Difference between revisions of "Debugging Minidumps on Windows"
(Initial version giving basic overview and describing requirements, most importantly that you need both exe and pdb files) |
(Clear up setup so it works even when the paths in the minidump are from the user's computer) |
||
| Line 16: | Line 16: | ||
Next, setup Visual Studio to find the binaries and pdb files: | Next, setup Visual Studio to find the binaries and pdb files: | ||
| − | * | + | * Extract the pdb files and the bin/ directory into a single directory. |
| − | * | + | * Go to Tools -> Options ... and select the Debugging -> Symbols items from the tree on the left. Add a new item to the list and fill it in with the path to the pdb files extracted from the dbg zip files acquired in the above steps. |
| − | Finally, open the minidump file in Visual Studio and 'Run' the dump file. It should start a debugging session, associate the loaded modules with the binaries and debug symbols you just setup, and then look just as if you hit an error when debugging normally. | + | Because the binaries are in the same directory as the PDBs, telling Visual Studio about the PDB files is sufficient. Finally, open the minidump file in Visual Studio and 'Run' the dump file. It should start a debugging session, associate the loaded modules with the binaries and debug symbols you just setup, and then look just as if you hit an error when debugging normally. |
| + | |||
| + | {{note}} If you aren't getting a real stack trace, check the 'Modules' tab for the Sirikata binaries. If it shows paths with a * in front of them, that means it can't find both the PDB and the corresponding executable. Make sure you have them all in the same directory and that permissions are correct. This usually happens if you are debugging somebody else's crash -- you'll notice that it uses paths from their computer. | ||
Latest revision as of 20:59, 2 January 2012
Overview
To facilitate debugging of crashes for users, we use Breakpad to collect crash reports. Breakpad uses Microsoft's minidump format. Minidumps are small compared to core dumps, but require additional information to debug.
We've built a very simple service for collecting these dumps (found in tools/crashcollector) which also collects the necessary information when a build is generated. The crashcollector is able to generate backtraces based on byproducts from the build process. However, sometimes it is useful to load up a crash from Windows in Visual Studio because it can sometimes do a better job of generating a stack trace and frequently gives more detailed information about local variables.
Debugging a Minidump
You need three things to debug a minidump:
- The minidump itself. Grab it from wherever you store crash reports, or for Sirikata releases find the minidump you're trying to debug on crashes.sirikata.com.
- The original binaries. For a Sirikata release you just need the regular release package found at http://sirikata.com/releases/win32/
- PDB files for the original binaries. These are found in the dbg files associated with each release. They are also at http://sirikata.com/releases/win32/ and for sirikata-x.y.z-win32.zip they will be in sirikata-x.y.z-win32.dbg.zip
The pdb files contain the debugging information -- instead of requiring you to strip the binaries, Visual Studio stores debug information in a separate file from the actual executable.
Next, setup Visual Studio to find the binaries and pdb files:
- Extract the pdb files and the bin/ directory into a single directory.
- Go to Tools -> Options ... and select the Debugging -> Symbols items from the tree on the left. Add a new item to the list and fill it in with the path to the pdb files extracted from the dbg zip files acquired in the above steps.
Because the binaries are in the same directory as the PDBs, telling Visual Studio about the PDB files is sufficient. Finally, open the minidump file in Visual Studio and 'Run' the dump file. It should start a debugging session, associate the loaded modules with the binaries and debug symbols you just setup, and then look just as if you hit an error when debugging normally.
If you aren't getting a real stack trace, check the 'Modules' tab for the Sirikata binaries. If it shows paths with a * in front of them, that means it can't find both the PDB and the corresponding executable. Make sure you have them all in the same directory and that permissions are correct. This usually happens if you are debugging somebody else's crash -- you'll notice that it uses paths from their computer.