tags:

views:

112

answers:

2

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?

+1  A: 

If you're talking about kernel Event Objects, then an event handle will be a handle (Int) that the system keeps on this object so other objects can reference it. IE Keep a 'handle' on it.

Hope this helps!

Tony
This definitely helps a bit, though I'm still not really clear on how event object synchronization differs from semaphores (ie: why is there a separate kernel object for it?)
Tanzelax
+1  A: 

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.

Preet Sangha
Ah, so they're pretty much the same, just different implementation/semantics for use with hardware drivers instead of through software. Thanks!
Tanzelax
Yeah, this inherited code component is essentially the device driver (it's directly p/invoking hid.dll and returning a wrapper for the input/output of the device), so I'm fairly certain the problem is in here and not any hardware idiosyncrasies.
Tanzelax
@Preet: Cool... I wish I could upvote you again for that answer, that's really nice to know. And in case you were wondering, the problem ended up just your everyday not-disposed-correctly leak, but I've learned a ton from this. :)
Tanzelax
I so00o recommend reading the above book. I've just started on it (been ages since I did driver development) and its good to understand the mechanics of the system.
Preet Sangha