Finalizer bloqued hanging the application

Question

Today we received a CrashDump of an application that was hung. Running it thru DebugDiag we got the following information:

Analysis Summary

Error

Description Recommendation

The finalizer thread 5 in this WordHangs.dmp is blocked Review the callstack for the Finalizer thread to see what the finalizer is blocked on. Long running code on a Finalizer thread can increase the number of objects ready for finalization and is bad for the overall memory consumption of the process

Looking at the thread 5 we cannot identify what the thread is doing. The callstack is the following one:

Thread 5 - System ID 13636

Entry point clr!Thread::intermediateThreadProc Create time
19/04/2017 9:32:59 Time spent in user mode 0 Days 00:00:00.093 Time spent in kernel mode 0 Days 00:00:00.078

This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.

.NET Call Stack

[[DebuggerU2MCatchHandlerFrame]]

Full Call Stack

Source

ntdll!NtWaitForSingleObject+15 KERNELBASE!WaitForSingleObjectEx+98 kernel32!WaitForSingleObjectExImplementation+75
clr!CLREventBase::Reset+145 clr!CLREventBase::Reset+18d
clr!CLREventBase::WaitEx+152 clr!CLREventBase::Wait+1a
clr!Thread::WaitSuspendEventsHelper+8a
clr!Thread::WaitSuspendEvents+14
clr!Thread::RareEnablePreemptiveGC+8e
clr!Thread::RareDisablePreemptiveGC+102
clr!WKS::GCHeap::FinalizerThreadWorker+1b5
clr!Thread::DoExtraWorkForFinalizer+1bd
clr!Thread::DoExtraWorkForFinalizer+240
clr!Thread::DoExtraWorkForFinalizer+5f0
[[DebuggerU2MCatchHandlerFrame]]
clr!WKS::GCHeap::FinalizerThreadStart+1a0
clr!Thread::intermediateThreadProc+4d
kernel32!BaseThreadInitThunk+e ntdll!__RtlUserThreadStart+70
ntdll!_RtlUserThreadStart+1b

We have executed Windb with SOSEX loaded to identify any deadlock without success. This is the output generated:

0:000> !dlk Examining SyncBlocks... Scanning for

ReaderWriterLock(Slim) instances... Scanning for holders of

ReaderWriterLock locks... Scanning for holders of ReaderWriterLockSlim

locks... Examining CriticalSections... Scanning for threads waiting on

SyncBlocks... Scanning for threads waiting on ReaderWriterLock

locks... Scanning for threads waiting on ReaderWriterLocksSlim

locks... Scanning for threads waiting on CriticalSections...

*** ERROR: Symbol file could not be found. Defaulted to export symbols for MSO.DLL -

*** ERROR: Symbol file could not be found. Defaulted to export symbols for VSTOLoader.dll -

*** ERROR: Symbol file could not be found. Defaulted to export symbols for WWLIB.DLL -

*** ERROR: Symbol file could not be found. Defaulted to export symbols for WINWORD.EXE -

*** ERROR: Symbol file could not be found. Defaulted to export symbols for Csi.dll -

*** WARNING: Unable to verify checksum for aetpkss1.dll

*** ERROR: Symbol file could not be found. Defaulted to export symbols for aetpkss1.dll -

No deadlocks detected.

Can anyone show us where to look to identify why the finalizer thread was blocked?

It is blocked, but not deadlocked. Entirely normal state, it is waiting for some finalization work to be done. Hard to guess why DebugDiag is generating this diagnostic, maybe it just fingered the wrong thread. Deadlocking a thread that is using a COM server like Word is pretty easy to do, you have to look at the STA thread that owns the Application object. You've been asking a lot of questions about this, seemingly without getting anywhere. Time to call in the help of Microsoft Support. — Hans Passant, Apr 21 '17 at 12:04
Thanks Hans. The dump may show a blocked thread but in fact the application is deadlocked as it was hung at that time. You are right about Microsoft Support, I'm collecting all the information now. I will answer my own questions (hopefully) when this nightmare ends. — Ignacio Soler Garcia, Apr 24 '17 at 07:22

score 0 · Accepted Answer · answered Jan 11 '18 at 13:43

In the code we had the following call:

        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.Collect();
        GC.WaitForPendingFinalizers();

Since we removed it following this question:

Is correct to use GC.Collect(); GC.WaitForPendingFinalizers();?

the issue is gone so I guess somehow this was involved (probably this was not the culprit alone and other code was related as well).

Finalizer bloqued hanging the application

1 Answers1