4

I am developing a Windows Service in C# to centrally manage some application connectivity. It's a sleeper service in general, which performs some actions when awoken by an external executable. To this end I'm using named events, specifically the .NET EventWaitHandle. My code boils down to, at the service end:

        EventWaitHandleSecurity sec = new EventWaitHandleSecurity();
        sec.AddAccessRule(new EventWaitHandleAccessRule(
                  new SecurityIdentifier(WellKnownSidType.WorldSid, null),
                  EventWaitHandleRights.FullControl,
                  AccessControlType.Allow));
        evh = new EventWaitHandle(false, EventResetMode.AutoReset, EVENT_NAME, 
                                  out created, sec);

        Log(created ? "Event created" : "Event already existed?");

As it's an internal application on trusted servers I don't mind that granting 'Full Control' to 'World' in general wouldn't be smart.

At the client end I have:

EventWaitHandle.TryOpenExisting(EVENT_NAME, EventWaitHandleRights.Modify, out evh)

The code above works perfectly when I run my service in console-based interactive mode. The event is found on both ends, the client can set, and the service kicks to work. Everybody's happy.

When installing the service however it doesn't work. The logging still reports that the event was created anew, but the client cannot find the event. As I thought it was security-related I added the World Full Control Allow access rule, but it didn't change anything. I changed the service to run as Local Admin, even as my own user account, but nothing - the client cannot find the event even though logs show the service is happily polling away on it. If I change the TryOpenExisting to OpenExisting I get an explicit exception:

System.Threading.WaitHandleCannotBeOpenedException: No handle of the given name exists.

What am I missing?

Niels Keurentjes
  • 41,402
  • 9
  • 98
  • 136

1 Answers1

5

Starting with Windows Vista, services are isolated and run in Session 0 (see Service Changes for Windows Vista). When calling CreateEvent (which EventWaitHandle does), the event object is created in the local namespace by default, also called session namespace. An event object created by a service in session 0 with a name in the session namespace is visible in session 0 only. It is invisible to applications running in an interactive user session.

To create an event object by a service (running in session 0) that can be discovered by application code (running in an interactive user session), you have to create it into the global namespace. This is done by prefixing the event name with "Global\", as documented under CreateEvent.

A helpful tool to track down kernel object-related bugs is Sysinternal's WinObj.

IInspectable
  • 46,945
  • 8
  • 85
  • 181
  • You're right, and I had even discovered this before reading your answer, and I've (shame on me) [actually answered a nearly identical question elsewhere myself nearly 2 years ago](http://stackoverflow.com/a/20714164/1729885). I was however not completely aware that this was a fundamental change in Service model in the 6.x kernels. It's working fine in the global namaespace. Thank you! – Niels Keurentjes Aug 13 '15 at 19:51
  • @NielsKeurentjes: If nothing else, I followed your petition to re-open that question, due to the shortcomings of the duplicate question's answer. It is indeed incomplete, at best. – IInspectable Aug 13 '15 at 20:14