A couple weeks ago I was talking to a couple developers from other companies. We were talking about the debugger, which is always one of my favorite topics of discussion. They said one thing very surprising – they didn't get how they could look at a minidump in Visual Studio. Sometimes, when you have been using something for years, it is difficult to understand what is intuitive, and what isn't. This was definitely one of those cases. Anyway, I decided that minidumps needed some more publicity.
A minidump is a file that describes the state of a process. For some problems, they totally kick ass. When you have a user or a tester complaining about a hang or crash, they make life so much easier. That user or tester can send you a small file, and you might be able to figure out what went wrong. Even if you can't figure out the problem, you will at least be able to determine where to start looking for a repro, or which developer needs to look at the problem.
A minidump contains a list of modules with enough information for the debugger to find the module, a list of threads with their context, and whatever memory the tool that wrote the dump decided to include. Sometimes minidumps really are 'mini' – they only include the stacks of every thread. Other times minidumps can be hundreds of megabytes because they include all user mode memory in the process space. There are three common types of minidumps:1. Stacks Only2. All user mode memory 3. Stacks + CLR data
In Whidbey (VS 2005):
Someday, I hope that we will automatically start debugging so that you won't have to hit F5. Before Whidbey, you have to also set the MODPATH. However, in Whidbey, we got it right and we use your symbol path for locating modules. To set your symbol path, go to Tools->Options->Debugging->Symbols. If your process has managed code, you have a harder time. This is because the regular managed debugging APIs don't work with mindumps. So instead you are forced to use sos.dll. This will be fixed in some future version of Visual Studio.
There are a bunch of tools to generate them. You can generate them from Visual Studio using 'Debug->Save Dump As…'. Set the file format to control what you want in the dump. You can generate them from windbg/ntsd/cdb using '.dump /m <filename>'. This is the most useful command that windbg has because it allows you to take a look at the problem in a better debugger :). The error reporting in Office/Windows/Visual Studio/etc is also based on generating minidumps.
You can also generate a minidump from your application. For instance, you could generate a minidump whenever asserts fire. You would do something like this:
RaiseException(0xffffffff, 0, 0, NULL);
int GenerateDump(EXCEPTION_POINTERS *pExceptionPointers)
[Updated September 28th, 2004] MiniDumpWriteDump with the Whidbey CLR and the latest dbghelp will contain CLR data. The beta 1 CLR wrote minidumps that were not very small. This should be improved before Whidbey releases.