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).
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).