If you’re a software developer, chances are that you have written an application, and this application has crashed. When this happened, it probably put up a dialog that looks something like this:
How do you figure out what went wrong?
Strategy #1: Extract the minidump from Windows Error Reporting
Windows Error reporting has already created a minidump of the crash. So one way to find out what went wrong is just to look at the minidump. This works really well if your application is written in native code and there is no debugger on the machine where the crash occurs. You can use it for managed code too, but you will need to use sos.dll to analyze the dump (see MSDN). Open a command prompt (Start->Run, cmd.exe), and switch to your temp directory:
C:\Documents and Settings\greggm>cd /d %tmp%
Look for the dump file that Windows Error Reporting produced. It will have a ‘.dmp’ or ‘.mdmp’ extension and the date should be shortly after the crash happened:
Volume in drive C has no label.
Volume Serial Number is 70E3-6676
Directory of C:\DOCUME~1\greggm\LOCALS~1\Temp
05/24/2007 08:54 AM 109,570 4A88835.dmp
1 File(s) 109,570 bytes
0 Dir(s) 25,379,823,616 bytes free
Mark the file as read-only. This will prevent Windows Error Reporting from deleting the file after you dismiss the dialog:
C:\DOCUME~1\greggm\LOCALS~1\Temp>attrib +r 4A88835.dmp
Now dismiss windows error reporting and copy the dump file wherever you want. You can analyze the dump in Visual Studio by opening the dump file as a project (File->Open Project), and start debugging (F5).
Strategy #2: Access the dump from Online Crash Analysis
Microsoft has a program to allow ISVs to access the crashes in their applications that have been submitted by users. If the person experiencing the crash is a customer, this is a great way to find out what happened. See the winqual site for more information.