Let me start by clarifying that this only applies to x86. The reason for this is that on x86 the first field on a CONTEXT (more info at http://msdn.microsoft.com/en-us/library/ms679284 ) structure is a flag with the value 0x1003f.


More often than I desire I get memory dumps (in hang mode) when an exception occurs and someone complains their application is not working for the last 24 hours. Before I throw the ball back and ask crash dumps I always give it a shot to see if I’m lucky enough and the memory dump collected contains any remains or clues that would allow me to explain or get closer to the resolution of the problem.


I´m not covering managed exceptions. To those you can use SOS or the recently released psscor2 (http://www.microsoft.com/downloads/details.aspx?FamilyID=5c068e9f-ebfe-48a5-8b2f-0ad6ab454ad4&displayLang=en). As a side note I highly recommend psscor2 if you are debugging managed code. For more info on this extension and commands, give a look at Tom blog (http://blogs.msdn.com/b/tom).


Now, back to our scenario. Whenever an exception occurs, the CONTEXT is pushed on the stack so our goal would be to see if any traces of 0x1003f still exist on stack. Below is an example using s (search memory). For more information on s command please refer to debugging tools for windows help.


0:003> ~*e s -d esp L-1000 0x1003f

0115e400  0001003f 00000000 00000000 00000000  ?...............


Now take the yellow address above and use .cxr to set context


0:003> .cxr 0115e400 

eax=0115e6cc ebx=004824d0 ecx=00000003 edx=00000000 esi=10256b48 edi=0115e75c

eip=762dfbae esp=0115e6cc ebp=0115e71c iopl=0         nv up ei pl nz na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206


762dfbae c9              leave


Let’s look at the stack after using .cxr


# ChildEBP RetAddr 

00 0115e71c 10209499 kernel32!RaiseException+0x58

01 0115e75c 0040ed8c msvcrtd!_CxxThrowException+0x39

WARNING: Stack unwind information not available. Following frames may be wrong.

02 0115fc60 00415dab mod1+0xed8c

03 0115fc68 00425bd3 mod1+0x15dab

04 0115fe4c 00421e85 mod1+0x25bd3

05 0115ff54 1020bf53 mod1+0x21e85

06 0115ff88 762ed0e9 msvcrtd!_threadstartex+0x73

07 0115ff94 76fa19bb kernel32!BaseThreadInitThunk+0xe

08 0115ffd4 76fa198e ntdll!__RtlUserThreadStart+0x23

09 0115ffec 00000000 ntdll!_RtlUserThreadStart+0x1b


Just for reference this thread stack is


00 0115fe58 76fc4780 ntdll!KiFastSystemCallRet

01 0115fe5c 762e9990 ntdll!ZwDelayExecution+0xc

02 0115fec4 762a1c6c kernel32!SleepEx+0x62

03 0115fed4 00430948 kernel32!Sleep+0xf

WARNING: Stack unwind information not available. Following frames may be wrong.

04 0115ff54 1020bf53 mod1+0x30948

05 0115ff88 762ed0e9 msvcrtd!_threadstartex+0x73

06 0115ff94 76fa19bb kernel32!BaseThreadInitThunk+0xe

07 0115ffd4 76fa198e ntdll!__RtlUserThreadStart+0x23

08 0115ffec 00000000 ntdll!_RtlUserThreadStart+0x1b


So, bottom line if you are lucky enough J some info might still be present and give clues to the issue being debugged.