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.
Now take the yellow address above and use .cxr to set context
Let’s look at the stack after using .cxr
Just for reference this thread stack is
So, bottom line if you are lucky enough J some info might still be present and give clues to the issue being debugged.