James Finnigan : debugging

How to stop WinDbg from going crazy and loading all the symbols

jamesfinnigan — Mon, 04 Jun 2007 17:00:00 GMT

One of my favorite features of WinDbg is that it doesn't load all the symbols up-front. That's a huge part of what makes it so much faster than Visual Studio. However, every once in a while you can do things that cause WinDbg to go crazy and load all the symbols in a desperate attempt to resolve a symbol that it just isn't finding. Oftentimes this is because of a typo, or because you forgot to scope the symbol to a module. It's annoying - but it's not something that you have to live with.

To tell WinDbg not to do it's whole-hog symbol search use this command:

.symopt+ 100

If you find yourself in a situation where you don't want to wait for the debugger to finish resolving symbols before issuing the command, you can just start windbg with the -snul parameter. In some cases, the reason this is happening is some goofy breakpoint you set, or something in your watch window - it's not going away. If you don't want to take the time to track it down, you can bail on the workspace by starting windbg with the -WX parameter, and saving whatever you put into the first one.

Here's what the documentation has to say on the topic:

SYMOPT_NO_UNQUALIFIED_LOADS
This symbol option disables the symbol handler's automatic loading of modules. When this option is set and the debugger attempts to match a symbol, it will only search modules [whose symbols] have already been loaded.
This option can be used as a defense against mistyping a symbol name. Normally, a mistyped symbol will cause the debugger to pause while it searches all unloaded symbol files. When this option is active, a mistyped symbol will not be found in the loaded modules, and then the search will terminate.
This option is off by default. It can be activated by using the -snul command-line option. Once the debugger is running, it can be turned on or off by using .symopt+0x100 or .symopt-0x100, respectively

All postings are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Breaking when the instruction pointer leaves the module

jamesfinnigan — Thu, 31 May 2007 19:00:59 GMT

The problem is to skip out of a kernel driver that we don't have symbols for - what's the best way to break on calls out of that driver.

If you used pc (step until the next call instruction), you would hit calls that are inside that driver.

Here's another approach (using an example from Pavel Lebedynskiy) - step until the ip address moves outside that module:

.while (@eip > fee50000 & @eip < feef1000) { t; reip }

If you want to skip the output, you can use setting the instruction pointer instead like we did in the last post using a .while trick.

All postings are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Finding where a bad HRESULT is returned

jamesfinnigan — Thu, 31 May 2007 08:38:38 GMT

I've looked at this a couple times, but here's another way to break when the error code you're looking at is being returned.

.while(@eax != 0xc0000005) { t ; reax }

If you want to avoid the output noise, you can do something like this:

.while(@eax != 0xc0000005) { t ; r @eip = @eip}; r eax

All postings are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

How to only break on a jump when it will be taken

jamesfinnigan — Thu, 31 May 2007 08:22:37 GMT

Here's a question that came up a work a little bit back - thought I would share the result around.

There is a coding pattern (that I don't ever really use so I may be messing it up) that works like this:

T1 res1;
T2 res2;
T3 res3;

res1 = GetRes1();
if (!res1) goto Cleanup;

res2 = res1.GetRes2();
if (!res2) goto Cleanup;

res3 = res2.GetRes3();

Cleanup:
if (res3) CleanupRes3(res3);
if (res2) CleanupRes3(res2);
if (res1) CleanupRes3(res1);

So what if you wanted to break when you are at Cleanup because res2 was null? You can set a breakpoint with a conditional that will only break when the jump to Cleanup from res2 is going to be taken. You could base it on the symbols and do the comparison yourself. However, in optimized code the debuggers understanding of local variable information is often incorrect (the compiler doesn't emit enough information in the pdb to make this possible). In that case, it may be most convenient to make a conditional breakpoint using the x86 flags (described in detail in the help file that comes with windbg under the topic x86 Architecture).

Here's an example:

ntdll!RtlUnlockModuleSection+0x23a:
77937c71 8b4590          mov     eax,dword ptr [ebp-70h]
77937c74 6683785c01      cmp     word ptr [eax+5Ch],1
77937c79 7416            je      ntdll!RtlUnlockModuleSection+0x25a (77937c91)
0:000> bu ntdll!RtlEncodePointer+0x21a ".if (@ZF=1) { gc } "
0:000> g
ChildEBP RetAddr
WARNING: Stack unwind information not available. Following frames may be wrong.
0011f678 77945ad7 ntdll!RtlEncodePointer+0x21a
0011f6e4 7794a980 ntdll!RtlGetNtVersionNumbers+0x83
0011f6f4 00000000 ntdll!LdrInitializeThunk+0x10
eax=00000002 ebx=7ffde000 ecx=779a00dd edx=77970f34 esi=00000000 edi=779d5d14
eip=77944bef esp=0011f534 ebp=0011f678 iopl=0         nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000             efl=00000202
ntdll!RtlEncodePointer+0x21a:
77944bef 740d            je      ntdll!RtlEncodePointer+0x229 (77944bfe) [br=0]

ZF=1 is the flag for a comparison (which is a subtraction that sets flags) that was equal (so a subtraction would naturally result in 0 - setting the zero flag). In this second example we're interested in breaking when it is not equal, so we used gc (to continue execution) when ZF=1.

Cheers!

James

Locating the file that a function (not on the stack) was written in

jamesfinnigan — Sat, 11 Nov 2006 04:47:13 GMT

This question came up in one of the internal aliases a couple days ago. While debugging, how do I find the source for a particular function that is not on the stack? There are a couple caveats to consider first:

You must have symbols that include source information (public symbols have this information stripped out of them)
You must have turned on loading source information.

To satisfy #2, first run .lines -e and then you have several choices:

use ln with name of the function

0:000> ln RuntimeTest!CUIElementName::CUIElementName
d:\dev\acw\enduser\nuiux\acw\activecontentwizard\unmanaged\property.cpp(1593)
(00857050) RuntimeTest!CUIElementName::CUIElementName | (008570e0) RuntimeTest!CUIElementName::AddRef
Exact matches:
RuntimeTest!CUIElementName::CUIElementName (void)

use u with the name of the function

0:000> u RuntimeTest!CUIElementName::CUIElementName
RuntimeTest!CUIElementName::CUIElementName [d:\dev\acw\enduser\nuiux\acw\activecontentwizard\unmanaged\property.cpp @ 1593]:
00857050 8bff mov edi,edi
00857052 55 push ebp
...

use lsa with the name of the function and then lsc

0:000> lsa RuntimeTest!CUIElementName::CUIElementName
...
1590: }
1591:
1592: CUIElementName::CUIElementName()
> 1593: {
...
0:000> lsc
Current: dev\acw\enduser\nuiux\acw\activecontentwizard\unmanaged\property.cpp(1599)