Notice: This website is an unofficial Microsoft Knowledge Base (hereinafter KB) archive and is intended to provide a reliable access to deleted content from Microsoft KB. All KB articles are owned by Microsoft Corporation. Read full disclaimer for more details.

INFO: OpenEvent Fails in a Non-Administrator Account


View products that this article applies to.

This article was previously published under Q228785

↑ Back to the top


Summary

User applications running in a non-administrator account will fail (ERROR_ACCESS_DENIED) to open a named event that has been created in a device driver in the system process context.

↑ Back to the top


More information

One way (not the best way) to notify the user mode application of asynchronous events from a device driver is to create a named event in kernel mode using IoCreateNotificationEvent and allow the user application to open the event and wait on it. The most common problem with this approach is: if the driver creates the event in DriverEntry, which runs in the system process context, the event object inherits the default system security attributes. As a result, the application can open the event only if it runs in the administrator account. The other problem is that the user application cannot change the state of the event. It can only wait on the event.

Note that creating such an event visible in user mode is not possible in the driver entry on Windows 2000 and later. The Win32 subsystem is not loaded at this step and on Windows 2000 and later, this subsystem is responsible for creating the BasedNamedObject directory. This is the director where the event has to be created in order to be visible in user mode.

A simple workaround for this problem is to create the event in a driver routine that runs in the context of the process that wants to access the event. In this way, the event object will inherit the security attributes of the process and will be able to open the event.

But the best way to provide this kind of kernel-to-user notification is to create the event in user mode and send an IOCTL to the driver with the handle of the event. The driver in turn would get the address of the event object from the handle by using the ObReferenceObjectByHandle function and can signal the event from any arbitrary thread context at IRQL less than or equal to DISPATCH_LEVEL. When the driver no longer needs the event, it would call ObDereferenceObject to free the event. The following Microsoft Knowledge Base article has a link to a sample driver that demonstrates this technique:
176415 Event.exe Shows How to Share and Signal an Event Object
Another technique to notify the user application without using events is described in the following Knowledge Base article:
117308 INFO: How Drivers Notify User-Mode Apps of Asynchronous Events

↑ Back to the top


Keywords: kbinfo, kbkmode, KB228785

↑ Back to the top

Article Info
Article ID : 228785
Revision : 5
Created on : 2/23/2007
Published on : 2/23/2007
Exists online : False
Views : 917