Question

I had a leaking handle problem (“Not enough quota available to process this command.”) in some inherited C# winforms code, so I went and used Sysinternals’ Handle tool to track it down. Turns out it was Event Handles that were leaking, so I tried googled it (took a couple tries to find a query that didn’t return “Did you mean: event handler?”). According to Junfeng Zhang, event handles are generated by the use of Monitor, and there may be some weird rules as far as event handle disposal and the synchonization primitives.

I’m not entirely sure that the source of my leaking handles are entirely due to simply long-lived objects calling lots of synchronization stuff, as this code is also dealing with HID interfaces and lots of win32 marshaling and interop, and was not doing any synchronization that I was aware of. Either way, I’m just going to run this in windbg and start tracing down where the handles are originating from, and also spend a lot of time learning this section of the code, but I had a very hard time finding information about what event handles are in the first place.

The msdn page for the event kernel object just links to the generic synchronization overview… so what are event handles, and how are they different from mutexes/semaphores/whatever?

Answer 1

The NT kernel uses event objects to allow signals to transferred to entities that wait on the signal. A mutex and a semaphore are also waitable kernel objects (Kernel Dispatcher Objects), but with different semantics. The only time I ever came across them was when waiting for IO to complete in drivers.

So my theory on your problem is possibly a faulty driver, or are you relying on specialised hardware?

Edit: More info (from Windows Internals 5th Edition – Chapter 3 System Mechanics)

Some Kernel Dispatcher Objects (e.g. mutex, semaphore) have the of concept ownership. So when signalled the released one waiting thread will be released will grab these resources. And others will have to continue to wait. Events are not owned hence are available to be reset by any thread.

Also there are three types of events:

• Notification : On signalled all waiting threads are released
• Synchronisation : On signalled one waiting thread is released but the event is reset
• Keyed : On signalled one waiting thread in the same process as the signaller is released.

Another interesting thing that I’ve learned is that critical sections (the lock primitive in c#) are actually not kernel objects, rather they are implemented out of a keyed event, or mutex or semaphore as required.