My Solidworks Nightmare 3

[SteveSutherland]

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

 

[SteveSutherland]

Also

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.

 

[rfus]

I had crashing problems running XPSP1. XPSP2 fixed this problem. I would have your users run filemon

http://www.sysinternals.com/Utilities/Filemon.html

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

 

[SteveSutherland]

Thanks for the suggestion.

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?

 

[dezignstuff]

Are you getting a driver that is recommended for use with SW06 or 04?


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.

 

[SteveSutherland]

The driver is the one reccomended for 2004.

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.

 

[PDMAdmin]

First of all, try opening the "Performance" tab in the Windows task manager and see how much memory is in use. Are your files using lots of memory? If so, that may explain the crashes.

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.

 

[SteveSutherland]

3 Gig Switch

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.

 

[pdybeck]

SteveSutherland,

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

 

[SteveSutherland]

Thanks alot. Yes, I do agree that VM is going to be better than crashing and losing work.

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.

 

[kcarpenter]

What version of ST are you currently running? All SP's of V5R14 are compatible w/ XP SP1 and SP2. V5R12 SP2-SP8 are only XP SP1 compatible while SP9-SP11 are compatible with both XP SP1 and SP2.

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.

 

[SteveSutherland]

SmarTeam
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.

 

[kcarpenter]

I'd say the move to XP SP2 is just fine as you're running V5R12 SP11 which is supported for that OS. But I would stick with SP4.2 of SW for now. If something major was changed in SW from 4.2 to 5.0 and ST is using older SW calls for any part of it's LFO's you're gonna have problems.

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.

 

[SteveSutherland]

Sound Advice,

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.

 

[kcarpenter]

If your users are truly distraught with the crashing problem, try taking a different approach. Get them to only use the ST add-in when needed, keeping it off while doing any modeling changes whenever possible and not necessarily turning it off all together.

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.

 

[dogarila]

It is true that SW may have changed it's API with SP5, and we could lose some of the SmarTeam/Solidworks interoperability.

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?

 

[smcadman]

Regarding the 3 Gb switch:
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

 

[CorBlimeyLimey]

Using the /3GB switch will not harm your machine, nor should it create instability (unless you are on XP-SP1), even if you have less then 2GB physical RAM.


Helpful SW websites FAQ559-520
How to get answers to your SW questions FAQ559-1091

 

[pdybeck]

Flores,

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

 

[smcadman]

I went to

http://www.panoramafactory.com/discus/messages/17/313.html?1057432320

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

[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

Should I put the " /3GB " after the " /fastdetect "?, or should the switch replace the fastdetect?

Flores
SW06 SP4.1