How do I tell whether a Windows kernel Event object is auto-reset or manual-reset?

Question

Windows allows the creation of (named) Event objects.

An Event (the synchronization primitive in Windows) can be of type auto-reset (in which case you could say it's kind of a semaphore) or it can be of type manual-reset in which case it remains set until someone resets it.

Now, from the docs for CreateEvent, OpenEvent, SetEvent, etc. it does seem that there is no way to determine, once the event has been created, whether it's auto-reset or maual-reset.

I am in the situation, where one process creates a named Event and a 2nd process will have to operate on this event (it gets passed the name and then'll open the event and eventually signal it). Since the event should always be a manual-reset event for the whole thing to make sense, I would have liked to add a check in the 2nd process to make sure it is a manual-reset event. Is there any way to check for this?

(And yes, it's more of a nice-to-have in my situation, as it would be a bug anyway if any code would create a auto-reset event and then pass it to this process. But bugs happen, and the better if I can detect them.)

Demirep

This strongly fits "if you could find out then somebody will abuse it". It is forbidden knowledge, you can't find out. – Neophyte

Here is an updated link for the blog post since your link seems to be dead: An auto-reset event is just a stupid semaphore – Spokesman

Answer 1

There's no documented way to do this, but it's actually not hard if you venture into undocumented land. (For your purposes, this should be fine since it doesn't really affect your program's functionality.)

The first thing you need to do is figure out if the handle given to you is an event or not. You use NtQueryObject for this. The function is documented here: http://msdn.microsoft.com/en-us/library/bb432383(v=vs.85).aspx. It comes with the usual provisios for native APIs that it might disappear or change without notice. Partial example:

#include <winternl.h>

typedef NTSTATUS (NTAPI * PFN_NtQueryObject)(
    HANDLE Handle,
    OBJECT_INFORMATION_CLASS ObjectInformationClass,
    PVOID ObjectInformation,
    ULONG ObjectInformationLength,
    PULONG ReturnLength );

HMODULE ntdll = GetModuleHandle( L"ntdll.dll" );

auto NtQueryObject = (PFN_NtQueryObject)GetProcAddress( ntdll, "NtQueryObject" );

NTSTATUS result = NtQueryObject(
    eventHandle,
    ObjectTypeInformation,
    buffer,
    length,
    &length );

This will give you a PUBLIC_OBJECT_TYPE_INFORMATION structure. The TypeName field will be "Event" if the object is actually an event.

Next, you call NtQueryEvent to get the event's type. All this is completely undocumented.

typedef enum _EVENT_INFORMATION_CLASS {
    EventBasicInformation
} EVENT_INFORMATION_CLASS, *PEVENT_INFORMATION_CLASS;

typedef enum _EVENT_TYPE {
    NotificationEvent,
    SynchronizationEvent
} EVENT_TYPE, *PEVENT_TYPE;

typedef struct _EVENT_BASIC_INFORMATION {
  EVENT_TYPE              EventType;
  LONG                    EventState;
} EVENT_BASIC_INFORMATION, *PEVENT_BASIC_INFORMATION;

typedef NTSTATUS (NTAPI * PFN_NtQueryEvent)(
    HANDLE EventHandle,
    EVENT_INFORMATION_CLASS EventInformationClass,
    PVOID EventInformation,
    ULONG EventInformationLength,
    PULONG ReturnLength );

auto NtQueryEvent = (PFN_NtQueryEvent)GetProcAddress( ntdll, "NtQueryEvent" );

EVENT_BASIC_INFORMATION info;
ULONG length = sizeof( info );

NTSTATUS result = NtQueryEvent(
    eventHandle,
    EventBasicInformation,
    &info,
    length,
    &length );

Now, just examine the EventType field in the info and you're done. "NotificationEvent" means manual reset and "SynchronizationEvent" means auto reset.

If you're wondering how I figured that second part out, I didn't. The information comes from here: http://undocumented.ntinternals.net/. Please use responsibly!

Libby

Amazing. :-) While you're at it, take a peek at this completly unrelated question ;-) ... https://mcmap.net/q/1202733/-how-to-crash-a-process-on-windows-7-without-getting-the-wer-dialog/321013 – Demirep

Answer 2

Call WaitForSingleObject( handle, 0 ) immediately after your initial WaitForSingleObject has returned. If the return value is WAIT_TIMEOUT then you know it is an auto-reset event, if it is WAIT_OBJECT_0 will be returned and it is a manual reset event.

This does rely on the handle being set in-between the two calls, so there is a potential race condition where it does not detect an auto-reset event, but it should work most of the time. As it is a nice-to-have, hopefully that is enough?

Ruffianism

This code lives in the wrong process. The WaitForSingleObject() call is in the process that created the event. It already knows. – Neophyte

But surely in the second process OpenEvent will be called and that event will have to be waited on at some point? – Ruffianism