My Solidworks Nightmare
My Solidworks Nightmare
(OP)
Hello Everyone,
I come here in desperation. Much of our drafting department has an epidemic of Solidworks crashing. Sometimes 5 times a day! Before getting into the specifics, I'll give you a bit of background.
I’m an applications programmer, and not a big Solidworks user. I have taken classes and training sessions on it, so I’m not completely in the dark. Outside of some macros and API programs, I do not use it often. I work in R&D and I’m generally not too involved with our production drafters. However, crashing has become a very serious problem for them, and I have been recruited to solve the problem until we can get a Solidworks/data management expert back in (advertising now). We lost ours a little over a year ago and he was never really replaced, which definitely is a big factor in our sorry position now.
We are currently still running SW 2004. We have been holding off upgrading for a couple reasons. One, SW 2004 SP4.2 is the latest version recommended with our version of SmarTeam (data management software). Upgrading SmarTeam would require upgrading all our clients at once, upgrading the SmarTeam server, and upgrading our Oracle DB server. The problem with doing all this is that IT is shortstaffed, and we are to busy to allocate a production drafters time to test the system. Not to mention that we are using SW 06 up in R&D to do our CFD and flow analysis and its stability has not been all that brilliant. That’s on a machine that doesn’t use SmarTeam integrations, has 4 gigs of RAM, top of the line hardware, and has a minimal amount of software loaded on it. Since it’s not readily backwards compatible, it’s just not a jump we want to make without testing first.
Anyway, that’s our excuse for still being on SW 2004. We do have plans to upgrade next fall, but leaves a few months in the mean time to fix this crashing. To address the problem, I first charted out the hardware and software specs of the drafting machines. The hardware was all pretty equal, but driver and service pack levels were all over the place. I also spent time searching through the SW express newsletters on IT support, and forums such as this one. And I’m greatly looking forward to Scott Baugh’s input on this if he find’s this post. Finally, I had drafters start detailed logs of their crashing. They log the general appearance of the crash, what they were doing, any error messages, and approximate size of drawing.
Taking the recommendations I got from SW, our vendor, and sites such as this, I built a test machine. Hoping that if I did everything as suggested, the crashing would be minimized and the same steps could be repeated for all. What I did with the machine was:
1. Started with a new blank 10,000 RPM hard drive in the machine
2. Added another gig of RAM (2 total)
3. Installed Windows XP Pro (Sp1)
4. Updated motherboard, network card (gigabit Ethernet connection), and all other system drivers except the video card
5. Updated video driver (nVidia Quadro FX3400) to 6.7.2.2 (the driver right from the SW site)
6. Installed Solidworks Office 2004
7. Applied SW service pack 4.2 (highest recommended by our vendor for the version of smarTeam we are running.)
8. Installed SmarTeam R12 with Solidworks integration
9. Applied ST R12 service pack 11
10. Installed Symantec AV client 10, disabled scanning of all solidworks file extensions
11. Set solidwork environment variables to make sure journal files, work directory, etc. were all on the local machine
12. Cut off internet access to that machine (didn’t want user downloading crap or getting spyware on the machines, that has been a problem here)
13. Set VM to 2 Gigs, fixed size, on local hard drive
14. Set the Open GL application optimization setting on the video driver to Solidworks
15. Scheduled a batch file to clean out temp directory (as suggested by Scott Baugh)
16. Put the machine into production.
As for the rest of the machines, they were like a mix and match of Software levels. The first change I made was to get all machines to the Solidworks recommended video driver (all but 2 newer machines running nVidia Quadro FX 3400). After a week of watching the crash logs, we saw no improvement. After that, we did a full virus and spyware sweep, as well as removing anything we noticed on the machines that shouldn’t be there (limewire, screensavers, weatherbug, search assistants, etc.) Then, I set the VM to a fixed size on all of them. Once again, no improvement. Then, I updated SmarTeam to SP 11 a few machines were at SP8. No improvement there either. On one machine that was identical to another, I updated the video driver to the latest available. There was no improvement.
During this time period, the test machine I had set up continued to have 4-5 crashes a week.
We do have a couple machines that have consistently done better. One of them is the only machine running Windows XP SP0. In order to see if that was the problem, we had another drafter try using that machine to see if he had less crashes. Our instructions were for him not to change anything. Of course, the first thing he did was put SP1 on what was supposed to be the control machine for this experiment. Sheesh. The other machine that is performing well is now identical in hardware, drivers, VM, and hardware to a couple other machines that are having a lot of problems. That made me suspect either a setting within Solidworks we haven’t examined yet, or else plain old user practices. Or there is always inaccurate crash reporting, but I don’t really want to consider that right now. We’ve explained quite clearly that they must be keeping accurate logs.
The patterns we have noticed are that certain users do have less problems, even with a seemingly identical setup. Larger assemblies are more problematic (which is to be expected), and there is a fair amount of crashing while saving a file.
At this point, our test of Windows service packs is ruined. We have considered the following to try next: Schedule batch file to clear temp files on all machine (since it is running on one that is crashing, I’m not expecting that to be the problem) Have users disable the SmarTeam integration with Solidworks (this creates more work for them to get files checked in and out from the server), try turning down drawing resolution and other performance tweaks (they really complain about that), and perhaps trying to use software open GL rather than hardware accelerated.
If anyone has any other suggestions, or even a direction to start looking, please let me know.
Thank you in advance,
Steve Sutherland
I come here in desperation. Much of our drafting department has an epidemic of Solidworks crashing. Sometimes 5 times a day! Before getting into the specifics, I'll give you a bit of background.
I’m an applications programmer, and not a big Solidworks user. I have taken classes and training sessions on it, so I’m not completely in the dark. Outside of some macros and API programs, I do not use it often. I work in R&D and I’m generally not too involved with our production drafters. However, crashing has become a very serious problem for them, and I have been recruited to solve the problem until we can get a Solidworks/data management expert back in (advertising now). We lost ours a little over a year ago and he was never really replaced, which definitely is a big factor in our sorry position now.
We are currently still running SW 2004. We have been holding off upgrading for a couple reasons. One, SW 2004 SP4.2 is the latest version recommended with our version of SmarTeam (data management software). Upgrading SmarTeam would require upgrading all our clients at once, upgrading the SmarTeam server, and upgrading our Oracle DB server. The problem with doing all this is that IT is shortstaffed, and we are to busy to allocate a production drafters time to test the system. Not to mention that we are using SW 06 up in R&D to do our CFD and flow analysis and its stability has not been all that brilliant. That’s on a machine that doesn’t use SmarTeam integrations, has 4 gigs of RAM, top of the line hardware, and has a minimal amount of software loaded on it. Since it’s not readily backwards compatible, it’s just not a jump we want to make without testing first.
Anyway, that’s our excuse for still being on SW 2004. We do have plans to upgrade next fall, but leaves a few months in the mean time to fix this crashing. To address the problem, I first charted out the hardware and software specs of the drafting machines. The hardware was all pretty equal, but driver and service pack levels were all over the place. I also spent time searching through the SW express newsletters on IT support, and forums such as this one. And I’m greatly looking forward to Scott Baugh’s input on this if he find’s this post. Finally, I had drafters start detailed logs of their crashing. They log the general appearance of the crash, what they were doing, any error messages, and approximate size of drawing.
Taking the recommendations I got from SW, our vendor, and sites such as this, I built a test machine. Hoping that if I did everything as suggested, the crashing would be minimized and the same steps could be repeated for all. What I did with the machine was:
1. Started with a new blank 10,000 RPM hard drive in the machine
2. Added another gig of RAM (2 total)
3. Installed Windows XP Pro (Sp1)
4. Updated motherboard, network card (gigabit Ethernet connection), and all other system drivers except the video card
5. Updated video driver (nVidia Quadro FX3400) to 6.7.2.2 (the driver right from the SW site)
6. Installed Solidworks Office 2004
7. Applied SW service pack 4.2 (highest recommended by our vendor for the version of smarTeam we are running.)
8. Installed SmarTeam R12 with Solidworks integration
9. Applied ST R12 service pack 11
10. Installed Symantec AV client 10, disabled scanning of all solidworks file extensions
11. Set solidwork environment variables to make sure journal files, work directory, etc. were all on the local machine
12. Cut off internet access to that machine (didn’t want user downloading crap or getting spyware on the machines, that has been a problem here)
13. Set VM to 2 Gigs, fixed size, on local hard drive
14. Set the Open GL application optimization setting on the video driver to Solidworks
15. Scheduled a batch file to clean out temp directory (as suggested by Scott Baugh)
16. Put the machine into production.
As for the rest of the machines, they were like a mix and match of Software levels. The first change I made was to get all machines to the Solidworks recommended video driver (all but 2 newer machines running nVidia Quadro FX 3400). After a week of watching the crash logs, we saw no improvement. After that, we did a full virus and spyware sweep, as well as removing anything we noticed on the machines that shouldn’t be there (limewire, screensavers, weatherbug, search assistants, etc.) Then, I set the VM to a fixed size on all of them. Once again, no improvement. Then, I updated SmarTeam to SP 11 a few machines were at SP8. No improvement there either. On one machine that was identical to another, I updated the video driver to the latest available. There was no improvement.
During this time period, the test machine I had set up continued to have 4-5 crashes a week.
We do have a couple machines that have consistently done better. One of them is the only machine running Windows XP SP0. In order to see if that was the problem, we had another drafter try using that machine to see if he had less crashes. Our instructions were for him not to change anything. Of course, the first thing he did was put SP1 on what was supposed to be the control machine for this experiment. Sheesh. The other machine that is performing well is now identical in hardware, drivers, VM, and hardware to a couple other machines that are having a lot of problems. That made me suspect either a setting within Solidworks we haven’t examined yet, or else plain old user practices. Or there is always inaccurate crash reporting, but I don’t really want to consider that right now. We’ve explained quite clearly that they must be keeping accurate logs.
The patterns we have noticed are that certain users do have less problems, even with a seemingly identical setup. Larger assemblies are more problematic (which is to be expected), and there is a fair amount of crashing while saving a file.
At this point, our test of Windows service packs is ruined. We have considered the following to try next: Schedule batch file to clear temp files on all machine (since it is running on one that is crashing, I’m not expecting that to be the problem) Have users disable the SmarTeam integration with Solidworks (this creates more work for them to get files checked in and out from the server), try turning down drawing resolution and other performance tweaks (they really complain about that), and perhaps trying to use software open GL rather than hardware accelerated.
If anyone has any other suggestions, or even a direction to start looking, please let me know.
Thank you in advance,
Steve Sutherland






RE: My Solidworks Nightmare
Any further questions on our setup that would help explain the problem, please ask.
And an aside, SW 2004 does not seem to have Solidworks RX.
RE: My Solidworks Nightmare
Send the log after crashing to your VAR.
I have also used the dependency walker to track down errors. http://www.dependencywalker.com/
This is where I found one of my crahsing problems was from a dll in XPSP1.
RFUS
RE: My Solidworks Nightmare
What I think we will do is pull the test machine back, apply XP service pack 2, and upgrade SW 2004 to service pack 5.
SP 5 for SW is supposed to be the most reliable with SW2004. However, our Vendor recommends staying as 4.2 and SP1 because that is what works best with SmarTeam. But since the aren't incompatible, and we are dealing with a large number of Solidworks crashes, I think it trumps the concerns about certain SmarTeam features not working properly, if that is the case.
That change would likely only be done on the one test machine though. If we determine it is helpful, we'll likely do it to all of them.
Also, Did you have any other issues such as anti-virus settings, VM settings, SW performance settings, or any not so obvious changes that seemed to help?
RE: My Solidworks Nightmare
The first thing I'd try would be turning off the SmarTeam add-in. I've been on-site with users before who were very frustrated with ST, and it caused tons of problems.
RE: My Solidworks Nightmare
We have been kicking around the idea of turning off the SW integration, but would want to make that something we test after some of the other solutions are exhausted since it requires a change in user procedure. It seems those changes are always much harder to make happen than software or hardware changes.
RE: My Solidworks Nightmare
If it's a memory problem, try the /3GB switch, as outlined here:
thread559-107229
However, since you're on XPSP1, you must apply the hotfix; otherwise you could lock up your hard drive.
RE: My Solidworks Nightmare
I have looked into that 3 gig switch on here before. But with only 2 gigs of RAM, does it really pay? Any more RAM allocated other than the 2 gigs I have in the machine would be VM wouldn't it? It's not exactly desirable to be running from VM either. I think Windows does allocate the 2 gigs it does have. I have monitored the memory usage before, and it wasn't maxed out, but then again, I've never been able to see that right before a crash either.
Does the 3 gig switch actually allow Solidworks to use a greater percentage of the 2 gigs? I know Windows XP alone will take around 200MB. But we also have SmarTeam and usually SW Explorer working, as well as MS Office. So I'm guessing we don't really want to give Solidworks more than the 1.6 gigs Windows can currently allocate to it do we?
Also, after a crash, it seems they can usually open up the program and do the same thing they were doing before without trouble. If it was a memory issue, wouldn't the same large file create a repeatable crash? But I can say we do notice more problems on larger assemblies.
I'm just trying to get more clarity on what the 3 gig switch can help with only 2 gigs of RAM in the first place? I know I realy should know this ahead of time, my apologies.
RE: My Solidworks Nightmare
Enabling the 3GB switch even if you have only 2GB of RAM will most definitely help if you are pushing RAM useage to 1.3 GB and above. I have first hand experience with several machines in that scenario. All the machines would crash when SolidWorks attempted to use more than roughly 1.3 GB of RAM. Since enabling the 3GB switch I have seen some of our users acessing slightly over 2GB of RAM in rare situations (obviously some hard space is now being utilized) and SolidWorks still remains stable. I think if you do more searching around this forum and other forums and newsgroups, you'll hear of similar reports. If you use the 3GB switch, make sure to add it as an extra boot option in the boot.ini file. This will allow you to boot into your original setup should something not take right. Otherwise you could end up a creek without a paddle, so to speak. I also have the Userva=2900 option based on other information from our reseller, SolidWorks tech support, and other fourm members.
Pete
RE: My Solidworks Nightmare
I'll be bringing back the test machine this morning. I'm going to skip our SmarTeam vendor's warning, and put on XP SP 2, as well as a later service pack of Solidworks. I will also enable the 3 gig switch and setup those monitoring tools as well. If the jump to SP2 and a newer Solidworks hrts SmarTeam too badly, the good news is that I could just disable it, since that is another thing I suspect may be related to their crashes when opening or saving a drawing.
RE: My Solidworks Nightmare
CAD compatibility is as follows...
SolidWorks 2004 SP0:
Compatible with SMARTEAM V5R12 from SP1.
Compatible with SMARTEAM V5R11 from SP6.
Compatible with SMARTEAM V5R10 from SP10.
SolidWorks 2004 SP1:
Compatible with SMARTEAM V5R13 from GA.
Compatible with SMARTEAM V5R12 from SP4.
Compatible with SMARTEAM V5R11 SP7.
SolidWorks 2004 SP3:
Compatible with SMARTEAM V5R14 from GA.
Compatible with SMARTEAM V5R13 from SP4.
Compatible with SMARTEAM V5R12 from SP7.
Compatible with SMARTEAM V5R11 from SP10.
SolidWorks 2004 SP4.2:
Compatible with SMARTEAM V5R14 from SP3.
Compatible with SMARTEAM V5R13 from SP8.
Compatible with SMARTEAM V5R12 from SP10.
Kevin Carpenter
CAD Systems Specialist
Invacare Corp.
RE: My Solidworks Nightmare
5RV12 SP11
SW 2004 4.2
This is the combo reccomended by our ST vendor. However, I would like to move to XP SP2 so I can enable the 3 gig switch. If we are at XP Sp2, I would also like to have SW 2004 SP5.
Upgrading SmarTeam can't happen until we get a new server.
So our test machine in drafting will be running:
ST 5RV12 SP11
SW 2004 SP5
XP SP2
From what I have been told from our vendor, 5tv12 sp11 is not reccomended with XP SP2 -sw 2004 SP5. However, I have no idea how incompatible they are. Any idea?
I've seen ST 5R12 SP11 running on service pack 2 machines without any differences than those running the recommended SP1, which makes me think it won't be too much trouble.
RE: My Solidworks Nightmare
Besides, if you start changing too many things at once and suddenly everything is working better you might not know what the actual cause was and what fixed it (this will help to avoid problems later obviously). If there are any new problems it will most likely be between ST and SW, not ST and the OS (which to me doesn't at this point appear to be the cause).
Someone had suggested turning off the add-in for ST, which is a good idea in general. It would be a good idea to turn off all add-ins not necessary for daily use actually. I have seen bugs w/ ST integration and the only way to tell is to turn off the add-in(s) and see if the stability improves.
There is a SMARTEAM forum you can check out also (in case you didn't alreay know about it):
http://www.smartuserforum.com/
Kevin Carpenter
CAD Systems Specialist
Invacare Corp.
RE: My Solidworks Nightmare
It does make sense, but I have seen it recommended that SP5 be used with Solidworks 2004 running on Windows XP SP2, which is why I would like to do them both. It is true that SW may have changed it's API with SP5, and we could lose some of the SmarTeam/Solidworks interoperability. There just seems to be a gap in compatability between the 3. ST is OK with Windows at SP2, but SW recommends going to sp5. But then, ST and SW are not an approved combo. I do think for a test, I want to still try the later SW sp to see how the SmarTeam integration acts. But I do think perhaps I am letting pressure to fix get the better of me any only test one major change at a time. Try Sp2 for a while, then the 3 gig switch, and if things still don't improve, then try SP5 and see if that improves crashing without any real traumatic changes to the way ST and SW work together.
Right now, the SmarTeam add-in is part of daily operations, and I meet alot of resistance when suggesting we try disabling it. If I cannot find any other fix for our problems, that will certainly have to happen, at least on our one test machine.
RE: My Solidworks Nightmare
Empowering them to help find the problem/answer will help relieve some of the pressure you're feeling. It's a minor interruption in their daily routine and there is no way possible you alone can duplicate the way each of them work on a single test workstation.
Good luck with your continued testing, hope you find your answer.
Kevin Carpenter
CAD Systems Specialist
Invacare Corp.
RE: My Solidworks Nightmare
As far as I know, when SW updates API, it still keeps the old functions/commands, for compatibility. I don't think this is an issue.
When and how these crashes started? Just out of the blue? After a hardware upgrade? SW upgrade? ST upgrade?
RE: My Solidworks Nightmare
Microsoft recommends 1.5 physical ram for page file/virtual ram. (It also recommends that initial and maximum page file values are the same.) With 2 Gb. ram, and 3 Gb. virtual ram, should I use the 3 Gb. switch, or do you only use the 3 Gb. switch if your physical ram is more than 3 Gb.?
Flores
SW06 SP4.1
RE: My Solidworks Nightmare
Helpful SW websites FAQ559-520
How to get answers to your SW questions FAQ559-1091
RE: My Solidworks Nightmare
Use the 3GB switch. Even with 2GB of RAM (without the switch), I think you will notice that SolidWorks will crash well before your computer reaches 2GB of memory useage. We were seeing SolidWorks crash when our memory useage hit 1.3 GB even with 2GB of RAM installed. I believe all this has to do with how windows allocates memory for itself. By enabling the 3GB switch, you reduce the amount of memory reserved by windows and therefore allow running applications to access more memory. After we enabled the 3GB switch, we were able to utilize the full amount of 2GB of RAM that had been installed.
Pete
RE: My Solidworks Nightmare
http://ww
and tried to find the boot.ini, but could not find it. I'm running XP Pro, and I have "Show hidden files and folders". I didn't find the boot.ini, but I do have a file called boot.pcp and it's contents look similar to the .ini file in the link above:
boot.pcp
CODE
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
Should I put the " /3GB " after the " /fastdetect "?, or should the switch replace the fastdetect?
Flores
SW06 SP4.1
RE: My Solidworks Nightmare
[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /3GB /NoExecute=OptIn
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /3GB /Userva=2900 /NoExecute=OptIn
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /NoExecute=OptIn
Pete
RE: My Solidworks Nightmare
The second line in my boot option is the one you should add...
Make sure to copy the first boot option to create the 2nd. Add the 3GB switch and Userva=2900 to the second line. Leave the 1st line alone. Next time you boot, you'll be presented with 2 options. Choose the second option to boot into as this will be the 3GB switch enabled one. Use this one until you are confident everything is fine and dandy. If you want, then you can delete the first boot option.
Pete
RE: My Solidworks Nightmare
I haven't been that involved with drafting, from what I hear, it's always been happening. We used to have a person maintaining their machines, keeping them all at the same SP level etc. That person left some time ago and was never replaced. The users have been basically making whatever changes they want without oversight. It has gotten worse over time without oversight.
I now have them all back to pretty much the same software (cleaned all the viruses, spyware, and other non-work related software), and for the most part, the same hardware, but we are still seeing crashing.
I do have one machine up there I loaded from scratch (new hd, video card, and RAM) with all the reccomendations I could find (yet to apply the 3 gig switch, or test without SW integration, have my fingers crossed it will help), and I'm still seeing trouble with it.
Of course, user practices and plain old buggy software could also be it. I just want to make sure I do everything I can to setup the machines.
RE: My Solidworks Nightmare
Created a system restore point.
Made a backup of boot.ini file.
After modification it looked like this:
CODE
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /3GB /NoExecute=OptIn
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /3GB /Userva=2900 /NoExecute=OptIn
Flores
SW06 SP4.1