My EventWaitHandle says "Access to the path is denied", but its not
Asked Answered
V

2

15

Quick summary with what I now know

I've got an EventWaitHandle that I created and then closed. When I try to re-create it with this ctor, an "Access to the path ... is denied" exception is thrown. This exception is rare, most of the times it just re-creates the EventWaitHandle just fine. With the answer posted below (by me), I'm able to successfully call EventWaitHandle.OpenExisting and continue on in the case that an exception was thrown, however, the ctor for EventWaitHandle should have done this for me, right? Isn't that what the out parameter, createdNew is for?


Initial question

I've got the following architecture, a windows service and a web service on the same server. The web service tells the windows service that it has to do work by opening and setting the wait handle that the windows service is waiting on.

Normally everything is flawless and I'm able to start / stop the windows service without any issue popping up. However, some times when I stop the web service and then start it up again, it will be completely unable to create the wait handle, breaking the whole architecture.

I specifically need to find out what is breaking the event wait handle and stop it. When the wait handle "breaks", I have to reboot windows before it will function properly again and thats obviously not ideal.

UPDATE: Exception thrown & Log of Issue

I rebooted the windows service while the web service was doing work in hopes of causing the issue and it did! Some of the class names have been censored for corporate anonymity

12:00:41,250 [7] - Stopping execution due to a ThreadAbortException
System.Threading.ThreadAbortException: Thread was being aborted.
   at System.Threading.Thread.SleepInternal(Int32 millisecondsTimeout)
   at OurCompany.OurProduct.MyClass.MyClassCore.MonitorRequests()

12:00:41,328 [7] - Closing Event Wait Handle
12:00:41,328 [7] - Finally block reached


12:00:42,781 [6] - Application Start
12:00:43,031 [6] - Creating EventWaitHandle: Global\OurCompany.OurProduct.MyClass.EventWaitHandle
12:00:43,031 [6] - Creating EventWaitHandle with the security entity name of : Everyone

12:00:43,078 [6] - Unhandled Exception 
System.UnauthorizedAccessException: Access to the path 'Global\OurCompany.OurProduct.MyClass.EventWaitHandle' is denied.
   at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
   at System.Threading.EventWaitHandle..ctor(Boolean initialState, EventResetMode mode, String name, Boolean& createdNew, EventWaitHandleSecurity eventSecurity)
   at OurCompany.OurProduct.MyClassLibrary.EventWaitHandleFactory.GetNewWaitHandle(String handleName, String securityEntityName, Boolean& created)
   at OurCompany.OurProduct.MyClassLibrary.EventWaitHandleFactory.GetNewEventWaitHandle()
   at OurCompany.OurProduct.MyClass.MyClassCore..ctor()

Rough timeline:

  • 11:53:09,937: The last thread on the web service to open that existing wait handle, COMPLETED its work (as in terminated connection with the client)

  • 12:00:30,234: The web service gets a new connection, not yet using the wait handle. The thread ID for this connection is the same as the thread ID for the last connection at 11:53

  • 12:00:41,250: The windows service stops

  • 12:00:42,781: The windows service starts up

  • 12:00:43,078: The windows service finished crashing

  • 12:00:50,234: The web service was actually able to open the wait handle call Set() on it without any exception thrown etc.

  • 12:02:00,000: I tried rebooting the windows service, same exception

  • 12:36:57,328: After arbitrarily waiting 36 minutes, I was able to start the windows service up without a full system reboot.


Windows Service Code

Initialization:

// I ran into security issues so I open the global EWH
//    and grant access to Everyone
var ewhSecurity = new EventWaitHandleSecurity();

ewhSecurity.AddAccessRule(
 new EventWaitHandleAccessRule(
  "Everyone",
  EventWaitHandleRights.Synchronize | EventWaitHandleRights.Modify,
  AccessControlType.Allow));

this.ewh = new EventWaitHandle(
 false,
 EventResetMode.AutoReset,
 @"Global\OurCompany.OurProduct.MyClass.EventWaitHandle",
 out created,
 ewhSecurity);

// the variable "created" is logged

Utilization:

// wait until the web service tells us to loop again
this.ewh.WaitOne();

Disposal / closing:

try
{
    while (true)
    {
        // entire service logic here
    }
}
catch (Exception e)
{
    // should this be in a finally, instead?
    if (this.ewh != null)
    {
        this.ewh.Close();
    }
}

Web Service Code

Initialization:

// NOTE: the wait handle is a member variable on the web service
this.existing_ewh = EventWaitHandle.OpenExisting(
    @"Global\OurCompany.OurProduct.MyClass.EventWaitHandle");

Utilization:

// wake up the windows service
this.existing_ewh.Set();

Since the EventWaitHandle is a member variable on the web service, I don't have any code that specifically closes it. Actually, the only code that interacts with the EventWaitHandle on the web service is posted above.


Looking back, I should probably have put the Close() that is in the catch block, in a finally block instead. I probably should have done the same for the web service but I didn't think that it was needed.

At any rate, can anyone see if I'm doing anything specifically wrong? Is it crucially important to put the close statements within a finally block? Do I need to manually control the Close() of the existing_ewh on the web service?

Also, I know this is a slightly complex issue so let me know if you need any additional info, I'll be monitoring it closely and add any needed information or explanations.

Reference material

Vannesavanness answered 23/11, 2009 at 16:43 Comment(1)
Error code? You mean the exception? As soon as I can recreate it (I've been trying, it only happens when I don't want it to!) I will post the exception. Until then, I can add additional logging if anyone wantsVannesavanness
V
13

In the code that creates the wait handle on the windows service, if it fails (as in access denied), you could try to "open an existing wait handle" via

EventWaitHandle.OpenExisting(
    @"Global\OurCompany.OurProduct.MyClass.EventWaitHandle",
    EventWaitHandleRights.Synchronize | EventWaitHandleRights.Modify);

Though, I'm not entirely sure if the behaviour would stay the same at that point.

Note: I'd appreciate feedback. Its a potential answer so I'm answering my own question, again, plenty of comments are quite welcome!

Note 2: Amazingly, applying EventWaitHandleRights.FullControl instead of the above flags (Synchronize + Modify) doesn't work well. You must use the sample above.

Vannesavanness answered 24/11, 2009 at 17:43 Comment(4)
WOOT! After updating the code, I was able to duplicate the issue again and this fixed it. However, subsequent reboots of the windows service would always result in the windows service being unable to create the wait handle and always having to open an existing one. So far no functionality is lost. I will wait 30 minutes and try to reboot the service to see if it is able to create it or if it STILL needs to open an existing oneVannesavanness
30 minutes later, I rebooted the windows service and it was able to create the EventWaitHandle as if it were new. The out parameter in the ctor indicated that it was newly created.Vannesavanness
we have the same issue but the code above didn't work for us. :(Daisy
You don't need to do OpenExitsing. You simply need to add the correct security when you create the EventWaitHandle in the first place. See: #15130143Steddman
F
1

MSDN says:

UnauthorizedAccessException - The named event exists and has access control security, but the user does not have EventWaitHandleRights.FullControl.

and

The caller has full control over the newly created EventWaitHandle object even if eventSecurity denies or fails to grant some access rights to the current user.

Your service has no rights to get the existing event via EventWaitHandle constructor. (EventWaitHandleRights.FullControl is not specified. And your named event exists while it has opened handles on it.) You can open the existing event using EventWaitHandle.OpenExisting.

Friedly answered 25/11, 2009 at 7:32 Comment(1)
hrm, interesting, I had read the documentation but skimmed over the part where it says "The named event exists"... So apparently it can exist and it will throw an exception by design. Not entirely sure how this is useful (the exception that is, not your answer) :) Thanks manVannesavanness

© 2022 - 2024 — McMap. All rights reserved.