Analyze -v

The debugger defines a set of pseudo registers, which can be used in expressions and always evaluate to certain special values. The full list of pseudo registers can be found here, but thought I’d highlight a few in their own post.

Always remember to prefix the pseudo register name with the @ symbol so that WinDBG knows you’re specifying a register name. If you don’t, be prepared to be punished when you fat finger the register name and WinDBG goes into a tailspin trying to resolve it!

$pagesize

This register contains the page size for the target platform. Most of us are only using the x86 and x64 so this will always evaluate out to 4K, but if you’re scripting better to use the pseudo register to be future proof.

$thread

The current ETHREAD address.

$peb

The current Process Environment Block addres.

$teb

The current Thread Environment Block address.

$ptrsize

The pointer size of the target machine.

$p

This one I love. $p contains the result of the previous Display Memory (d) command. For example, I can dump out a memory block and then evaluate a new expression using the contents of the memory location:

Back before the dps command was introduced this was the easiest way to evaluate a jump through a driver’s Import Address Table when you didn’t have symbols for the driver:

Under the Debugger Command Program Examples section of the debugger documentation, there’s a nifty example script that will walk the current process list and print the process name and address. Only problem is that if you run the script you’ll get the following:

Luckily the fix to the script is easy, the name of the alias defined doesn’t match the name of the alias used. In order to fix the script, the following line:

.echo ${$ImageName} at ${$Procc}

Thread specific breakpoints are a feature that I wasn’t aware of for a while but have become an important part of my debugging toolbox.

As it turns out, the bp command takes a /t switch, which allows you to specify the address of the thread object that you want to set the breakpoint for. By that I mean that the breakpoint will only fire if the address specified is executed by the thread specified. This is helpful if you have a routine in your driver called from multiple threads and you’re trying to narrow down the behavior of a particular thread. Example usage would be:

bp /t 86033858  ntfs!ntfscommoncreate

This will set a breakpoint on an incredibly hot routine in the system (the open handler for NTFS) but will only break into the debugger if the breakpoint is hit by thread 0×86033858.

As an added tip, this command can be combined with the $thread pseudo register, which always evaluates to the current thread:

bp /t @$thread ntfs!ntfscommoncreate

There are a couple of interesting commands that can provide insight into symbol issues that you’re having. Perhaps you’re running an extension command that is failing mysteriously even though you’re sure that you have symbols loaded? Enter .show_sym_failures and .show_read_failures, which spit error messages out when a symbol can’t be resolved or read. They are to be documented in a future release of the WinDBG docs, but until then:

.show_sym_failures
/s           Enable Display of Symbol Lookup Failures
/S           Disable Display of Symbol Lookup Failures

/t           Enable Display of Type Lookup Failures
/T           Disable Display of Type Lookup Failures

.show_read_failures
/v           Enable Display of Read Errors
/V           Disable Display of Read Errors