A collection of windbg links, tips and tricks
- Mike Taulty’s intro is very good. Especially the stuff on setting up the symbol file path.
- windbg.info is an excellent advanced resource from Robert Kuster. The command reference and A-Z are especially recommended.
- virtualdub: very good summary of useful commands.
- stackoverflow: as ever, a rich and detailed repository
- codemachine: download windbg install kits, registry settings for minidump files
Tips & tricks
- Your PDBs must match your DLLs and EXEs. Even if you’ve built with the same set of compiler switches, they won’t match if they’re not from the same build, as the compiler injects a checksum that windbg checks. You can find some hacky ways around this on stackoverflow. But if it’s at all possible to rebuild and generate a matching set of bins and PDBs do so. You’ll find a huge amount of stuff in windbg starts just working when bins and PDBs match: breakpointing on C++ method names, variable inspection, automatic viewing of source code when stepping up and down the stack with “.frame N” etc.
- Clear down registry keys to reset windbg. For instance, if you can’t get the command window to issue g, bp, bl etc, then using regedit to clear keys can help. Delete everything under HKCU\Software\Microsoft\Windbg
- If you’re debugging a 32 bit binary, use the 32 bit debugger. Don’t attempt to make the 64 bit debugger work in 32 bit mode with the .effmach x86 command
- The .expr command will tell you if you’re using MASM or C++ style symbols. Use “.expr /s c++” to flip into C++ symbol mode if not already in that mode. Setting breakpoints and examining variables will be much easier.
- Type conflict error at ‘<EOL>’: I get this sometimes setting a breakpoint when I get a module name wrong. Check your ‘bp module!class::method’ syntax. The module is the same as the DLL name, without the .dll suffix.
System Internal Process Explorer is an essential debugging tool. Here are some common debugging scenarios that PE can resolve quickly…
- Windows gives you “permission denied” when you attempt to overwrite a DLL. You’ve got write permission, so you know some running process must have that DLL loaded. But which one? Use PE’s Find/Find Handle or DLL menu option