Memory dumps come in two flavors user mode dumps or kernel mode dumps. The user mode dumps is a snapshot of a process and the memory it addresses, kind of like stopping at a break point while your debugging in Visual Studio, but you do not have the ability move forward. For deep analysis of crash dumps WinDbg is probably the most flexible tool but it can be a little intimidating for beginners to start using. There are a few alternatives out there but I would like to propose Visual Studio as the first stop for crash dump analysis.
What is a crash?
For crash scenarios there is really only a few different things that might be going on, the most common by far being are unhandled exceptions. This is where the exception occurs but it is not placed in a try catch block and it is allowed to go up the stack and it becomes what we refer to as a second chance exception which will, inevitably, crash the process. If your applications is using ASP.NET there is a good chance that your unhandled exception will get swallowed by the framework, thereby permitting the developer to safely show off an error page rather than wait for the w3wp process to restart.
Additionally OutOfMemoryException, StackOverflowException and ExecutionEngineException can cause crashes without going to 2nd chance. StackOverflowException and OutOfMemoryException are both cases where there is insufficient space for a function to handle the exception. In contrast the ExecutionEngineException is typically a bug in the framework, I am not sure how common these are and truth be told I have never witnessed one.
Handling a crash dump with Visual Studio
I am going to capture my crash dump using procdump with a command like this (6344 is the process id):
procdump.exe -e -ma 6344
Over the years Visual Studio has gotten pretty good with memory dumps, this is especially true when you have your symbols and source code lined up with the dump. If you were more inclined to to use WinDbg you might execute the !ClrStack command which will show a list of the call stacks for every thread, allowing you to manually look for a stack that ended with the 2nd chance exception.
This is much more straightforward with Visual Studio, once you have opened up the dump file click the Debug with Managed Only button on the right side of the summary page and it will automatically open the source at the location of the exception, on the the correct thread and the Call Stack, Watch and Immediate windows will all be active.
This is a simple example but given all the information restored to your Locals window it might be clearer what was directly responsible for the crash in the first place.
Comments are closed.