AnsweredAssumed Answered

Instability of Solidworks 2009

Question asked by 1-GHQKT8 on Aug 12, 2009
Latest reply on Aug 14, 2009 by Anna Wood

Like • Show 0 Likes0
Comment • 36

Our engineering group has been using SW 2009 for about six months now and regret ever installing the upgrade. There are simply too

many crashes which has caused lost productivity. We have spoke to our I.T. person and he has done everything to help stablilize our system

but SW 2009 simply has too many bugs and software problems to ensure consisten stability. It's as if SW rushed the version out the door, before it

was completely finished. Everything in our culture today is based on the almighty dollar, so I guess I"m not surprised at this.

We wish we would have gone with Autodesk Inventor now, but we'll have to manage what we have.

No one else has this question

Outcomes

36 Replies

1 2FirstPrevious

Charles Culp Aug 12, 2009 11:08 AM
Mark Correct
Correct Answer
Don,

You have come to the right place, most people here find Solidworks 2009 to be very stable. I have been keeping track, and I have crashed 10 times since January 1st of this year. I think the last few are due to my 3d mouse, but I can't confirm that. I was actually crashing once per month until I installed it in May.

So, hopefully you weren't just here to rant, I think we can help. Let us know, in great detail:

1. What kind of modeling/assemblies/drawings do you create?

2. What are the FULL system specs of your computer(s)? Processor spec should be something like: Intel Core2Duo E8500.

3. Do you use PDM software? If no, how do you store your files?

4. What mouse do you use, do you use any other input devices, which video card driver are you running, which service pack of 2009 are you using, which OS are you running, is it 32 or 64 bit?

5. Also, what kind of crashes are you getting? How often do they happen? Just with assemblies/etc?

Let us know and there is a good chance we can help fix your problems.
Like • Show 0 Likes0
Actions
Daniel Smith Aug 12, 2009 11:12 AM
Mark Correct
Correct Answer
I find 2009 to be much more stable than the previous version. As Charles said there are many things that can contribute to crashing though and any and every possible detail will give insight and hopefully lead to a solution.
Like • Show 0 Likes0
Actions
Bruce Fisher @ Daniel Smith on Aug 12, 2009 11:56 AM
Mark Correct
Correct Answer
I too find SW 2009 to be very stable, but not totally without glitches, which has to be true of any complex program. Like Charles said, this forum is a great place to get help if you can provide more details. Have you worked with your VAR on this?
Like • Show 0 Likes0
Actions
1-GHQKT8 @ Bruce Fisher on Aug 12, 2009 12:03 PM
Mark Correct
Correct Answer
I know for a fact that there have been many many SPRs (Software Performance Reports) on this version. I saw a list a while back, and there are hundreds! I would not
call that "a few glitches"....just my opinion. I have worked with our I.T. person and SW support, Fisher Unitech. They have
been unable to solve these issues.
Like • Show 0 Likes0
Actions
Josh Brady @ 1-GHQKT8 on Aug 12, 2009 12:39 PM
Mark Correct
Correct Answer
There are hundreds of SPRs on every version of every 3-D CAD package.

As others have requested, what is your purpose in posting here? If you are looking for solutions, there are many who are willing to help. If all you want to do is vent, feel free to do so, but please let us know so that we may ignore this thread in the future.
Like • Show 0 Likes0
Actions
Tim R Aug 12, 2009 12:55 PM
Mark Correct
Correct Answer
Yes, I agree with the other posts. There are many things that can cause instability, including someone wishing they hadn't gone with something new, and instead had stayed with something familiar and comforting. In my opinion, SW09 is just as stable, of course in service pack 4, as anything that has gone before it. I have some experience with Inventor and SW09 seems to be just as stable if not more so than the current version of AI. One thing I will say is that I reverted back to a previous/approved Nvidia video driver and allot of my video glitches are gone. One other thing I would also check is other software that is running in the background, maybe that automatically starts up, that you don't use. Allot of my resources were being used by portions of software I had installed but did not need memory resident. MsConfig is one of my best friends.

-Tim
Like • Show 0 Likes0
Actions
Gerald Davis Aug 12, 2009 1:39 PM
Mark Correct
Correct Answer
... using SW 2009 for about six months now and regret ever installing the upgrade...
SW09 SP2.0 and later have been pretty stable. I've chased all of my system crashes back to hardware problems. One was video, one was bad mouse driver, another was my utility company!

Xcel has a program that saves me some money on the monthy bill by allowing them to brown-out my airconditioner at their whim. When they do that, one of my Dell laptops has a fit and falls in it. If I put a battery in it that would probably fix that one.

As Charles said, it would help if you provided more info about your workstations.

If you want to fix this on your own, try running in Software OpenGL mode. If the crashes stop, you will know that your problem is with the video system.
Like • Show 0 Likes0
Actions
1-GHQKT8 @ Gerald Davis on Aug 12, 2009 1:42 PM
Mark Correct
Correct Answer
Been there, done that with open GL mode, no difference. Doesn't good software design include compatibilty with current software
configurations? It seems that many periphial components are the cause of these crashes, but that doesn't escape the fact that it is
related to the software itself.
Like • Show 0 Likes0
Actions
David Paulson @ 1-GHQKT8 on Aug 12, 2009 2:01 PM
Mark Correct
Correct Answer
Don,

There are known compatibility issues with SolidWorks and MS Office. I understand that this was fixed in SP4.0 along with a hot fix?? I use SW2009 on a computer that does not use Outlook and have very little problems. However, I do have very significant crashing problems when running Flow Simulation 2009 on Vista x64, but understand that this issue is the subject of a SPR. You should try SolidWorks on a machine with a fresh OS install with a reformatted hard drive. Then just add back in applications until you start crashing again. That way you will determine the source of your issue.
Like • Show 0 Likes0
Actions
Gerald Davis @ 1-GHQKT8 on Aug 12, 2009 2:03 PM
Mark Correct
Correct Answer
... Doesn't good software design include compatibilty with current software configurations? ...

Sort of - if all of the other current software configurations are written correctly. SW focuses on performance and takes advantage of all published functionality. NVIDIA, ASUS, et. al. advertise their API's to work one way and they don't always. SW is a very thourough test platform for other software and hardware vendors.
Like • Show 0 Likes0
Actions
Michael Cudnik Aug 13, 2009 9:28 AM
Mark Correct
Correct Answer
We have yet to see any system specs.....this would help

Also, most IT departments, although good at their "IT" stuff, have no idea how to properly configure and maintain a SW workstation. That is why we all come here.

Like Charles said, post system specs, peripherals used, etc. etc.
Like • Show 0 Likes0
Actions
1-GHQKT8 @ Michael Cudnik on Aug 13, 2009 9:43 AM
Mark Correct
Correct Answer
Sorry. I may add that I have had Fisher Unitech review all of my hardware configurations and they saw nothing that should causse this instability issue. System specs are as follows: Operating system is Windows XP 64 version 3.0 sp 2.0
Computer is Intel Corel 2 Duo E8500 3.16 GHZ 3.93 GB ram Graphics card Nvidia Quadro FX 1700

We use a shared network and store our files in subdirectories under the main network drive.
Like • Show 0 Likes0
Actions
Michael Cudnik @ 1-GHQKT8 on Aug 13, 2009 9:52 AM
Mark Correct
Correct Answer
Core computer hardware looks good.

2 things I would entertain as changes....

1) Why xp64 over vista64?

2) Personally, I had nothing but problems with the FX1700 and FX3700. By themselves, they are great cards, they just never worked for me. Something with the drivers and my particular PC. The pc's were Dell T3400 with the Intel Core 2 Duo E8500 3.16 Ghz and 4GB ram. I have since switched to ATI FireGL v7600 and have had no issues. Perhaps (dare I say) even a little better performance. Since SW is so reliant on the video card, maybe try switching it out and see if your stability improves.
Like • Show 0 Likes0
Actions
Tom Nicholson @ 1-GHQKT8 on Aug 13, 2009 9:55 AM
Mark Correct
Correct Answer
Should be fine enough, Hardware isn't cutting edge, but not bad at all..

When you installed 2009, did you do a clean install or upgrade from a previous version?

What video driver version are you using?

When was the last time the computer was just blown away? Sometimes a nice clean system will solve most problems.
Like • Show 0 Likes0
Actions
1-GHQKT8 @ Michael Cudnik on Aug 13, 2009 9:58 AM
Mark Correct
Correct Answer
What kind of problems have you had? Do you think this could cause my issues? That's funny, because this card is "SW approved" to be perfectly compatible with their software. As far as the operating system, I guess you would have to ask our I.T. guy as to why we use XP over Vista, but again, a good software program should run on either platform, don't you think?
Like • Show 0 Likes0
Actions
Charles Culp @ 1-GHQKT8 on Aug 13, 2009 10:01 AM
Mark Correct
Correct Answer
It could be due to faulty power (not getting good line voltage). Sounds wacky, but it has been reported multiple times here. Try running on a difference circuit.

It could be due to bad network configuration (bad wires, bad switches, etc). Try copying your assemblies locally for a few days, and working on them that way. If it fixes the problems, your IT dept. needs to review your network and fix the issue. This is also a convenient time to convert/review everything to gigabit spec parts.

The best option to fix your issues if it is a network problem is to run SW's PDM for workgroups. It requires everyone to have a seat of SW Professional, but then it comes with the package. This is a great solution, because the PDM will automatically pull all the files to your local computer, and manage that for you. This will require reconfiguring your data for PDM, so it is not a small step, but then you get the additional benefit of PDM control. The workgroup package is fairly unobtrusive, but definitely requires changes to procedure.

Windows XP is a poor choice for 64 bit operating systems. Convince IT that is imperative for you to run Vista x64. You have already shown serious issues, things can only get better. It has been shown many times here on these forums that Vista x64 is the operating system of choice for Solidworks. XP x64 is a hack-job.

Of course, this all depends on the answer to my fifth question, which is what types of crashes are you receiving? And what types of assemblies do you work on? If you give a thourough answer to all my questions in my first post I still think we can work a solution for you.
Like • Show 0 Likes0
Actions
1-70W0UV @ 1-GHQKT8 on Aug 13, 2009 10:12 AM
Mark Correct
Correct Answer
Are you opening your files from the network drive or are you copying them to your computer before opening them?

Can you give any more information about what type of crashes your having? Which SW package (core, premium etc.) are using and which Add-Ins do you have active? Is it in all areas of SW or mostly when working with part, assemblies or drawings? Is it when the computer is working hard or anytime you try to do something?
Like • Show 0 Likes0
Actions
1-GHQKT8 @ 1-70W0UV on Aug 13, 2009 10:19 AM
Mark Correct
Correct Answer
We open files from the network and don't copy files onto our hard drive as that can cause confusion. ( We currently do not use PDM works).
The crashes don't happen exclusively with one particuliar file type, but usually drawings and assemblies.

It looks like I may be defending myself to my grave here....lol.
Like • Show 0 Likes0
Actions
Charles Culp @ 1-GHQKT8 on Aug 13, 2009 10:21 AM
Mark Correct
Correct Answer
Well, then I guess I will stop "challenging" you with questions. Good luck.
Like • Show 0 Likes0
Actions
1-1NHKU5 Aug 13, 2009 10:27 AM
Mark Correct
Correct Answer
Are you by any chance using Flow Simulation? If so, try unloading it when not needed and see what happens.

-Martin
Like • Show 0 Likes0
Actions
1-GHQKT8 @ 1-1NHKU5 on Aug 13, 2009 10:29 AM
Mark Correct
Correct Answer
Currently, I am using no add-ons. I have never used flow stimulation but I do use routing sometimes, but turn it off immediately after using it.
Like • Show 0 Likes0
Actions
Matt McKendrick @ 1-GHQKT8 on Aug 13, 2009 11:51 AM
Mark Correct
Correct Answer
Believe me, this forum is not loaded with Solidworks apologists. Nobody is trying to argue with you or even disagree, We don't have the ability to jump on your workstation and evaluate it, so we need to ask a lot of questions. Nobody is meaning to make you feel defensive, I assure you. Many of us have had the exact same frustrations as you have and have been able to resolve them. But no one can help unless we know some very specific information that may, or may not seem pertinant to you right now.

Some observations I have from the information you have provided thus far:

1) Charles is absolutely correct about the XP64 situation. An arguement needs to be made to your IT dept. about upgrading to Vista 64.
2) The network at our facility is our Achilles heal as well. When you load and work directly from the network, things slow down, especially if you are using autosave. I work locally, and then save to the network at the end of the day. We are a small group, so we can get away with this. PDM would be the answer.
3) Your video card needs to be ugraded (or rolled back) to the latest approved driver.
4) Consider upgrading to 8GB of memory.
5) Try and run as few other processes as possible with Solidworks open. Close down any unecessary background processes.
6) If you do get Vista 64 installed, Have it De-bloated. In other words, turn off all of the bells and whistles that make it look pretty, but slow things down. Be sure to also disable UAC.
7) Try playing with you affinity settings. If you have mulitple cores, you can assign processes to run on specific cores instead of having windows automatically adjust this for you. It made a 10% improvement in speed for me.
8) Make sure Solidworks is customized to run well on your system. Image quality, background, backup/recover, curvature generation, lightweight loading, etc will all have an impact on performance.

These are just a few easy suggestions. It is possible that your workstation just isn't built with 3D CAD in mind. IT guys are notorious for ordering what is convenient and cost-effective, and not necessarily what is optimal to help you do your job.

You might find this blog entry from Matt Lombard interesting as well: http://www.dezignstuff.com/blog/?p=261

Good luck.
Like • Show 0 Likes0
Actions
1-70W0UV @ 1-GHQKT8 on Aug 13, 2009 12:54 PM
Mark Correct
Correct Answer
Sorry to make you feel like your defending yourself, you're providing clues. Troubleshooting computers is basically a process of elimination, the more we know about what you have, how you work and what you've tried the more we can eliminate. The problem could be anything from a corrupt file to a bad powersupply. SW works your computer hard and hardware issues may show up running SW even though your computer runs every other program perfectly.

Drawings and assemblies will work SW more then simple parts. Have you tried copying the files to your local harddrive to work on them? Opening SW file over a network tends to be a bit of a trouble area.
Like • Show 0 Likes0
Actions
1-1NHKU5 @ 1-GHQKT8 on Aug 13, 2009 1:18 PM
Mark Correct
Correct Answer
Grasping at straws here...I'd suggest using a memory monitor to see what is happening with memory as you load and unload SW. Start it up as soon as the system boots-up and log memory utilization changes as you do different things. Start SW, load a design file, unload the file, shutdown SW. What happens with memory? Do this many times in a row...10...20. What happens?

With Flow Simulation we've seen a small amount of RAM that never seems to be given back to the OS depending on what you are doing. We are working directly with SW to chase after this issue as it seems that we are one of the few and the proud that are doing things with FS that stress the limits (or these limits at least).

With a 32 bit OS memory fragmentation was an issue. Since you are running a 64 bit OS I'd install as much memory as your MB can handle and see what happens. Memory is far cheaper than your time.

Also, don't discount the possibility of having a bad memory module. I forgot if you said whether this happens on more than one machine. Obvisouly if it is more than one machine the issue could be somewhere else.

Have you tried running the files locally just to have a cross-check?

I understand just how frustrating this can be for you. We've gone through three hardware platforms, four CPU models and several memory configurations in trying to solve SW/FS problems. Still not 100% there but a few things have improved. These issues have cost us months in delays due to having to switch to unpaid-troubleshooter mode rather than getting-on with design work. You need to make it 100% clear to SW just how much of a productivity hit you are taking because of these issues.

My personal position on all of this is that there have to be fundamental problems with the software somewhere deep inside (like Windows for the last 10 years or more) that are causing issues. With the power and performance available today on true workstation-class machines there's almost no excuse to write software that is so finnicky about hardware configurations as to cause so many problems. I've been very vocal about the fact that I think we don't need any more features but we do need what we have today fully debugged and working reliably with the approved hardware/software combo. If you build a machine using the approved hardware, drivers and OS it should just work, no excuses.

-Martin
Like • Show 0 Likes0
Actions
Jim Sculley @ Charles Culp on Aug 13, 2009 2:25 PM
Mark Correct
Correct Answer
It could be due to faulty power (not getting good line voltage). Sounds wacky, but it has been reported multiple times here. Try running on a difference circuit.
A bit of a stretch. For such voltage problems to affect SW and only SW would be unlikely. There are device drivers such as hard drive controllers that would be far more sensitive to such things. I would expect BSODs, not SW crashes.

It could be due to bad network configuration (bad wires, bad switches, etc). Try copying your assemblies locally for a few days, and working on them that way. If it fixes the problems, your IT dept. needs to review your network and fix the issue. This is also a convenient time to convert/review everything to gigabit spec parts.

Every time is see this excuse, I get a little more annoyed. Bad networks will not cause crashes in well written software. TCP/IP is designed to be reliable, regardless of network issues. Bad packets are retransmitted until success occurs. Most applications place some sort of time limit on such activities to prevent infinite wait times when someone inadvertently disconnects the server while vacuuming. Well written applications handle these timeouts gracefully and notify the user See your web browser for an example. Poorly written applications fall over. Claiming that a better network will solve all your SW crashing problems is nonsense.

The best option to fix your issues if it is a network problem is to run SW's PDM for workgroups. It requires everyone to have a seat of SW Professional, but then it comes with the package. This is a great solution, because the PDM will automatically pull all the files to your local computer, and manage that for you. This will require reconfiguring your data for PDM, so it is not a small step, but then you get the additional benefit of PDM control. The workgroup package is fairly unobtrusive, but definitely requires changes to procedure.
So, if a bad network causes SW to crash, why doesn't it cause the PDM to crash? The network traffic should be nearly identical. Load a part from the network versus check a part out from the vault. The PDM doesnt' have some magical alternative to TCP/IP. Furthermore, if you work for a company such as I do, local machines are NOT backed up. So, unless I want to handle backups myself for our 20 or so SW users, we'll be keeping everything on the network.

My personal opinion is that most of the problem with SW2008/9 are related to the new user interface. When you start drawing your own title bars and window buttons and adding non-standard button styles, you are asking for problems. If you look at it logically, 99% of the input SW sees is button clicks and key presses. The overall disk and network I/O operations (ignoring the low level read/write stuff) is small in comparison. Rarely do I see SW crash or hang when I'm *not* at the wheel.

This also explains why some people crash more often than others. Everyone has a different way of pointing and clicking. This is also *very* difficult to isolate, test and resolve.

Using SW2007 we had very few problems. We moved to 2009 and the crashes/glitches increased by a factor of 10.

NO OTHER CHANGES HAVE BEEN MADE.

Same workstations. Same network setup. Same number of users pointing and clicking the same way they always have. How can anyone possibly think that the responsibility for the crashes and hangs lies anywhere other than SW?

Jim S.
Like • Show 0 Likes0
Actions

Instability of Solidworks 2009

Outcomes

Related Content

Recommended Content