The minidump file format contains data about a crash on Windows. It is used by Breakpad and also by various Windows debugging tools.
Using the MS Visual Studio debugger
- set up the debugger to use the Mozilla symbol server
- install the relevant release of Firefox (for example from here), and add the directory it is in (e.g., "C:\Program Files\Mozilla Firefox 3.6 Beta 1\") to the same dialog in which you set up the symbol server (in case the binary location in the minidump is not the same as the one on your machine). Note that you can install the relevant release anywhere. Just make sure to configure the symbol server to the directory where you installed it.
- Get the source for that release of Firefox
- make sure the minidump has the .dmp file extension (that is, rename it from *.dump to *.dmp)
- double-click on the minidump file to open it in the debugger
- when it loads, click the green icon in the visual studio debugger toolbar that looks like a play button
- When the first source file is loaded, you will need to tell the debugger where your corresponding source tree is.
Then you'll be able to examine:
- the stack trace
- The debugger shows the stack trace. You can right-click on any frame in the stack, and then choose "go to disassembly" or "go to source". (Choosing "go to dissassembly" from the source view might not get you to the right place due to optimizations.) When looking at the source, beware that the debugging information will associate all inlined functions as part of the line into which they were inlined, and compiler (with PGO) inlines very aggressively (including inlining virtual functions). You can often figure out where you really are by reading the disassembly.
- In the Registers tab (Debug -> Windows -> Registers if you don't have it open), you can look at the registers associated with each stack frame, but only at the current state (i.e., the time of the crash). Registers that Visual Studio can't figure out will be grayed-out and 00000000.
- stack memory
- You open a window (Memory 1, etc.) that shows contiguous segments of memory using the Debug -> Windows -> Memory menu item. You can then enter the address of the stack pointer (ESP register) in this window and look at the memory on the stack. (The minidump doesn't have the memory on the heap.) It's a good idea to change the "width" dropdown in the top right corner of the window from its default "Auto" to either "8" or "16" so that the memory display is word-aligned. If you're interested in pointers, which is usually the case, you can right click in this window and change the display to show 4-byte words (so that you don't have to reverse the order due to little-endianness). This view, combined with the disassembly, can often be used to reconstruct information beyond what in shown the function parameters.
- local variables
- In the Watch 1 (etc.) window (which, if you don't have open, you can get from Debug -> Windows -> Watch), you can type an expression (e.g., the name of a local variable) and the debugger will show you its value (although it sometimes gets confused). If you're looking at a pointer to a variable that happens to be on the stack, you can even examine member variables by just typing expressions. If Visual Studio can't figure something out from the minidump, it might show you 00000000 (is this true?).
Manually unwinding the stack in a minidump
Sometimes unwinding the stack doesn't work very well. In those case you can resort to doing it by hand. Here's what I do.
- Grab breakpad
- Apply this http://people.mozilla.com/~jmuizelaar/breakpad-print.patch
- Run minidump_dump on the minidump file
- You should get a dump of values on the stack of the crashing thread
- Figuring out where xul.dll and any other dlls you care about are mapped. xul.dll is usually at 0x10000000.
- Look for any values that look like they are in the range of where xul.dll is mapped. Assume these are return addresses
- Get the symbol file for xul.dll. Search xul.sym for a FUNC area that contains the return symbol. Assume that this is the caller
- Rinse and repeat.
If you have any questions or need any help with this ask Jeff Muizelaar
Getting a stack trace from a crashed B2G process
- Get the minidump file in the phone at /data/b2g/mozilla/*.default/minidump/. You can use adb pull for that.
- Build the debug symbols using the command ./build.sh buildsymbols inside the B2G tree. The symbol files will be generated in $OBJDIR/dist/crashreporter-symbols.
- Build and install google-breakpad.
- Use the minidump_stackwalk breakpad tool to get the stack trace.
Example: $ cd B2G $ adb pull /data/b2g/mozilla/*.default/minidump/*.dmp . $ls *.dmp 71788789-197e-d769-67167423-4e7aef32.dmp $ minidump_stackwalk 71788789-197e-d769-67167423-4e7aef32.dmp objdir-debug/dist/crashreporter-symbols/