Quick tips: Is there any exception out there ?
Hello,
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 https://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 (https://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 (https://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
kernel32!RaiseException+0x58:
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.
Bruno