.NET Debugging - System.Threading.ExecutionContext.runTryCode

We have this bug that only appears 30% of the time for the Release build. Opening the crash dump in WinDbg (snipped "!analyze -v" output):

FAULTING_IP: 
+4
00000000`00000004 ??              ???

EXCEPTION_RECORD:  ffffffffffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 0000000000000004
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000008
   Parameter[1]: 0000000000000004
Attempt to execute non-executable address 0000000000000004
ERROR_CODE: (NTSTATUS) 0xc0000005 - 
   The instruction at 0x%08lx referenced memory at 0x%08lx. 
   The memory could not be %s.
WRITE_ADDRESS:  0000000000000004 
MANAGED_STACK: 
(TransitionMU)
0000000024B9E370 000007FEEDA1DD38 
   mscorlib_ni!
   System.Threading.ExecutionContext.runTryCode(System.Object)+0x178
(TransitionUM)
(TransitionMU)
0000000024B9DFB0 000007FF00439010 MyLibrary!DocInfo.IsStatusOK()+0x30

Now, IsStatusOK() just calls PrintSystemJobInfo.Get开发者_高级运维(), but that doesn't seem to even appear in the stack.

Any ideas on how to debug this? I'm sure runTryCode() is really not the problem...but..I'm stuck.

Thanks! (I'm really groping here).

A stab in the dark - but seeing as it is possibly related to printing, could it be caused by a dodgy printer driver?

Does the problem occur on different machines or only specific ones?

The access violation must be coming from native code so either the datastructures going down there are wrong or something about the definition could be. Do you p-invoke to native call methods or send datastructures to other managed methods which invoke the native ones?

As there is threading mentioned is this code running multithreaded? Is it possible that you have a threading issue where the datastructures you are using to talk to the native code are being corrupted by other threads?

Thanks everyone! Finally figured it out.

There's some native interop going on here and, the GC is apparently moving around some variables in memory. This is the one that is wreaking havoc on the Interop side. Solution: Use IntPtr or GCHandle.Alloc()

(admittedly, this answer was written in a bit of a hurry, will try to fill in a proper answer when i have time).