4 Replies Latest reply on Mar 1, 2018 11:22 AM by Scott Lyon

    file corruption in SW 2018

    Richard Bruning

      Solidworks 2018 File Corruption


      Machine: Lenovo Thinkpad P71 Signature Ed., i7-7820HQ @ 2.9GHz, Win10 Pro, 64GB RAM, NVIDIA P4000 8GB. Solidworks Installed:  2018 SP1

      Older Machine where I did my SW2017 SP5? work.  HP ZBook, NVIDIA K2100M 2GB, 24 GB RAM

      While working on a large project I started to see files becoming corrupted - unable to be opened at all.  The accompanying error message was:

      “An error was encountered while trying to open your file.  Contact Technical Support for a possible solution.”

      All corrupt files reported to be exactly 8 bytes according to Windows Explorer properties and had lost their nice preview picture.  File names were also became prefixed with ~$  This occurred with parts and assemblies alike.  For example: “ ~$stuffed-table-bearing-factory.SLDASM “  (This could just as easily be a SLDPRT)

      So far, my investigation has found this consistently and reproducibly happens when saving SW2017 assemblies in SW2018 creating “version hybrid assemblies;” consisting of both SW2017 and SW2018 parts and subassemblies.  Maybe it’s just the newly saved and thus converted SW2018 top-level assembly that is of SW 2018 species with all children entities SW2017, but the subsequent children subassemblies and parts will also be proactively corrupted by this file-save action.

      I found a partial workaround - If I am fortunate enough to remember to do this when loading an uncorrupted SW 2017 assembly.  It is a tedious nested process:  OPEN the assembly

      FOR EACH PART, simply open, save, and close (OSC) – ONLY IF THEY ARE PARTS. Nothing else.  Don’t “save as.”    Do this to ALL parts.  IMPORTANT: “ALL” means, for example, if you have six identical fasteners – EACH must be opened, saved, closed (OSC’ed). This makes them 2018 parts.  One missed entity will defeat the effort altogether and that assembly will likely get corrupted. 

      FOR EACH ASSEMBLY within that assembly, ONLY OPEN IT – put it aside, it is uncorrupted – IT IS YOUR NEXT PROJECT and you will follow the same process. 


      FINALLY, Only when an assembly (which may be nested within a parent assembly) contains ONLY PARTS, open, save, close all.  Once EVERY part (unique and duplicate) of an assembly WITH NO SUBASSEMBLIES, have been OSC’ed. Save that assembly.  Save – no save as – consider it a part.  Close that assembly so you don’t get confused. 

      Now you can move up and continue with other child assemblies or the parent assembly.  You see, THIS IS NESTED and no assemblies with sub-assemblies should ever be saved until those sub-assemblies have been dealt with. Finally, as you’ve OSC’ed the lowest level child parts within child sub-assemblies and the sub-assemblies themselves, you can save the next level assembly.  When all subassemblies of the parent assembly have been processed and all parts (unique and duplicate) have been OSC’ed.  ONLY NOW can you save the original assembly you were preventing from being corrupted.  Simply save it.  Again, no save as.


      After this, you will notice you have two copies of all of your sub-assemblies and parts;  one adorned with a ~$ prefix indicated corruption (maybe perinatally – time will tell)  and the original.  Reopen the top level assembly to verify you have a pure SW2018 assembly.  If this opens, rebuild it and save it.  If this opens, it also means everything the assembly tree in including sub-assemblies are now SW2018 and hopefully robust enough you can continue your project with confidence.

      I see SW 2018 issues with other repositories (ex. GrabCAD).  I don’t blame GrabCAD, they have been open, are working on it and it will require help from Solidworks Developers.  I feel for companies that are in this predicament.  A lot of time will be lost.  I don’t know if these corrupted files are forever lost but reading 8 bytes in the properties section of Windows Explorer has me reaching for my TUMS.

      This is just my experience working on a large project.  I’d be interested in hearing your experiences.



        • Re: file corruption in SW 2018
          Vladimir Urazhdin

          When I tested SW 2018 SP1 I also have seen this issue. Indeed, in some cases SW freezes when open assembly with multiple sub assemblies. What I noticed, if the problematic part/sub assembly open before open main assembly, in some cases the issue may be resolved.

          • Re: file corruption in SW 2018
            Michael Lord


            I'm not seeing any of the issues you are having with SW2018

            Have you tried opening the Assembly in Advance mode.

            This may help isolate which sub-assembly or part which may be causing the problem.

            An Error was Encountered … DON’T PANIC – SOLIDWORKS ASSEMBLY #SOLIDWORKS | Michael Lord

            • Re: file corruption in SW 2018
              Scott Lyon

              So far I'm not getting any permanently corrupted parts but I am getting lots of errors relating to finding parts in sub assemblies. It seems if I have two sub assemblies that share common parts but of different part configurations SW can't figure out that it can load both. If sub assy A used part B in config 'a' then sub assy B can't find part B if its config is 'b'. If both sub assies use part B in the same config 'a' then all is well. Very frustrating.

              I too am finding lots of files with the ~$ prefix now. Usually that designation is used by Windows Explorer to indicate that the parent file is in use somewhere. It applies to almost all file types and usually they go away when the parent file is closed. It is the file marker that lets someone else know that the parent file is open and you can't edit it until they close it. I believe SW is tripping on these little markers and thinking it can't open two instances of the same part file for editing even though they are in different configurations.

              I have almost 27,000 part files in my huge main assembly so saving each one to 2018 is out of the question. Unfortunately I've never gotten the task scheduler to work for updating files so this whole issue is one that SW is going to have to fix. Hopefully they can before too many folks suffer permanent damage to their work.

              • Re: file corruption in SW 2018
                Scott Lyon

                Follow-up a couple hours later


                I've also found that having two identical files (parts or assemblies) from different locations is causing problems. Say I have 2 hopper sub-assemblies in my top level, the hoppers are different but they both have a pipe flange at the bottom and the flanges are the same. Not just the same type but the exact same files stored in 2 separate places on my hard drive with its respective tank model. Which ever tank gets opened first ends up just fine. The second tank opens but complains it can't find the flange and asks me to suppress or find it on my own. In the end I open with it suppressed and the tank throwing errors. If I close everything out and open tank 2 assy by itself everything is fine.

                This again makes me think the problem is with the way SW is using the ~$ markers.