Site Tools


Crash Dump Analysis

C++

Version: Rhino 4
Summary: Discusses how to analyze crash dump files in Visual Studio.

If Rhino crashes, two files are created on your desktop: RhinoCrashDump.dmp and RhinoCrashDump.3dm. The .3DM file is Rhino's last ditch effort to save the model. The .dmp file can be used in Visual Studio to find the place in the source code where a Rhino plug-in crashed.

More information

Analyzing crash dumps is not a quick and easy way to diagnose crash bugs. If a crash is repeatable, do not use crash dumps. Simply debug the crash by running the command in the debugger.

In a crash dump, no heap is available and only a limited amount of stack is available. But with a little effort and thought, you can find the line where the crash occurred and see what arguments were passed to the functions.

Keep in mind you are debugging optimized code. Some values of local variables (like loop counters and frequently used doubles) are kept in CPU registers and cannot be viewed in a watch window.

If you read a RhinoCrashDump.dmp file in Notepad.exe and search for “RHINOCRASHINFO” you will find a block of text like the following:

 <RHINOCRASHINFO>
   <BUILD VERSION="YYYY-MM-DD" DATE="mmm dd yyyy" TIME="hh:mm"ss" />
   <COMMAND NAME="..." UUID="..." />
   <EXECUTABLE FILENAME="..." UUID="..." />
 </RHINOCRASHINFO>

If the crash happens in a command that is in a plug-in, the name of the plug-in's .RHP file is in <EXECUTABLE FILENAME> and the id is in <EXECUTABLE UUID>.

<BUILD DATE> and <BUILD TIME> are the date and time the .cpp file that contains the crash dump exception handling code was compiled.

Analyzing a crash

Step 1. Determine which build of Rhino crashed

Open the RhinoCrashDump.dmp“ file in Notepad.exe and search for RHINOCRASHINFO. Then look for B u i l d V e r s i o n = ” YYYY - MM - DD “… YYYYMMDD is the build that crashed. If you are lucky, the other RHINOCRASHINFO values will give you a hint about what crashed. Common Rhino build versions are:

 2008-02-06 - Rhino 4.0 SR3
 2007-10-17 - Rhino 4.0 SR2 Hot Fix 1 (in this case the BuildVersion is 2007-10-17 like SR2 but the CompileDate = Dec 18, 2007...)
 2007-10-17 - Rhino 4.0 SR2
 2007-07-03 - Rhino 4.0 SR1

Step 2. Get the build of Rhino that crashed

To analyze the crash dump file, you need the build of Rhino on your system that produced the crash dump. If you do not have the same build, download it from the Rhino web site.

Step 3. Copy files

After you determine the version of the crashed Rhino, copy the RhinoCrashDump.dmp into the same directory as the Rhino4.exe file. In most cases, this will be the following folder:

 C:\Program Files\Rhinoceros 4.0\System

Over your plug-in's life, you are likely to see many crashes. So do yourself a big favor and rename the RhinoCrashDump.dmp file something descriptive.

Also, copy your plug-in's release .RHP and .PDB files into the same folder.

Critical To be successful in performing crash dump analysis, save your release build .PDB files to use later. Without your plug-in's .PDB file, crash dump analysis is useless.

Step 4. Locate the crash

Start a new instance of Developer Studio and from the menu use:

 File > Open Solution...

to bring up the Open Solution dialog box. In the Files of type: droplist box select Dump files (.dmp; .mdmp). Then navigate to the Rhino System folder and double-click on RhinoCrashDump.dmp. It may also be possible to double-click on the .dmp file from Explorer and have Developer Studio open it.

Once the dump is loaded (it doesn't take long), press the F10 key. When you are prompted to save RhinoCrashDump.sln, click the Save button. The Output window will pop up and you can watch as the debugger attempts to reconstruct the state of the executable when the crash occurred. This can take a while, especially if the debugger has to go to an external symbol server to download symbols.

Eventually an error message box will pop up with Break/Continue/Ignore/Help buttons. Click Break and examine the call stack for hints about what when wrong.

Microsoft Symbol Server

You must have symbol information when you debug applications with various Microsoft tools. Symbol files provide a footprint of the functions contained in executable files and dynamic-link libraries (DLLs). Also, symbol files can present a roadmap of the function calls that lead to the failure point. For example, you must have the symbols when you dump call stacks inside a debugger.

The Microsoft Symbol Server is built by using the SymSrv technology (SymSrv.dll) provided with the Debugging Tools for Windows package. SymSrv builds a local symbol cache for fast, automatic symbol resolution.

You can use the symbol server to allow Visual Studio to automatically download the proper Microsoft symbols for debugging your Visual Studio project. To allow Visual Studio to use the Microsoft Symbol Server, select Tools→Options and fill in the information listed below.

Try this yourself

Below is a sample C++ plug-in that will crash Rhino. To test out crash dump analysis, download and build the plug-in. Then, launch Rhino and load the plug-in using the PlugInManager command. Then run the TestSdkCrash command. While the McNeel Error Reporting dialog displays, copy the RhinoCrashDump.dmp from the desktop to another location, and then click Don't Send. Then follow the steps above to analyze the crash dump.

http://en.wiki.mcneel.com/content/upload/files/TestSdkCrash.zip

developer/crashdumpanalysis.txt · Last modified: 2016/01/05 by sandy