I have a mixed mode dll (C++/Cli) that is referenced in a C# application. It crashes with the error: name_here.dll has caused an access violation exception(0xC0000005) when trying to read from memory location 0x00000000 on thread 243.
What I have tried:
I ran DebugDiag on a crashdump and it shows that error together with the following information: GC is running in this process. The thread that triggered the GC is 274.
Then DebugDiag report shows this warning: The following threads are waiting for .net garbage collection to finish. Thread 274 triggered the garbage collection.The garbage collector thread wont start doing its work till the time the threads which have pre-emptive GC disabled have finished executing. The following threads have pre-emptive GC disabled 274.
Then there's another warning regarding the initial thread that throws the access violation, thread 243: Detected possible blocking or leaked critical section at <address_here> owned by thread 243.
Not exactly sure how to approach this or what I could be doing wrong. Anyone has had this issue. Is thread 274 causing a deadlock on itself? Any idea would be very much appreciated.
This is the stack trace for the thread that’s triggering GC:
clr!StackFrameIterator::NextRaw+4
clr!GCToEEInterface::GcScanRoots+4e3
clr!WKS::gc_heap::mark_phase+197
clr!gc_heap::gc1+a3
clr!WKS::gc_heap::garbage_collect+54c
clr!WKS::GCHeap::GarbageCollectGeneration+10d
clr!WKS::gc_heap::trigger_gc_for_alloc+2d
clr!JIT_New+4d6
[my user code here]
This is the thread that’s causing the Access Violation error:
ntdll!NtWaitForMultipleObjects+14
KERNELBASE!WaitForMultipleObjectsEx+ef
KERNELNASE!WaitForMultipleObjects+e
kernel32!WerpReportFaultInternal+4b0
kernel32!WerpReportFault+73
KERNELBASE!UnhandledExceptionFilter+23b
ntdll!RtlUserThreadStart$filt$0+38
ntdll!_C_specific_handler+96
ntdll!RtlpExecuteHandlerForException+d
ntdll!RtlDispatchException+373
ntdll!KiUserExceptionDispatch+3a
This is the stack trace for the GC thread according to DebugDiag:
ntdll!NtWaitForSingleObject+14
KERNELBASE!WaitForSingleObjectEx+8f
clr!CLREventWaitHelper2+3c
clr!CLREventWaitHelper+1f
clr!CLREventBase::WaitEx+7c
clr!WKS::gc_heap::bgc_thread_function+9f
clr!Thread::intermediateThreadProc+86
kernel32!BaseThreadInitThunk+14
ntdll!RtlUserThreadStart+21
And this is the finalizer thread:
ntdll!NtWaitForSingleObject+14
KERNELBASE!WaitForSingleObjectEx+8f
clr!CLREventWaitHelper2+3c
clr!CLREventWaitHelper+1f
clr!CLREventBase::WaitEx+7c
clr!FinalizerThread::WaitForFinalizerEvent+44
clr!FinalizerThread::FinalizerThreadWorker+54
clr!ManagedThreadBase_DispatchInner+39
clr!ManagedThreadBase_DispatchMiddle+6c
clr!ManagedThreadBaseDispatchOuter+75
clr!FinalizerThread::FinalizerThreadStart+10a
clr!Thread::intermediateThreadProc+86
kernel32!BaseThreadInitThunk+14
ntdll!RtlUserThreadStart+21
Also a lot of threads are waiting for GC to finish and they have this in their call stack:
ntdll!NtWaitForSingleObject+14
KERNELBASE!WaitForSingleObjectEx+8f
clr!CLREventWaitHelper2+3c
clr!CLREventWaitHelper+1f
clr!CLREventBase::WaitEx+7c
clr!WKS::GCHeap::WaitUntilGCComplete+2b
clr!Thread::RareDisablePreemptiveGC+180