How do I retrieve Register Context from AccessViolationException?

Question

I have a x64 crash dump of a managed (C#) application that p/invokes to native code. The dump was taken after the native code attempted to dereference a bad memory location, and after the .NET marshaler had turned it into an AccessViolationException. As a result, the stack frame where the error occurred is no longer available, and the thread where the exception occurred is now hijacked by the CLR exception handler:

0:017> kb
 # RetAddr           : Args to Child                                                           : Call Site
00 000007fe`fd3b10dc : 00000000`0402958b 00000000`20000002 00000000`00000e54 00000000`00000e4c : ntdll!NtWaitForSingleObject+0xa
01 000007fe`ea9291eb : 00000000`00000000 00000000`00000cdc 00000000`00000000 00000000`00000cdc : KERNELBASE!WaitForSingleObjectEx+0x79
02 000007fe`ea929197 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!CLREventWaitHelper2+0x38
03 000007fe`ea929120 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!CLREventWaitHelper+0x1f
04 000007fe`ead8cae5 : 00000000`29cbc7c0 00000000`3213ce40 00000000`00000000 00000000`ffffffff : clr!CLREventBase::WaitEx+0x70
05 000007fe`ead8c9d0 : 00000000`29cbc7c0 00000000`00000000 00000000`0002b228 00000000`0002b228 : clr!Thread::WaitSuspendEventsHelper+0xf5
06 000007fe`eacf2145 : 00000000`007ea060 000007fe`ea924676 00000000`00000000 000007fe`fd3b18da : clr!Thread::WaitSuspendEvents+0x11
07 000007fe`eaccc00c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!Thread::RareEnablePreemptiveGC+0x33a905
08 000007fe`eae2c762 : 00000000`00000000 00000000`007cbce0 00000000`29cbc7c0 00000000`00000001 : clr!Thread::RareDisablePreemptiveGC+0x31b40c
09 000007fe`eaf662d4 : 00000000`00000000 00000000`007cbce0 00000000`29cbc7c0 00000000`00000000 : clr!EEDbgInterfaceImpl::DisablePreemptiveGC+0x22
0a 000007fe`eaf66103 : 00000000`29cb0100 00000000`00000000 00000000`3213cf80 00000000`29cbca20 : clr!Debugger::SendExceptionHelperAndBlock+0x174
0b 000007fe`eaf65d0d : ffffffff`ffffffff 00000000`29cbca20 00000000`29cbc700 000007fe`eaf62100 : clr!Debugger::SendExceptionEventsWorker+0x343
0c 000007fe`eaf61bd8 : 00000000`00000100 00000000`00000000 00000000`00000019 00000000`3213dd01 : clr!Debugger::SendException+0x15d
0d 000007fe`eadac75d : 00000000`007cbce0 00000000`3213d258 00000000`3213d1e8 00000000`00000001 : clr!Debugger::LastChanceManagedException+0x1f8
0e 000007fe`eaf698c7 : 000075ce`2b30e018 00000000`00000000 00000000`00000001 00000000`00000000 : clr!NotifyDebuggerLastChance+0x6d
0f 000007fe`eaf6af20 : 00000000`00000000 000007fe`8cf40020 000007fe`8cfa200c 4328fffe`43e0fffe : clr!Debugger::UnhandledHijackWorker+0x1a7
10 000007fe`eaaacbf0 : 00000000`0000000a 00000000`2ab23e30 00000000`00000001 00000000`00000000 : clr!ExceptionHijackWorker+0xc0
11 00000000`3213d8c0 : 00000000`3213ddb0 00000000`00000001 00000000`00000000 00000000`0000000b : clr!ExceptionHijack+0x30
12 00000000`3213ddb0 : 00000000`00000001 00000000`00000000 00000000`0000000b 00000000`0035578c : 0x3213d8c0
13 00000000`00000001 : 00000000`00000000 00000000`0000000b 00000000`0035578c ffffffff`00000002 : 0x3213ddb0
14 00000000`00000000 : 00000000`0000000b 00000000`0035578c ffffffff`00000002 00000000`00350268 : 0x1

And .exr -1 (display most recent exception) returns:

0:017> .exr -1
ExceptionAddress: 00000000771d685a (user32!ZwUserMessageCall+0x000000000000000a)
   ExceptionCode: 80000004 (Single step exception)
  ExceptionFlags: 00000000
NumberParameters: 0

The call to user32!ZwUserMessageCall is at the top of the stack of thread 0, not 17 where the native exception occurred, so I can only assume it's not pointing to my exception.

I can dump the access violation exception to get some info about the native error:

0:017> !DumpObj /d 0000000012175640
Name:        System.AccessViolationException
MethodTable: 000007fee9a61fe8
EEClass:     000007fee9528300
Size:        176(0xb0) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
000007fee9a50e08  4000002        8        System.String  0 instance 000000001217b538 _className
000007fee9a5b218  4000003       10 ...ection.MethodBase  0 instance 0000000000000000 _exceptionMethod
000007fee9a50e08  4000004       18        System.String  0 instance 0000000000000000 _exceptionMethodString
000007fee9a50e08  4000005       20        System.String  0 instance 0000000012179818 _message
000007fee9a61f18  4000006       28 ...tions.IDictionary  0 instance 0000000000000000 _data
000007fee9a51038  4000007       30     System.Exception  0 instance 0000000000000000 _innerException
000007fee9a50e08  4000008       38        System.String  0 instance 0000000000000000 _helpURL
000007fee9a513e8  4000009       40        System.Object  0 instance 0000000012179ad0 _stackTrace
000007fee9a513e8  400000a       48        System.Object  0 instance 0000000012179c68 _watsonBuckets
000007fee9a50e08  400000b       50        System.String  0 instance 0000000000000000 _stackTraceString
000007fee9a50e08  400000c       58        System.String  0 instance 0000000000000000 _remoteStackTraceString
000007fee9a53980  400000d       88         System.Int32  1 instance                0 _remoteStackIndex
000007fee9a513e8  400000e       60        System.Object  0 instance 0000000000000000 _dynamicMethods
000007fee9a53980  400000f       8c         System.Int32  1 instance      -2147467261 _HResult
000007fee9a50e08  4000010       68        System.String  0 instance 0000000000000000 _source
000007fee9a54a00  4000011       78        System.IntPtr  1 instance                0 _xptrs
000007fee9a53980  4000012       90         System.Int32  1 instance       -532462766 _xcode
000007fee9a02d50  4000013       80       System.UIntPtr  1 instance                0 _ipForWatsonBuckets
000007fee9a3d210  4000014       70 ...ializationManager  0 instance 0000000012179900 _safeSerializationManager
000007fee9a513e8  4000001        0        System.Object  0   shared           static s_EDILock
                                 >> Domain:Value  00000000007e09b0:NotInit  <<
000007fee9a54a00  400018a       98        System.IntPtr  1 instance      7fedad179f4 _ip
000007fee9a54a00  400018b       a0        System.IntPtr  1 instance fffffffc2ab22078 _target
000007fee9a53980  400018c       94         System.Int32  1 instance                0 _accessType

From this I see the instruction address that failed (7fedad179f4) and the address that the code tried to dereference (fffffffc2ab22078). It appears to be a sign extension or overflow bug somehow, but it's not obvious in the code how that might have happened. The instruction referenced is:

0:017> u 7fedad179f4
MYDLL!_interpolate+0x174 [c:\my\source\file.c @ 85]:
000007fe`dad179f4 f3450f59548404  mulss   xmm10,dword ptr [r12+rax*4+4]

To debug this further, I need the register context from when the native code crashed to see what was in r12 and rax. Is this possible to retrieve?

---

Edit: I tried to get information about the parameters to ExceptionHijackWorker, but the values don't make sense to me. The function signature according to @S.T.'s link is

void STDCALL ExceptionHijackWorker(T_CONTEXT * pContext,
                                   EXCEPTION_RECORD * pRecord,
                                   EHijackReason::EHijackReason reason,
                                   void * pData);

So a first parameter of 0000000a doesn't make sense as a pointer. And dumping the second parameter 000000002ab23e30 yields nonsensical data for the EXCEPTION_RECORD:

0:017> dd 000000002ab23e30
00000000`2ab23e30  00000019 00000019 2ab23e40 00000000
00000000`2ab23e40  42b8f800 42b8de00 42b89b00 42b85000
00000000`2ab23e50  42b81b00 42b7a000 42b72600 42b6fa00
00000000`2ab23e60  42b6a000 42b67a00 42b63600 42b59c00
00000000`2ab23e70  42b4fc00 42b4da00 42b49e00 42b46a00
00000000`2ab23e80  42b38e00 42b31c00 42b2d600 42b29000
00000000`2ab23e90  42b2ec00 42b2fa00 42b2a000 42b27a00
00000000`2ab23ea0  42b23e00 42b6e800 42b6ab00 42b66c80

0x19 and 0x19 for the ExceptionCode and ExceptionFlags don't make sense; there is no code with that value and the flag is documented as being zero or EXCEPTION_NONCONTINUABLE, which is defined as 1.

Am I misinterpreting anything here?

Answer 1

Following advice from @S.T., I started probing around the call stack to see if I could find an exception record or context record. I started around the strangeness at the bottom of the stack, namely:

0:017> k
 # Child-SP          RetAddr           Call Site
...
0f 00000000`3213d210 000007fe`eaf6af20 clr!Debugger::UnhandledHijackWorker+0x1a7
10 00000000`3213d850 000007fe`eaaacbf0 clr!ExceptionHijackWorker+0xc0
11 00000000`3213d880 00000000`3213d8c0 clr!ExceptionHijack+0x30
12 00000000`3213d8a8 00000000`3213ddb0 0x3213d8c0
13 00000000`3213d8b0 00000000`00000001 0x3213ddb0
14 00000000`3213d8b8 00000000`00000000 0x1

I happened to find the exception record:

0:017> .exr 00000000`3213ddb0 
ExceptionAddress: 000007fedad179f4 (SMTCV!_interpolate+0x0000000000000174)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: fffffffc2ab22078
Attempt to read from address fffffffc2ab22078

And then I happened to find the context record (what I was looking for):

0:017> .cxr 00000000`3213d8c0 
rax=0000000000000019 rbx=000000000000000a rcx=00000000709c7c88
rdx=0000000000000002 rsi=000000002ab23e30 rdi=0000000080000000
rip=000007fedad179f4 rsp=000000003213dff0 rbp=0000000000000019
 r8=000007ffffe22000  r9=0000000070910000 r10=0000000000000000
r11=000000003213e0a0 r12=fffffffc2ab22010 r13=000000002b50ae40
r14=000000002ab241ec r15=0000000000000003
iopl=0         nv up ei pl nz na pe nc
cs=0033  ss=002b  ds=0000  es=0000  fs=0000  gs=0000             efl=00010200
MYDLL!_interpolate+0x174:
000007fe`dad179f4 f3450f59548404  mulss   xmm10,dword ptr [r12+rax*4+4] ds:fffffffc`2ab22078=????????

I can see my bad pointer in r12 now!

I don't understand what these stack frames are, or why the exception and context records were stored as the return address for them. Any comments on this would be great, for me and for future readers.