Share via

Event Handles “leak”

  • Article

On our stress run, we saw our process’ handle count steadily increases until certain point, then it stabilizes. However the number of handles is high. Most of those handles are Event handles. We are concerned about it. So we went off and did some investigation.

Turns out the Event handles are coming from the use of Monitor.

When there is contention on the lock object, CLR internally creates an Event handle, presumably to facilitate the thread scheduling. The event handle is not cleaned up until the object is garbage collected.

It appears we were using Monitor in a lot of places, and we had lock contentions, which triggers CLR to allocate a lot of Event handles.

So if you have a lot of long lived objects, be careful about the usage of Monitor.

Comments

  • Anonymous
    April 28, 2008
    PingBack from http://microsoftnews.askpcdoc.com/debugging/event-handles-%e2%80%9cleak%e2%80%9d

  • Anonymous
    April 28, 2008
    The comment has been removed

  • Anonymous
    May 05, 2008
    Interesting. I had the same problem once and I had no idea how to track down those "leaking" events. It would be nice to know how it can be done :). I assumed they were used by some critical sections in unmanaged code.