Yesterday I imposed a curious error on my workflow. I think I figured out why, and how to avoid it. Not a question here unless I'm wrong. Some terminology may be inaccurate, but issues, actions and results are eminently clear and I don't care to argue PC semantics here or anywhere. Installation ref 2018 SP5 on Win7 Pro.

What happened:

I saved a large assembly as a Parasolid and closed assembly, to re-import parasolid and save as 3D PDF. Large assembly and its subassemblies both contained virtual components. Some (about 95%) imported components were altered to assign Acrylic (Medium-high Impact) as the material so that they would be fully transparent in the 3D PDF output, meaning that I altered some of the imported components which had never been saved as a file. 3D PDF creation went through without issues. I closed imported Parasolid without saving anything from it.

Then I did not close SWx.

I opened the same large assembly file again to continue work on it. It was error-free just recently when closed. Now it had non-matching internal ID ("NMIID") errors on apparently random virtual components, and only on virtual components. Further review showed that they had all been modified in the imported parasolid which was not saved as an assembly file.

This was infrequently seen by me before, so I came to Forum to search for "non-matching internal ID" posts. You can do that yourself if you want. Every single topic and discussion described Part FILES and blah-blah-PDM-shaming, without a single reference to virtual components in any previous topic that I examined. All of the suggested workarounds and repairs suggested involved manipulating files only, whether via PDM, backup, restore previous version, or w/e. The key differentiator here is that my errors are exclusively in virtual components in the parent assembly that - not only had never ever been a part file - but also had been created into existence by importing a parasolid file from the large assembly which had never been and never would be saved to a file. Again, important detail.

What's happening in the background:

When a file is imported and until it is saved, it will exist as a SWx Part or Assembly per the chosen templates in the import process. However, the representation you see in front of you is not a real file in file storage until you save it as a real file. It does exist somewhere as something to be worked upon, altered, processed, or whatever, and that somewhere is the Temp folder, a system location where Windows puts stuff it's working on, particularly when it does not belong to a saved file yet. I do hope that you see where this is heading.

What SWx had misrepresented:

Somehow, altering the virtual components in the parent assembly when imported from a parasolid and also not saved to a file, created these parts in the Temp directory where they were named Thing^Assembly.SLDPRT and also for some reason retained these parts in Memory even when the imported assembly was closed without saving. Therefore, when I reloaded the actual assembly file, and because SWx cannot handle two items with the same name, now the very same Thing^Assembly components opened in the actual assembly: 1) gave NMIID error, 2) did not show, 3) could not be unsuppressed or edited, and 4) made the whole assembly incomplete, unworkable, and unstable.

How I restored functionality:

Fuss and discuss and complain. Can you believe this crap? Here, take a look at what it's doing. I've never seen this before, in this way. (Optional. You could skip this step if you have read this, or you could choose to reenact the frustration for a true historical reproduction of the process to repair it.)

Close files without saving. Close SWx. Restart Windows. Log in. Open SWx. Open file. Yay! Everything came back as it should be.

Therefore, I definitely cleared the Temp folder with a system restart. I believe that the altered virtual components remained resident in memory so that the real virtual components within the assembly file would not open anew because the software already had that 'open'. Perhaps a simpler software restart without system restart could also achieve this, particularly if paired with a manual temp folder emptying. I don't care to test that. Maybe you can test and report here if this happens to you, and you find this post, and you haven't given up and resorted to a system restart.