Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Pro/E Crashing, Without Warning


Pro/E Crashing, Without Warning

It doesn't seem to matter what version or cut of ProE I use, or what the spec of the machine I'm using ProE on may be - always at one time or another I experience the software crashing without warning. For almost eight years now this has been the case, and still to this date it's the only program I'm required to use which inexplicably and unexpectedly quits while I'm busy working with it. And I know many in the same boat. Don't get me wrong, when it works well it's a lovely CAD package and really fairly user-friendly. I do enjoy using it most of the time. But when I'm under pressure to complete my tasks and am let down yet again by my software, I often ask myself; "Why is it not possible for PTC to program in some kind of limit warning, to let the user KNOW that something is wrong before a fatal crash?". Does anyone have any suggestions? Many thanks.
This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

I have been running ProE since R17 and it is much more stable now than it was back then but the one thing we learned very early on was to "Save and save often!" It will probably be the way it always is.

I noticed a LOT more instability when I went from using the UNIX version of Pro/E to the MicroSUCK version. My SG machine hardly ever crashed. Face it, with companies going to PC's because it's "cheaper" (the bean counters don't count the lost man-hours, obviously), that's what you get. I save after EVERY major command. Don't forget to purge your frames often if you're using Intralink though.

Outline the OS version & service pack #s. What processor, how much ram, what graphics solution? What version of Pro/e and build code? You offer too little information to make anything more than broad brush suggestions. Graphics solution is a big cause of premature exits in my experience. If you are not running a true openGL graphics card (Nvidia Quadro, ATI FireGL, or similar) but trying to run w/ a fast gaming card I am not surprised you are having crashes. I know a lot of people get away with high power gaming cards just fine but I have also experienced users that, because of how many pro/e windows they keep up or even just number of other productivity apps were up had BSODs with great frequency. For the one user (R2000I^2) when I finally convinced him to put an FX1100 card in, his instability almost went away entirely. There have been really bad versions and some bad build codes historically, but for two companies that I have been involved with, WF2.0 has not been a bad version at all on Windoze. Tom

We're running wf3.0. It seems fairly stable, but I feel your pain. When you really need to finish a project fast and you click that mouse a little too quickly, then keep you fingers crossed and say a prayer. When we were using 2000i^2 you just kind of learned what combination of keys not to push, that version was a true nightmare. I learned a long time ago, you can't push this program too fast or you're asking for trouble. Slow and steady, wins the race. There's no explanation.

Maybe the problem is your RAM memory... check the memory peak when your pro-e crash...

Guys, thanks a lot for your input. Firstly, I should give my hardware/software configuration as suggested; OS: Win XP Version 2002, Service Pack 2 Processor: Pentium 4 3.2GHz RAM: 3Gb Graphics: NVIDIA Quattro FX 3000 ProE: Wildfire 2.0, date code M150 It's not the newest PC in the world but should be good enough I think. The only other program I use on this PC is the PLM software Agile e6.0. I don't even have MS Office / Outlook etc loaded on my CAD machine, I have a separate laptop for all that stuff. When using ProE I usually work with a maximum of 5 windows open, usually consisting of one main assembly (first window, industrial vehicle design) plus some of the component parts/subs of that assembly (windows 2-5). When working with drawings I keep it down to two windows open (unless the parts are very simple), one for the assembly/part and one for the related drawing. I'm always very aware of what's in RAM at any given moment and don't overload it - when moving from one large simp rep to another within an assembly, I always go via an 'Empty' rep and wipe the RAM at that point before moving on to the next working rep. The RAM rarely maxes out, usually it's the processor which spends more time at its limit. For some of the inexplicable crashes I've noticed that all it can take is one quick processor 'peak', then the software dies. I do also save often and by now rarely lose unsaved work, the delays caused by crashing are normally limited mainly to restart times on ProE/Agile - but this is still significant. As I say though, even with some years experience with this software I've yet to come across a version which is robust and reliably stable enough to 'trust'. It's a source of frustration for me - and others at my workplace - hence my rant last Thursday!

I have two AMD machines and 2 Pentium machines, the AMD's very rarely crash, using "gaming" cards the Pentiums seem very unstable and sometimes wont even open a version of a model which easily opens on the AMD.

It would be very useful tool if I get a warning and if there is still available resource to save. I think it should not be difficult to test operating systems first and then set boundaries for safe operation and to monitor system resources during regeneration. ProE gives warning but just 1 second before it crashes if crash is related with the memory. If you carefully look at bottom of screen, you can see a massage like "Fatal Memory Error" before everything dissappears. I experienced some fatal errors because of indefinite references in some features (because of deleted or suppressed parents) and assumptions done by the program. Redefining with correct references helped me to regenarate them.

There is an environment variable you can create called: ALLOW_CRASH value is TRUE. Set it up in Control Panel. It will bring a dialog when Pro is going to crash and allow you to create an error file for PTC's analysis. Unfortunately, you still cannot save your work. Regards

You should also learn how to run trail files, they can be helpful in recovering lost work from crashes. Saving often never hurts either, as suggested above.

If this has been a recurring problem like you state, it sounds like there are config settings you are carring over to each version of ProE. we have virtually the same hardware setup you have , and do not have the crash issues. If a user does crash a lot, it's ususally something in their personal and/or we had issues with old config files as well. Delete and recreate config files for Wildfire. Make sure that all the settings are valid for Wildfire. Certain older settings will cause this as well. A last resort we had with on user was to delete his Windows profile, and he finally stopped crashing.

Thanks, that might be a useful one, I'll give it a try.

If it gave you a warning, then it wouldn't be called a "crash".

Hi, at least reports from crashes should be gathered by PTC like office softs and others. Even if nothing can be done to increase the stability, a list of recurents causes should be published. On a related topic, anyone knows if it's possible to virtualize a Sun station with Unix OS on our Windows OS (or directly on a virtualize layer), and would it be usefull for ours crashes probs?

I was at a Pro Engineer convention last year and one of the metrics they try to improve between each version is the amount of time between crashes. So PTC apparently knows that it is a problem, but just try to reduce the number of crashes that occur. I have been using the software for only about three years, but get kicked out at least once a week.

Hello there, I know this is an old post. But I've had this same problem since day one using pro/e (check my post is you like: Premature Exit - The sum of all fears). We have spent lots of money in new Hardware, training, time in testing and more testing different values, parameters, solutions, options, windows configurations, video driver updates, etc... Some very fancy and some too odd. For over 4 years we have been dealing with this constant and annoying issue. Lately we’ve come up with an ultimate windows environment setting, using a Windows XP-64 system (in order to benefit the whole 16GB RAM and the 2 Quad Core Xeon processors), we installed only Pro/E on it, just that and a pdf viewer. Then we also installed a virtual box application tool. In this V-Box we installed a XP-32 system (creating a virtual hard driver, shared folders, etc). Into this V-Box we put every Windows application we regularly use, Autocad, Office, Lotus, Adobe Acrobat, All printers and plotters, etc). The idea was to completely isolate pro/e from any other application running at the same time. So when you check at the W-64 task manager, you only see 2 major applications running (other than Windows own processes), that is Pro/E and Virtual-Box. So far, our premature exit ratio has diminished greatly, from over 480 minutes lost per person at month, to eventually one or two exits at month. However, it’s a configuration hard to cope. Some people may not find it very comfortable; anyway using 2 monitors is a great advantage, as you put a Windows in each monitor. If anyone cares for further info about this, please let me know. Hope it helps you out

Ha ha, now that's the funniest thing I have seen in a long time. Another "perceived customer benefit"? I've never had control like that. We certainly have come a long way!

Never ment to put it as a joke. I don't know what you mean about the "control" nor the "perceived customer benefit" - Better be more respectful next time

Whoa, Claudio, I was not laughing at your post. Post number 10 about the "ALLOW_CRASH" variable was my focus, as noted in the subject line. I have never been able to "allow" a computer program to crash. Please accept my apologies for the misunderstanding.

Hey, Claudio, Jim got back to you just before me, but it was pretty clear that he wasn't talking about your post; it didn't make any sense; anyway, don't be so quick to take offense. Meanwhile, the solution you have come up with is very interesting. I've noticed problems before when other applications are running (e.g. Microsoft Word) at the same time as Pro. What you are doing is a great idea even though you would hope it wouldn't be necessary. I agree also that it's a great setup to run with two monitors.

Hello Jim, David. Ok, no problem them. Sorry if I was so picky, but I've been in such situations before, so I reacted offensive. Anyway... Well the only thing is that this solution is on our own risk (so to speak), as you can imagine such configuration is not approved from ptc, so if we eventually come with any further issue that needs to contact ptc, they will allege it to be responsible. But I'm glad to know that you find it interesting, good to say is working so far (knock on wood) Regards

@Recai you may try this to watch memory usage Regards Reinhard
Attention: Creo 7.0 Customers
Please consider upgrading
End of Life announcement here.

NEW Creo+ Topics:
PTC Control Center
Creo+ Portal
Real-time Collaboration