Блог

У меня есть dll, которая выходит из строя с исключением нарушения доступа(0xC0000005), но каждый раз, когда я получаю аварийный дамп, это происходит во время GC.

Использование процессора составляет 81%, и несколько источников говорят, что это тот случай, когда выполняется GC. Затем в отчете DebugDiag отображается следующее предупреждение: следующие потоки ожидают завершения сборки мусора .net.Поток 274 запустил сборку мусора.Поток сборщика мусора не начнет выполнять свою работу до тех пор, пока не завершатся выполнение потоков, у которых отключен упреждающий сборщик мусора. В следующих потоках отключена упреждающая GC 274.

Также в DebugDiag есть это предупреждение для потока, который выдает нарушение доступа: Обнаружена возможная блокировка или утечка критического раздела в lt;адрес_хереgt;lt;адрес_хереgt; Я поискал здесь несколько похожих потоков, но пока не повезло. У кого-нибудь была проблема или есть идеи, как ее расследовать?

Мне интересно, вызвана ли проблема с нарушением доступа в моем коде c в результате зависания GC.

 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```