Does anyone know whether the 'unhandled error' and subsequent crash to
desktop problem been solved yet. This is now becoming a major pain,
just lost a whole afternoon's work (I was working on a drg and
switched off backup etc because of speed problems).
Feel like contacting my VAR and asking them to pay for lost time!


While I'm here I might as well get some other things of my chest.
SW2004 is soooooo slow in drg mode..... thanks SW!

I don't want all these new bells and whistles, I just want a stable
piece of software!

Cosmos Xpress for example shows how a part may deflect under load but
doesn't tell you by how much...... whats the point?

There's a lot more but I'm going to stop now, blood pressure has gone
too high....... I do feel a bit better.

Bob MacGregor

you worked an entire afternoon on a drawing without saving?

bill

"Bob MacGregor" <rmcgregor.uk@wentworthlabs.com> wrote in message
news:2f08ee1f.0402100838.4a0dd064@posting.google.com...
> Does anyone know whether the 'unhandled error' and subsequent crash to
> desktop problem been solved yet. This is now becoming a major pain,
> just lost a whole afternoon's work (I was working on a drg and
> switched off backup etc because of speed problems).
> Feel like contacting my VAR and asking them to pay for lost time!
>
>
> While I'm here I might as well get some other things of my chest.
> SW2004 is soooooo slow in drg mode..... thanks SW!
>
> I don't want all these new bells and whistles, I just want a stable
> piece of software!
>
> Cosmos Xpress for example shows how a part may deflect under load but
> doesn't tell you by how much...... whats the point?
>
> There's a lot more but I'm going to stop now, blood pressure has gone
> too high....... I do feel a bit better.
>
> Bob MacGregor

Have you updated to SP2.1?  This was to address speed and a few other
issues.

Keith

"Bob MacGregor" <rmcgregor.uk@wentworthlabs.com> wrote in message
news:2f08ee1f.0402100838.4a0dd064@posting.google.com...
> Does anyone know whether the 'unhandled error' and subsequent crash to
> desktop problem been solved yet. This is now becoming a major pain,
> just lost a whole afternoon's work (I was working on a drg and
> switched off backup etc because of speed problems).
> Feel like contacting my VAR and asking them to pay for lost time!
>
>
> While I'm here I might as well get some other things of my chest.
> SW2004 is soooooo slow in drg mode..... thanks SW!
>
> I don't want all these new bells and whistles, I just want a stable
> piece of software!
>
> Cosmos Xpress for example shows how a part may deflect under load but
> doesn't tell you by how much...... whats the point?
>
> There's a lot more but I'm going to stop now, blood pressure has gone
> too high....... I do feel a bit better.
>
> Bob MacGregor

This is a good place to vent, Bob, and a lot more.  You can learn a lot
here and get your questions answered by experts . . . and some
non-experts (like me).  Welcome BACK to the newsgroup.  Perhaps you
should lurk here more often.  You would have already known the answer to
the slow drawing performance issue.

Best regards,
Mark 'Sporky' Stapleton
WaterMark Design, LLC
Charlotte, NC
www.h2omarkdesign.com (will be up tomorrow -- not there today)

Bob MacGregor wrote:
> 
> Does anyone know whether the 'unhandled error' and subsequent crash to
> desktop problem been solved yet. This is now becoming a major pain,
> just lost a whole afternoon's work (I was working on a drg and
> switched off backup etc because of speed problems).
> Feel like contacting my VAR and asking them to pay for lost time!
> 
> While I'm here I might as well get some other things of my chest.
> SW2004 is soooooo slow in drg mode..... thanks SW!
> 
> I don't want all these new bells and whistles, I just want a stable
> piece of software!
> 
> Cosmos Xpress for example shows how a part may deflect under load but
> doesn't tell you by how much...... whats the point?
> 
> There's a lot more but I'm going to stop now, blood pressure has gone
> too high....... I do feel a bit better.
> 
> Bob MacGregor

There is some workaround method of getting the deformation data. I believe
it involves creating an eDrawing which should create an "analysis file"
containing the deflections of each node in a text form. Unfortunately, my
memory is not that good and I couldn't figure it out by tinkering. I'll bet
a good search of the NG would bring you the answer or maybe someone here
remembers.

JJ

"Bob MacGregor" <rmcgregor.uk@wentworthlabs.com> wrote in message
news:2f08ee1f.0402100838.4a0dd064@posting.google.com...
> Does anyone know whether the 'unhandled error' and subsequent crash to
> desktop problem been solved yet. This is now becoming a major pain,
> just lost a whole afternoon's work (I was working on a drg and
> switched off backup etc because of speed problems).
> Feel like contacting my VAR and asking them to pay for lost time!
>
>
> While I'm here I might as well get some other things of my chest.
> SW2004 is soooooo slow in drg mode..... thanks SW!
>
> I don't want all these new bells and whistles, I just want a stable
> piece of software!
>
> Cosmos Xpress for example shows how a part may deflect under load but
> doesn't tell you by how much...... whats the point?
>
> There's a lot more but I'm going to stop now, blood pressure has gone
> too high....... I do feel a bit better.
>
> Bob MacGregor

"JJ" <jayjay1@comcast.net> wrote in message
news:NYadnc4SF6mbqbTdRVn-uw@comcast.com...
> > Cosmos Xpress for example shows how a part may deflect under load but
> > doesn't tell you by how much...... whats the point?
> >
> There is some workaround method of getting the deformation data. I believe
> it involves creating an eDrawing which should create an "analysis file"
> containing the deflections of each node in a text form. Unfortunately, my
> memory is not that good and I couldn't figure it out by tinkering. I'll
bet
> a good search of the NG would bring you the answer or maybe someone here
> remembers.

I'm not sure this still works, but when CosmosXpress came out, it would
create a text output file for each job and save it with the suffix .OUT. If
you open that file with a text editor, like Notepad, you can find the
maximum deflection (it's in meters, no matter what units you are working
in). If that's what you are looking for, you are in luck. If the deflection
you are looking for is some where else and you aren't too fussy, you might
be able to get close enough by scaling from a print of the deflected shape.


Jerry Steiger
Tripod Data Systems

bill allemann wrote:
> you worked an entire afternoon on a drawing without saving?

I've donw that.  Many times.  I have, in the past, had 10+ work in 
progress models open and did't save them all day.  Of course, these days 
I do save and save often.  Anyone who thinks saving every few minutes 
should be the norm is nuts.  Good software doesn't crash.  Period.

Jim S.

I don't think it is crazy to plan for the unexpected. It would be ideal if
software never crashed, if power interruptions never occurred, and if
computers never hiccupped. None of these things should happen, but they do.
To deny this and to not precautionary measures is nuts.


JJ



"Jim Sculley" <niceguyj@wisdomteeth.comcast.net> wrote in message
news:c0bfun0qdt@enews4.newsguy.com...
> bill allemann wrote:
> > you worked an entire afternoon on a drawing without saving?
>
> I've donw that.  Many times.  I have, in the past, had 10+ work in
> progress models open and did't save them all day.  Of course, these days
> I do save and save often.  Anyone who thinks saving every few minutes
> should be the norm is nuts.  Good software doesn't crash.  Period.
>
> Jim S.

Bob:

The "unhandled error" is not just a single problem, it could be a 
hundred different things.  If you want to fix the problem, the best 
thing is to try to isolate the cause.  There is a crash troubleshooting 
document on the SW FAQ, and an on-line Troubleshooter that may or may 
not help you find the cause.  

You might want to consider calling your VAR before you get this worked 
up instead of only to complain after the fact.  Sometimes they can help 
you solve problems like these.

Possible causes:

SolidWorks software
SolidWorks data (part, assy, drw files corrupt)
bad install (sometimes due to antivirus software)
other questionable software installed causing conflicts
temp directory too full
bad virtual memory settings
corrupted registry (try to log on as new user)
Novell network
Windows network slow
hardware drivers
RBP syndrome (rapid or random button pushing)


Many folks have reported drawings much faster in sp2.1.

Good luck,

matt



rmcgregor.uk@wentworthlabs.com (Bob MacGregor) wrote in 
news:2f08ee1f.0402100838.4a0dd064@posting.google.com:

> Does anyone know whether the 'unhandled error' and subsequent crash to
> desktop problem been solved yet. This is now becoming a major pain,
> just lost a whole afternoon's work (I was working on a drg and
> switched off backup etc because of speed problems).
> Feel like contacting my VAR and asking them to pay for lost time!
> 
> 
> While I'm here I might as well get some other things of my chest.
> SW2004 is soooooo slow in drg mode..... thanks SW!
> 
> I don't want all these new bells and whistles, I just want a stable
> piece of software!
> 
> Cosmos Xpress for example shows how a part may deflect under load but
> doesn't tell you by how much...... whats the point?
> 
> There's a lot more but I'm going to stop now, blood pressure has gone
> too high....... I do feel a bit better.
> 
> Bob MacGregor

Thanks for the tips guys I'll look into them when I finish this
project.
Also got this info from John Picinich @ CADimensions thought I'd post
it for other people.

**************************************************************************
Cosmos Express Deflection: Does it or doesn't it?

Note: This subject was brought up during our introductory OKSWUG
meeting.
There were
differing opinions, so here is information you may find useful. This
is more
or less a Newsletter
Tutorial.

Using Cosmos Express (Included free inside of SolidWorks 2003), you
can get
a pretty picture of
a deflected part, based on Force or Pressure criteria you specify. The
typical depiction of
deflected or stressed parts in analysis software is to exaggerate it.
Cosmos
Express gives you this
representation, but doesn't really tell you what the true deflection
is. Or
do they?

After you do a Run Analysis, you can SAVE the data by clicking the
Close
button. After saving,
there will be several files with the part name (with "COSMOSXpress
Study"
after it) as the
filename, with varying extensions ("partfile-COSMOSXpress Study.out",
"partfile-COSMOSXpress Study.mas", etc.). We need to OPEN the file
with the
OUT extension ("partfile-COSMOSXpress Study.out") in Notepad. In the
middle
of the file, in the "Load Case 1" section,
you will see something like the following listed:

Minimum/Maximum Displacements

X-displ. 		Y-displ. 		Z-displ.
Node: 	106 			106 			211
Min.: 	-0.00038138 	-0.054787 		-1.0483e-005
Node: 	1294 			2201 			1071
Max.: 	0.00038140 		1.2401e-006 	1.0500e-005

Maximum Magnitude of Displacement
Node: 	106
Max.: 	0.054789

For a simple one-way, or maximum, deflection analysis, you can use the
"Maximum Magnitude
of Displacement" and grab the Max. Value listed there. This is the
Maximum
Deflection,
according to SolidWorks. But SolidWorks does all its measuring in
METERS
(does all it's
Angular Degrees in RADIANS, in case you wondered). To convert this to
Inches, you take the
Max. Value (0.054789) times 1000 (1000mm in a Meter) divided by 25.4
(mm in
an Inch). Thus
the equation would be as follows:

0.054789 * 1000 / 25.4 = 2.157047 inches for this example.

If you have multiple deflections from multiple loadings, you need to
subtract the Maximum and
Minimum values from the direction you are interested in, either X, Y,
or Z.
in the example above,
the X and Z directions basically zero themselves out, and don't, due
to
compressions and such in
the material during loading, or so I am told.

Hopefully this is beneficial for some of you. If you find this
information
hard to follow, not so
educational, or just plain wrong, let me know.

Craig Milligan
craig@okswug.com
*******************************************************************************

Good luck.
bill


"Jim Sculley" <niceguyj@wisdomteeth.comcast.net> wrote in message
news:c0bfun0qdt@enews4.newsguy.com...
> bill allemann wrote:
> > you worked an entire afternoon on a drawing without saving?
>
> I've donw that.  Many times.  I have, in the past, had 10+ work in
> progress models open and did't save them all day.  Of course, these days
> I do save and save often.  Anyone who thinks saving every few minutes
> should be the norm is nuts.  Good software doesn't crash.  Period.
>
> Jim S.

Jim,

>snip<

>Good software doesn't crash.  Period.

Very few examples of this, and none of them are parametric solid modelers.
All of them crash "Period". Even Pro-E on UNIX.

The only program (of any complexty) I use that doesn't crash is Mastercam. A
big reason for this is that it does'nt use MS components, especially the
memory "mangler". You tell it how much memory it can use and it grabs it,
and isolates it.

Regards

Mark

Mark M wrote:
> Jim,
> 
> 
>>snip<
> 
> 
>>Good software doesn't crash.  Period.
> 
> 
> Very few examples of this, and none of them are parametric solid modelers.
> All of them crash "Period". Even Pro-E on UNIX.

Parametric solid modelers are a tiny, *tiny* fraction of the software 
market.  There are far more complex programs that don't crash.

> 
> The only program (of any complexty) I use that doesn't crash is Mastercam. A
> big reason for this is that it does'nt use MS components, especially the
> memory "mangler". You tell it how much memory it can use and it grabs it,
> and isolates it.

Sounds reasonable.  Every Java program can be told how much memory it is 
allowed to have as well.

Jim S.

-- 
Remove my extraneous mandibular appendages to reply via email.

Jim,

> Parametric solid modelers are a tiny, *tiny* fraction of the software
> market.  There are far more complex programs that don't crash.

Hmmmm... Can you give me an example ? Even FEA programs are less complex
than modern solid modelers. They deal with huge amounts of numeric data, but
this data is much simpler in structure.

Regards

Mark

Mark M wrote:
> Jim,
> 
> 
>>Parametric solid modelers are a tiny, *tiny* fraction of the software
>>market.  There are far more complex programs that don't crash.
> 
> 
> Hmmmm... Can you give me an example ? 

Any database system.

Google.

Telephone switching software.

High traffic websites.

Imagine something like Solidworks having to support thousands of 
concurrent users.

Jim S.

"Jim Sculley" wrote:
> Mark M wrote:
> >>Parametric solid modelers are a tiny, *tiny* fraction of the software
> >>market.  There are far more complex programs that don't crash.
> > Hmmmm... Can you give me an example ?
> Any database system.
> Google.
> Telephone switching software.
> High traffic websites.

These applications manage (huge amounts of) relatively simple data
structured in a quite well known manner. User interaction is predictable and
limited (buttons, texts...)

Solid Modelers and CAD use complex data structures (API has more than 100
different classes...) which evolve in an explosion of unpredictable ways.
How many different solid+surface+multibody parts can you generate with 2
sketches (each containing a single circle) and, say, 3 features ? I'm pretty
sure no one knows, and it would take months to test them all...

I never saw a clear requirement of MTBF for a CAD. What would be
"accepatable" for you ? One crash per day ? one per week ?
-- 
Philippe Guglielmetti - www.dynabits.com

I have to agree with Matt, about a Novell network. It does not work too well
with Windoze Xp, that is why we scrapped Novell.

"Bob MacGregor" <rmcgregor.uk@wentworthlabs.com> wrote in message
news:2f08ee1f.0402100838.4a0dd064@posting.google.com...
> Does anyone know whether the 'unhandled error' and subsequent crash to
> desktop problem been solved yet. This is now becoming a major pain,
> just lost a whole afternoon's work (I was working on a drg and
> switched off backup etc because of speed problems).
> Feel like contacting my VAR and asking them to pay for lost time!
>
>
> While I'm here I might as well get some other things of my chest.
> SW2004 is soooooo slow in drg mode..... thanks SW!
>
> I don't want all these new bells and whistles, I just want a stable
> piece of software!
>
> Cosmos Xpress for example shows how a part may deflect under load but
> doesn't tell you by how much...... whats the point?
>
> There's a lot more but I'm going to stop now, blood pressure has gone
> too high....... I do feel a bit better.
>
> Bob MacGregor

> These applications manage (huge amounts of) relatively simple data
> structured in a quite well known manner. User interaction is predictable
and
> limited (buttons, texts...)
>
> Solid Modelers and CAD use complex data structures (API has more than 100
> different classes...) which evolve in an explosion of unpredictable ways.
> How many different solid+surface+multibody parts can you generate with 2
> sketches (each containing a single circle) and, say, 3 features ? I'm
pretty
> sure no one knows, and it would take months to test them all...
>
> I never saw a clear requirement of MTBF for a CAD. What would be
> "accepatable" for you ? One crash per day ? one per week ?


Phillippe,

My point exactly. A solid model file has several layers of variable data
which are driven and controlled by complex mathematics. This is true for a
single part file. Once you start adding mating relationships, in-context
features, etc., the complexity can grow exponentially.

Not trying to make a case for sloppy software or anything. It's just that
I've been using this stuff since the mid to late 80's (around Pro-E V7 or
8). It just seems to be the nature of the beast.

Regards

Mark

FWIW, I gotta agree. I don't want to antagonize anyone who is having a hard
time. We've probably all lost data due to crashing and it is extremely
frustrating. But, like many of you, I've worked with many CAD programs over
the years and they all crash now and then. I don't expect that will ever
change. It goes well beyond the company's development priorities and their
lack of concern for existing customers.

This doesn't mean that it couldn't be better, even much better. It doesn't
mean that people have no right to critique, complain, vent, and etcetera.
But if you have a zero tolerance for bugs then you are going to be forever
banging your head against a wall. It is better to accept that some crashing
is inevitable and to save your work regularly. Off soap box.

JJ


"Mark M" <markm@dont.email.me> wrote in message
news:c0gc13$vfj$1@www.omnica.com...
>
> > These applications manage (huge amounts of) relatively simple data
> > structured in a quite well known manner. User interaction is predictable
> and
> > limited (buttons, texts...)
> >
> > Solid Modelers and CAD use complex data structures (API has more than
100
> > different classes...) which evolve in an explosion of unpredictable
ways.
> > How many different solid+surface+multibody parts can you generate with 2
> > sketches (each containing a single circle) and, say, 3 features ? I'm
> pretty
> > sure no one knows, and it would take months to test them all...
> >
> > I never saw a clear requirement of MTBF for a CAD. What would be
> > "accepatable" for you ? One crash per day ? one per week ?
>
>
> Phillippe,
>
> My point exactly. A solid model file has several layers of variable data
> which are driven and controlled by complex mathematics. This is true for a
> single part file. Once you start adding mating relationships, in-context
> features, etc., the complexity can grow exponentially.
>
> Not trying to make a case for sloppy software or anything. It's just that
> I've been using this stuff since the mid to late 80's (around Pro-E V7 or
> 8). It just seems to be the nature of the beast.
>
> Regards
>
> Mark
>
>

Philippe Guglielmetti wrote:
> "Jim Sculley" wrote:
> 
>>Mark M wrote:
>>
>>>>Parametric solid modelers are a tiny, *tiny* fraction of the software
>>>>market.  There are far more complex programs that don't crash.
>>>
>>>Hmmmm... Can you give me an example ?
>>
>>Any database system.
>>Google.
>>Telephone switching software.
>>High traffic websites.
> 
> 
> These applications manage (huge amounts of) relatively simple data

'Simple' by whose standards?  The Google developers might look at the SW 
file format and find it laughably simplistic.

> structured in a quite well known manner. 

Now, that would be the essence of good design wouldn't it?  If SW 
doesn't have their data structured in a well known manner (even if only 
known to SW internally) things are much worse than I thought.


> User interaction is predictable and limited (buttons, texts...)

Uhm, user interaction in SW is no more complex than any other piece of 
software.  Just what actions do you think are more complex in SW?

> 
> Solid Modelers and CAD use complex data structures 

As do most software applications.


> (API has more than 100
> different classes...) which evolve in an explosion of unpredictable ways.

You consider 100 classes to be alot?  The Java API consists of several 
thousand public classes and hundreds more internal classes.  Most 
enterprise programming projects consist of thousands of classes in 
addition to the libraries they use.

> How many different solid+surface+multibody parts can you generate with 2
> sketches (each containing a single circle) and, say, 3 features ? I'm pretty
> sure no one knows, and it would take months to test them all...

If it is properly designed, you don't need to test them all.  The 
boundary between a sketch and something generated from that sketch 
should be well defined.  If it isn't, there is a problem.

> I never saw a clear requirement of MTBF for a CAD. What would be
> "accepatable" for you ? One crash per day ? one per week ?

Zero crashes.  Period.  Anything less is a miserable failure.  A crash 
represent a core software design flaw.  No operation or combination of 
operations should leave a system in such as state that it must terminate.

Mark M wrote:

>>These applications manage (huge amounts of) relatively simple data
>>structured in a quite well known manner. User interaction is predictable
> 
> and
> 
>>limited (buttons, texts...)
>>
>>Solid Modelers and CAD use complex data structures (API has more than 100
>>different classes...) which evolve in an explosion of unpredictable ways.
>>How many different solid+surface+multibody parts can you generate with 2
>>sketches (each containing a single circle) and, say, 3 features ? I'm
> 
> pretty
> 
>>sure no one knows, and it would take months to test them all...
>>
>>I never saw a clear requirement of MTBF for a CAD. What would be
>>"accepatable" for you ? One crash per day ? one per week ?
> 
> 
> 
> Phillippe,
> 
> My point exactly. A solid model file has several layers of variable data
> which are driven and controlled by complex mathematics. 

Well known mathematics.


> This is true for a single part file. 

Or a heuristic search of 1 billion indexed web pages.

> Once you start adding mating relationships, in-context
> features, etc., the complexity can grow exponentially.

So complexity cannot be had without crashes?  This simply isn't true. 
Even if it were true, the answer is to *decrease* the complexity.

For example, mating relationships have been made out to be more complex 
than they really are.  The gentleman in the office across from mine has 
written some VB code to analyze mates and tell you the true DOF of the 
assembly.  His humble opinion is that SW has botched mating in a variety 
of ways.

> 
> Not trying to make a case for sloppy software or anything. It's just that
> I've been using this stuff since the mid to late 80's (around Pro-E V7 or
> 8). It just seems to be the nature of the beast.

For CAD maybe.  But then most CAD companies don't have to try very hard. 
   A CAD company can screw things up for a long, long, long time before 
an appreciable number of users jump ship.  Doing so is painful, simply 
because their data is held hostage.

Complexity does not equate to more crash-prone.  Crashes are caused by 
design flaws.  Claiming that complexity causes crashes is like 
suggesting that Einstein is lucky to have not poked his own eye out 
doing all those complex calculations with pen and paper.

Jim S.

> Zero crashes.  Period.  Anything less is a miserable failure.  A crash
> represent a core software design flaw.  No operation or combination of
> operations should leave a system in such as state that it must terminate.


OoooK.....

Good luck on your quest for the Grail....



Mark

>The "unhandled error" is not just a single problem, it could be a
hundred different things.<

Although this may be true, I have been getting the "unhandled error"
on the rate of several times per hour after upgrading to SP2.1.  With
SP0 I maybe got it once a week. There is something with this SP that
causes that crash more.

pope

It seems very simple then.
You have no choice but to quit using solid modeling software.  Zero, Period
....

Problem solved.

Have a nice day.
Bill



"Jim Sculley" <niceguyj@wisdomteeth.comcast.net> wrote in message
news:c0gggp01ufp@enews2.newsguy.com...
> Philippe Guglielmetti wrote:
> > "Jim Sculley" wrote:
>snip
> Zero crashes.  Period.  Anything less is a miserable failure.  A crash
> represent a core software design flaw.  No operation or combination of
> operations should leave a system in such as state that it must terminate.

"pope" <costales@yahoo.com> wrote in message
news:ee528e79.0402121602.1c731ddb@posting.google.com...
> >The "unhandled error" is not just a single problem, it could be a
> hundred different things.<
>
> Although this may be true, I have been getting the "unhandled error"
> on the rate of several times per hour after upgrading to SP2.1.  With
> SP0 I maybe got it once a week. There is something with this SP that
> causes that crash more.


On the other hand, I think we're getting about the same number of crashes
per day on 2.1 as we were on SP0 (roughly 0-4, sometimes spiking up to 7 or
8, but usually only when we get something repeatable). Did your work change
in any way about the time you went to SP2.1?

Jerry Steiger
Tripod Data Systems

bill allemann wrote:
> It seems very simple then.
> You have no choice but to quit using solid modeling software.  Zero, Period

Spoken like a true sheep.

Jim S.

-- 
Remove my extraneous mandibular appendages to reply via email.

Keep swinging at those windmills Don Scully! :-)

JJ


"Jim Sculley" <niceguyj@wisdomteeth.comcast.net> wrote in message
news:3fOdndvKhrrRqrHdRVn-hA@comcast.com...
> bill allemann wrote:
> > It seems very simple then.
> > You have no choice but to quit using solid modeling software.  Zero,
Period
>
> Spoken like a true sheep.
>
> Jim S.
>
> --
> Remove my extraneous mandibular appendages to reply via email.

I would be willing to put money on the fix being related to your system, 
set up or installation rather than regressions in the sp. 

I'm not crash free, I had an ugly one last night at a user group 
presentation, but my crashes are limited to 1-2 per week using sweeps and 
lofts, surfacing and sheetmetal.  I don't work much with large assemblies.  
These are seemingly random unreproducible crashes, although I have noticed 
one pattern.  When I see double icons in the upper left or upper right of 
the SW window, I know a crash will happen if I just keep working.

anyway, good luck.

matt



costales@yahoo.com (pope) wrote in 
news:ee528e79.0402121602.1c731ddb@posting.google.com:

>>The "unhandled error" is not just a single problem, it could be a
> hundred different things.<
> 
> Although this may be true, I have been getting the "unhandled error"
> on the rate of several times per hour after upgrading to SP2.1.  With
> SP0 I maybe got it once a week. There is something with this SP that
> causes that crash more.
> 
> pope

"Keith Streich" <keiths@pflow.com> wrote in message news:<402918c2$0$13233$39cecf19@news.twtelecom.net>...

> Have you updated to SP2.1?  
> 
> Keith
> 
> "Bob MacGregor" <rmcgregor.uk@wentworthlabs.com> wrote in message
> news:2f08ee1f.0402100838.4a0dd064@posting.google.com...
>\el like contacting my VAR and asking them to pay for lost time!
> >
> >
> > While I'm here I might as well get some other things of my chest.

> > I don't want all these new bells and whistles, I just want a stable
> > piece of software!
> >
> > Bob MacGregor

Hummm....If I were to use the engineering method of failure and
productivity analysis, I might be tempted to ask if you have tried the
obvious & downgraded back to SolidWorks 2003 SP5?

Bo
boNoSpam@tilikum.com

matt, jerry,

I can't think of what is different with  my setup after i installed
SP2.1.  I probably exaggerate on my crashes. Sometimes it does happen
once every hour, but for instance I haven't had a crash all day and
it's almost 1:00.  I do run large assemblies, and it does seem to
happen then.  Sometimes though it will happen in a medium sized
assembly.  I can't seem to draw any connections and it happens so
suddenly.  Needless to say, I save my drawings non-stop.

I remember using  Microstation and the drawings would always become
corrupt. There was even some software developed to repair the corrupt
drawings. And this was on an Intergraph workstation running Unix!

Wayne

On Fri, 13 Feb 2004 00:24:59 GMT, "bill allemann"
<custom4173@sbcglobalDOTnet.invalid> wrote:

>
>It seems very simple then.
>You have no choice but to quit using solid modeling software.  Zero, Period
>...
>
>Problem solved.
>
>Have a nice day.
>Bill
>
>
>
>"Jim Sculley" <niceguyj@wisdomteeth.comcast.net> wrote in message
>news:c0gggp01ufp@enews2.newsguy.com...
>> Philippe Guglielmetti wrote:
>> > "Jim Sculley" wrote:
>>snip
>> Zero crashes.  Period.  Anything less is a miserable failure.  A crash
>> represent a core software design flaw.  No operation or combination of
>> operations should leave a system in such as state that it must terminate.