A collection of windbg links, tips and tricks

Introductory material

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.

Process Explorer

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

 

2 Responses to “windbg”


  1. […] I’ve been getting into windbg while working on my POC. I’ve long been a fan of Microsoft’s Visual Studio debugger. Even back in the late 90s, when I got a serious case of Open Source Religion after falling under the spell of Eric Raymond’s Cathedral and the Bazaar, and went through an anti Microsoft phase, I never stopped rating the debugger. Visual Studio debugger is great, but windbg is a whole ‘nother thing. It’s the debugger MS use themselves for debugging Windows. Yes, the interface is a little clunky compared to the VS debugger, but the power of the command set more than compensates. It’s got it’s own scripting system built in, so you can construct custom breakpoints: for instance, break the 5th time round the loop when this int is greater than 100. And it has an API too, so the debug engine can be driven from other languages like Python. Personally, I’m really enjoying discovering the power of windbg. While I do so I’m capturing tips and tricks here. […]


  2. […] I’ve got back into low level debugging on Windows for mixed x86 & C++ code recently. Here’s my summary of useful resources: https://etrading.wordpress.com/windbg/ […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s