If none of these settings fixed the problem then it is time to bring out the big guns - but beware, you must have access to the Default Administrator account on your computer for the following steps to work. If you do not , then you will need to get your IT team involved.
Here we will try to register the .dll files that may have not registered properly during installation. Keep in mind that it is possible for these files to become unregistered after windows updates or SOLIDWORKS updates.
Now for the fun part. Type the following in the command prompt, keep in mind these pathnames are the default paths. If you changed the name of the SOLIDWORKS installation folder or selected a path different from default please use the correct path.
You will get a message telling you if the .dll file was successfully registered or not. If you do not have administrative permissions these commands are likely to fail. Once again, get a hold of your IT team if this is the case.
Hi, I'm asking here because I have no idea about what's going on, and it's kinda driving me crazy. I have installed Solidworks on my secondary HDD, and I have noticed that once in a while some program will do some stuff on a folder cointaining fonts in the Solidworks installation. The list of these programs include: consent.exe, mmc.exe, systemsettings.exe, firefox.exe, and probably others that I haven't catched yet (I can provide Process Monitor screenshots and/or logs if needed).
I cannot find anything on the web similar to this, and I cannot find a way to understand why some random and apparently unrelated programs should access that folder. I don't want background HDD activity and most importantly I don't want activity that makes no sense!
As I noticed that the Solidworks fonts folder was regularly accessed when I launched Firefox, probably all the activity related to that folder was just because of those Fonts being installed in Windows. After removing the installed Solidworks fonts (located on the secondary HDD) through the Settings app, I have not seen any further activity related to them yet.
Thank you for your suggestion. I'm afraid I'm on windows 10 home, so I cannot use Group Policy. Is it possible to do the same thing by modifying folder permissions in the Properties - Security options in File Explorer? Also, for example when mmc.exe or consent.exe access that folder, ProcMon says that the user is me, not System, so I don't know to who I should deny access to that folder
I could give you some instructions about how to capture this activity with Event Tracing for Windows (ETW) but you would probably have to share the trace data here (via OneDrive, Google Drive, etc. link), since the data is not easy to interpret. The trace would also gather a lot of data every second, so you would probably need to be able to reproduce the problematic behaviour on demand in order to keep the trace data to a manageable size.
This issue seems more like an irritation than a major problem and you might not want to risk revealing too much information in the publicly shared trace data just to resolve it. Let us know if you are interested in pursuing this course of action.
Hi @Gary Nebbett , yes, it is definitely more like an irritation rather than a major problem, though it is completely ruining the work I have to do with this machine. It's not possible to reproduce the issue on demand and it might be very time consuming to record it since, for example, this morning it has happened several times in a row and now it hasn't happened for a while. Still, I may try what you suggest since it looks like there is nothing else to do; also, after you give me the instructions, I'm not 100% sure I will follow up with an actual ETW capture for practical reasons, so I don't want to waste your time if that's the case.
Before trying to proceed, maybe there is a way to tell Windows to treat this secondary non-os drive more like a mass storage rather than a drive where it has to do all of this stuff I've never asked for? The secondary HDD in my PC was supposed to be active only when I'd access it and for nothing else.
I have attached a file to this message, which you can save somewhere; conventionally, it should have a .wprp extension (Windows Performance Recorder Profile). Assuming that you save the file with the name "ts.wprp", to start a trace, issue the command wpr -start ts.wprp!Troubleshoot -filemode; to stop the trace, issue the command wpr -stop why.etl (you can choose your own name for the output file in place of "why.etl").
c80f0f1006