Event handle leaks in a .NET Framework 4 based application

This article helps you resolve event handle leaks in a .NET Framework 4 based application.

Original product version:   Microsoft .NET Framework 4
Original KB number:   2973904

Summary

This issue may occur even when the application is idle. Additionally, if you examine the process of this application by using a debugging tool, the stack resembles the following in which the event handles are allocated:

ntdll!ZwCreateEvent
kernelbase!CreateEventExW+0x6e
kernelbase!CreateEventW+0x27
clr!CLREvent::CreateManualEvent+0x3b
clr!Thread::AllocHandles+0xa3
clr!Thread::CreateNewOSThread+0x85
clr!Thread::CreateNewThread+0xa9
clr!ThreadpoolMgr::CreateUnimpersonatedThread+0xbb
clr!ThreadpoolMgr::CreateWorkerThread+0x19
clr!ThreadpoolMgr::EnsureEnoughWorkersWorking+0x116
clr!ThreadpoolMgr::AddWorkingWorker+0x12
clr!UnManagedPerAppDomainTPCount::DispatchWorkItem+0x266
clr!ThreadpoolMgr::NewWorkerThreadStart+0x20b
clr!ThreadpoolMgr::WorkerThreadStart+0x3d1
clr!Thread::intermediateThreadProc+0x4b
kernel32!BaseThreadInitThunk+0xe
ntdll!__RtlUserThreadStart+0x70
ntdll!_RtlUserThreadStart+0x1b

Cause

The issue occurs because the .NET Framework won't immediately reclaim the memory that is associated with these handles. The handles are reclaimed only when a Garbage Collection runs. For some applications, Garbage Collection happens rarely, because the application rarely allocates managed objects.

Resolution

To resolve this issue, upgrade from the .NET Framework 4 to the latest version of the .NET Framework 4.5.

Workaround

To work around this issue in the .NET Framework 4, call the GC.Collect() method when the application needs to reclaim the handles immediately.