views:

516

answers:

2

I ran kd by mistake and got some output that inteerested me, a reference to a line of code in my module that I can't see on the call stack of any thread. The lines weren't the beginnning of the method so I don't think the reference is to a function pointer, but possibly the result of an exception being stored in memory??? Of course, that happens to be what I'm looking for...

Update:

The stack trace of the exception is:

0:000> kb
   *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr  Args to Child              
0174f168 734ea84f 2cb9e950 00000000 2cb9e950 kernel32!LoadTimeZoneInformation+0x2b
0174f1c4 734ead92 00000022 00000001 000685d0 msvbvm60!    RUN_INSTMGR::ExecuteInitTerm+0x178
0174f1f8 734ea9ee 00000000 0000002f 2dbc2abc msvbvm60!    RUN_INSTMGR::CreateObjInstanceWithParts+0x1e4
0174f278 7350414e 2cb9e96c 00000000 0174f2f0 msvbvm60!    RUN_INSTMGR::CreateObjInstance+0x14d
0174f2e4 734fa071 00000000 2cb9e96c 0174f2fc msvbvm60!RcmConstructObjectInstance+0x75
0174f31c 00976ef1 2cb9e950 00591bc0 0174fddc msvbvm60!__vbaNew+0x21

and into our code (create a new Form derived class)

the dds output:

0:000> dds esp-0x40 esp+0x100
0174f05c  00000000
0174f060  00000000
0174f064  00000000
0174f068  00000000
0174f06c  00000000
0174f070  00000000
0174f074  00000000
0174f078  00000000
0174f07c  00000000
0174f080  00000000
0174f084  00000000
0174f088  00000000
0174f08c  00000000
0174f090  00000000
0174f094  00000000
0174f098  00000000
0174f09c  007f4f9b ourDll!formDerivedClass::Form_Initialize+0x10b [C:\Buildbox\formDerivedClass.frm @ 1452]

etc

which seems to indicate that Initialize is being called even though it isn't on the stack trace of either this exception or any of the threads. As suggested, it might all be a mismatch between pdbs and dlls, but it seems a coincidence that we end up in the right classes and methods

+2  A: 

Kd stands for "stack dump." From the documentation:

The kd command displays the raw stack data. Each DWORD value is displayed on a separate line. Symbol information is displayed for those lines together with associated symbols. This format creates a more detailed list than the other k* commands. The kd command is equivalent to a dds (Display Memory) command that uses the stack address as its parameter.

Try .hh to get the debugger help from inside ntsd / windbg.

See also "dds esp-0x40 esp+0x80"

jeffamaphone
So why are these stack lines there if they are not part of a call stack on a thread? Is there a command for tracing one of them back to the calling function so I can see why they are there?
Oskar
It's hard to say without seeing the output. If you're debugging optimized code (release) the stacks can get pretty funky. The debugger just tries to match of addresses with symbols--sometimes it gets it wrong. If it really makes no sense it could be stack corruption or you have the wrong symbols loaded (pdb doesn't match).
jeffamaphone
I'm pretty sure the pdbs are matching (we rebuilt the binary to get the pdbs earlier). Updating the question now with more info
Oskar
I'm not familiar with debugging VB exceptions in this way... Sorry.
jeffamaphone
A: 

Excuse me, but it looks kinda like you actually ran the "kb" command -- with a "B", not a "D". That's what appears in the session above, and the examples on http://www.debuginfo.com/articles/easywindbg.html certainly seem to produce similar output...

SamB