Why are handle counts going up in a .NET application?

[Dave Burns]

Hello,

We have a .NET application that runs as a service. Our customers have
observed, using Task Manager, that handle counts are going up after a period
of time and claim it is a leak on our part.

I have scoured the code looking for anything that I am not closing or
disposing, but don't see anything. I ran two different profiling tools and
also put in my own logging to make sure that at least at my level (in C#) I
do my part by making sure resources don't leak. My logs are steady after
days of running.

The only resources that I use are: Sockets, Threads, Files, and Timers - as
far as I can tell.

Are there resources that .NET runtime allocates on my behalf? ( I do know
about the System Thread pool )

Or is there a known handle leak in .NET that I am not aware of?

Thanks, any help on this will be greatly appreciated!

 

[dotNetDave]

What do you mean by handles? File handles? Memory?

David

======================================
David McCarter [Microsoft MVP]
www.dotNetTips.com
David McCarter''s .NET Coding Standards available at:
http://codingstandards.notlong.com

 

[Dave Burns]

I have run Process Explorer and the types of handles that are leaking are
Event. All other handle types are stable.

I found this post


http://blogs.msdn.com/junfeng/archive/2008/04/28/event-handles-leak.aspx

which seems to suggest that if there are a lot of thread contention on
locks, then the CLR creates more and more Events.

Can anyone confirm or deny this? I am using 3.5 SP1 Framework.

The service is written in C# and it does have a fair amount of

lock(syncRoot)

{

...

}

 

[Ben Voigt [C++ MVP]]

I have run Process Explorer and the types of handles that are leaking are
Event. All other handle types are stable.

I found this post


http://blogs.msdn.com/junfeng/archive/2008/04/28/event-handles-leak.aspx

Sounds like a bug. Native resources should only be used from classes which
are disposable, and should be released when disposed, but neither is done
for these events, so they live until memory pressure in the managed heap
causes collection. Not good, especially if the parent object lives beyond
Gen0.

Is there any way to force cleanup of these events from a user-implemented
dispose method?