Michael Lord

Computers can be frustrating! Let be honest!

We have all seen applications crash.  Some crashes appear to be random, other can be induced and some are reproducible.  I don’t recall an application, that I have used that hasn’t crashed at some stage.  We know there can be numerous causes of the crash!  Hardware, Operating Systems, graphic drivers, operator impatience or the software code itself!  Or any combination of those or a plethora of other reasons!

SOLIDWORKS is no exception!

I’m sure most have seen the SOLIDWORKS Error Report make an appearance after a crash.   Out of frustration many will just dismiss it.   I’m sure some will see the “What were you doing when SOLIDWORKS crashed (Optional)?” and decide to fill it in with a fair amount of sarcasm and scepticism.   Neither is really a good idea and there are very good reason why not to!

I don’t pretend to understand or can explain why but there are people within Dassault Systèmes SOLIDWORKS Corporation who can.

There is an ongoing post on the SOLIDWORKS Forum which predominately is about the stability, reliability and performance of the software.  The thread has currently moved on to crashes within the program!

Jim Wilkinson – Dassault Systèmes SOLIDWORKS Corporation – Vice President, User Experience Architecture has responded to a comment on the post and has provided a detail explanation on how the SOLIDWORKS Error Report is used and some improvement to it with SOLIDWORKS 2018.  It is a good read.

The following is Jim’s response on the post:

SOLIDWORKS is always recording information locally on  your machine about command usage, OS information, video card information, UI setup, etc. It is just not sent to SOLIDWORKS unless the user opts into the SOLIDWORKS Customer Experience Improvement Program. You can do this at install time, from the crash dialog, or at any time in Tools, Options, System Settings, General. This web page below that is linked from the installation,Tools/Options, and the crash dialog where those options are presented describes what is collected and what is not collected for privacy reasons and the fact that this does not negatively affect the performance of running the software:

SolidWorks Customer Experience Improvement Program | SOLIDWORKS

In addition, if you opt into the program, the crash reports are automatically sent when you crash. The crash dialog looks like this if you have opted into the program:

And it looks like this if you have not opted into the program:

And the crash reporting system already does something similar to what you are talking about.  Every crash report that is sent in through the crash dialog goes into a database and includes a “mini-dump” which includes information about the crash, including what module crashed and where in the module it crashed, along with other data like what commands were last run, etc. With this information, we can group like crashes together to automatically understand how many times the same crash has happened. The key factors which drive the priority within development are the total hit count on a given crash and the number of customers encountering that crash (some customers may hit the same crash multiple times, so the hit count can be higher than the number of customers).

Along with this crash data in the database, we also store the steps that the user has written into the crash dialog. You may ask why it is important to have the users manually enter steps if we already have information about what commands the user has run.  The reason is because we can’t capture the same level of detail in the data being automatically sent to us about command usage.  For instance, the automatic data sent will indicate that the extrude command was run, but it won’t have all of the information about what options were set, what selections were made, and certainly won’t have information like what the user was doing at the moment of the crash (for example, if the user was selecting a plane for input within the extrude command).   If we automatically captured this level of information it could potentially impact performance and would be huge amounts of data to send when it actually wouldn’t be as useful as the user describing the problem.

Users have asked in this thread if these steps that users write down are ever read by SOLIDWORKS…the answer is YES.   No, we don’t read every single one as they come in, but as our development team is investigating the crashes with multiple occurrences, the user steps are instrumental in helping track down the problem.   Since crash dialog reports do not include part/assembly/drawing files, it is often very difficult for us to reproduce the problem (see near the bottom of this post for information about reporting problems WITH part/assembly/drawing files).    A brief description of what you were doing, and anything unique to your model or workflow, can help us reproduce the problem.    You don’t have to write a novel here. At a minimum, please put in the last few things that you have done.    Knowing that the last step was to rotate the model with the mouse, or that you changed a part size in an assembly document and then switched back to the drawing (with just a couple of the steps before that since often it is a few steps in sequence that causes the problem) is way better than having no information at all.    If no users have put in any steps, it’s potentially like looking for a needle in a haystack…the developer is just staring at code trying to figure out what might be going wrong; sometimes there is something obviously wrong in the code, but often times, it is the complex path through the code before it got to this part of the code that causes the problem.    If multiple users have submitted steps, and there is no consistency to the steps, then that may lead the developer in one direction of investigation.    If multiple users have reported very similar, or the same steps, then the haystack gets smaller and smaller or the needle is just sitting there in plain sight.

You may ask why every single crash isn’t looked at.  Well, crashes can be caused by many things, and many of them aren’t actually caused by SOLIDWORKS.   They can be caused by issues in the OS, with the graphics card or driver, with the hardware, running out of memory, etc.    If a crash log only ever comes in once, it very likely isn’t caused by SOLIDWORKS.    If it comes in multiple times, then there is more chance it is something that we can address in our code or figure out that it is caused by a particular driver or OS DLL or something like that and then report to our partners for them to fix it.

The question came up as to whether it is important for users running older versions to send crash reports.    The answer is yes.    While a SP may not be released to address a problem in an older version since that version is no longer maintained, the data helps the developer to analyze the problem if it is still occurring on a version that is actively being maintained.   It helps for the developer to know how long the problem has been in the code so they know what change introduced the problem since they can look at the code and see what changed in the code at the time the problem started occurring.     The additional crash reports (especially when users have added steps), help the developer troubleshoot the problem, even if those steps are from an older version since the problem would probably still occur with those steps on the new version.    In the database, they can also tell how many occurrences come from each release which is additional useful information.

For reporting back to the user, starting with SOLIDWORKS 2018, you’ll notice that we are reporting the fault module in the crash dialog (see the images above).  This can be helpful to the user since if it is reporting some module frequently, especially one that might be “human recognizable” like a module name that is clearly related to the graphics card or something else in the OS, then they can pursue looking into that. As already mentioned in this thread earlier, a collection of this information over time is available in SOLIDWORK Rx under the Reliability tab.  Clicking on “Terminated unexpectedly” entries shows what is called a “Call stack” which is the fault module plus some additional information. And you’ll notice in the bottom right corner, it reports the number of sessions with the same call stack so something that may seem random can actually be seen as repeatable through this data.   We don’t expect users to become experts on this stuff, but much of this information can be very useful for VARs who are helping troubleshoot problems for users.

I have added the below image which shows what Jim explains about the Reliability Tab and “Call Stacking”

Also starting with SOLIDWORKS 2018, we have changed the crash dialog so it now has the ability to tell you if a crash is already fixed.  So, if a crash occurs and it matches a crash in our database that has already been fixed, it will have information right in the crash dialog to indicate that the problem is fixed and in what version/SP. All of this is done proactively without the need for an SPR.

All of this is dependent upon users sending in crash reports, and the results of us fixing what might seem like random crashes improves dramatically as more users add a few steps to help us troubleshoot.

And I’ll finally say, there is NO substitute for having a reproducible case with part/assembly/drawing data.  So, if something is reproducible, be sure to report it to your reseller with the data.  If you are getting a lot of frequent crashes and they seem to be random and non-reproducible, get your reseller involved.   There is very likely something that they can troubleshoot and either fix on your machine or find the common thread to get it to be reproducible so it can be sent to our teams to fix.

In cases where a persistent crashing problem is hard to pinpoint your reseller can request a “crash investigation” from the SOLIDWORKS Technical Support team, and we will assign one of our experts to work with your reseller to help troubleshoot and resolve the problem.

That is one thing I forgot to mention in my original reply and I have now edited it to add it. In SOLIDWORKS 2018, the crash dialog now does give confirmation that the information has been sent. It looks like this: