'Finalizer thread got blocked

I'm doing postmortem analysis on a high memory pressure .net application using WinDbg with a process dump and this process is a Windows service.

with the following output it seems the finalizer is blocked.

I've searched the code and there seems not a suspicious finalize method that's holding back the thread. what are the common patterns to look for such behavior?

Is there any other WinDBG commands that will help me to do further diagnosis?

Thanks,

0:000> ~[2]k

Child-SP          RetAddr           Call Site
00000017`fd5bf2c8 00007ffc`d340dd29 ntdll!NtWaitForSingleObject+0xa
00000017`fd5bf2d0 00007ffc`d340b6f4 ntdll!RtlpWaitOnCriticalSection+0xe1
00000017`fd5bf3a0 00007ffc`ca95ec1b ntdll!RtlpEnterCriticalSectionContended+0xa4
00000017`fd5bf3e0 00007ffc`ca7a8180 clr!CrstBase::Enter+0x119
00000017`fd5bf410 00007ffc`ca9582cc clr!ThreadStore::LockThreadStore+0x68
00000017`fd5bf440 00007ffc`ca95829b clr!Thread::CleanupDetachedThreads+0x2c
00000017`fd5bf4a0 00007ffc`ca8a603b clr!Thread::DoExtraWorkForFinalizer+0x186
00000017`fd5bf4d0 00007ffc`ca960805 clr!WKS::GCHeap::FinalizerThreadWorker+0x10c
00000017`fd5bf510 00007ffc`ca96078c clr!ManagedThreadBase_DispatchInner+0x2d
00000017`fd5bf550 00007ffc`ca9606f5 clr!ManagedThreadBase_DispatchMiddle+0x6c
00000017`fd5bf650 00007ffc`ca8eb377 clr!ManagedThreadBase_DispatchOuter+0x75
00000017`fd5bf6e0 00007ffc`ca95e8b6 clr!WKS::GCHeap::FinalizerThreadStart+0xd7
00000017`fd5bf780 00007ffc`d0d713d2 clr!Thread::intermediateThreadProc+0x7d
00000017`fd5bf840 00007ffc`d33e5454 kernel32!BaseThreadInitThunk+0x22
00000017`fd5bf870 00000000`00000000 ntdll!RtlUserThreadStart+0x34


Solution 1:[1]

The Finalizer thread in this particular dump is blocked, but that may be fine. After all, locks are entered all the time. In order to determine whether you really have a problem, you need to see how many objects are in the f-reachable queue. You can do so with !sos.finalizequeue or !sosex.frq.

Be sure to also examine the output of !sos.dumpheap to see if your problem is a memory leak instead.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Akira Yamamoto