Understanding Windbg output from call stack

Question

From analyzing a crash dump in Windbg, the following is the last call on the stack (obtained using clrstack):

00000000`1eeee410 00000000`ffffffff mscorlib_ni!System.Threading.WaitHandle.WaitOne+0x23

I would like to know what do the different sections of this output imply exactly (More particularly on +0x23).

Jersey

What WinDbg command did you use to get this output? Knowing the command, and any parameters used, will help. – Municipality

What I meant by my previous comment, is whether you had to use some thing like k or kp commands, or whether you used !analyze -v – Municipality

Regards the WaitOne+0x23 portion of the call stack, it is (likely) the offset from the nearest function entry point, as explained in this Sysinternals forum post: forum.sysinternals.com/… – Municipality

It is very annoying that the k, kb, kc, kd, kp, kP, kv (Display Stack Backtrace) does not have this information or if it does it is hidden in a big blob of text. – Joan

Answer 1

You are debugging a 64 bit process so you have two pointers printed out for each frame

the first one is 000000001eeee410 - is a child stack pointer, you can read more on how you can manually use it to recover previous framews manually here http://www.codeproject.com/Articles/331050/Assembly-Helps-Debug-NET-Applications but unless you are dealing with weird corrupted state memory dumps, its not really important :)

the second one is the current instruction pointer for the frame, pointing to the assembly instruction that will be executed next. You can get a mode detailed info by disasemblying the code at this address using the !U command like this

!U /d 00000000ffffffff

Lastly, the WaitOne+0x23 means that the current asembly command being executed is located at the adress of System.Threading.WaitHandle.WaitOne method's start (which means its probably this method being executed) and an offset of 0x23 after that - since you have no symbols for mscorlib, you cant get a line number for this offset

Diesel