我的 EventWaitHandle 说“访问路径被拒绝”，但它不是

Posted 2023-02-16

【中文标题】我的 EventWaitHandle 说“访问路径被拒绝”，但它不是

【英文标题】：My EventWaitHandle says "Access to the path is denied", but its not

【发布时间】：2009-11-23 16:43:31

【问题描述】：

简要总结一下我现在所知道的

我创建了一个EventWaitHandle，然后关闭了它。当我尝试使用 this ctor 重新创建它时，会引发“访问路径...被拒绝”异常。这种异常很少见，大多数时候它只是重新创建EventWaitHandle 就好了。通过下面（由我）发布的答案，我可以成功调用 EventWaitHandle.OpenExisting 并在引发异常的情况下继续，但是，EventWaitHandle 的 ctor 应该为我完成了这个，对吧？ out parameter、createdNew 不就是为了这个吗？

---

最初的问题

我在同一台服务器上有以下架构、一个 Windows 服务和一个 Web 服务。 Web 服务通过打开和设置 Windows 服务正在等待的等待句柄来告诉 Windows 服务它必须完成工作。

通常一切都完美无缺，我能够启动/停止 Windows 服务而不会出现任何问题。但是，有时当我停止 Web 服务然后重新启动它时，它会完全无法创建等待句柄，从而破坏了整个架构。

我特别需要找出是什么破坏了事件等待句柄并停止它。当等待句柄“中断”时，我必须重新启动 Windows，然后它才能再次正常运行，这显然不理想。

更新：抛出异常和问题日志

我在 Web 服务正在运行时重新启动了 Windows 服务，希望能引起问题，结果确实如此！一些班级名称已因企业匿名而被审查

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()

大致时间线：

11:53:09,937：Web 服务上打开现有等待句柄的最后一个线程，完成了它的工作（如终止与客户端的连接）

12:00:30,234：Web 服务获得新连接，但尚未使用等待句柄。此连接的线程 ID 与 11:53 的最后一个连接的线程 ID 相同

12:00:41,250：Windows 服务停止

12:00:42,781：windows 服务启动

12:00:43,078：Windows 服务完成崩溃

12:00:50,234：Web 服务实际上能够在其上打开等待句柄调用 Set()，而不会引发任何异常等。

12:02:00,000：我尝试重新启动 windows 服务，同样的异常

12:36:57,328：任意等待 36 分钟后，我无需完全重新启动系统即可启动 Windows 服务。

---

Windows 服务代码

初始化：

// 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

利用：

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

处置/关闭：

try

    while (true)
    
        // entire service logic here
    

catch (Exception e)

    // should this be in a finally, instead?
    if (this.ewh != null)
    
        this.ewh.Close();
    

---

网络服务代码

初始化：

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

利用：

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

由于EventWaitHandle 是Web 服务上的成员变量，我没有任何代码专门关闭它。实际上，上面贴出了唯一与 web 服务上的EventWaitHandle 交互的代码。

---

回想起来，我可能应该将catch 块中的Close() 放在finally 块中。我可能应该为 Web 服务做同样的事情，但我认为没有必要。

无论如何，谁能看出我做错了什么？将 close 语句放在 finally 块中是否至关重要？需要在web服务上手动控制existing_ewh的Close()吗？

另外，我知道这是一个稍微复杂的问题，所以如果您需要任何其他信息，请告诉我，我会密切关注并添加任何需要的信息或解释。

参考资料

EventWaitHandleSecurity Class EventWaitHandleAccessRule Class EventWaitHandle Class

【问题讨论】：

错误代码？你是说例外？一旦我可以重新创建它（我一直在尝试，它只会在我不想要它时发生！）我会发布异常。在那之前，如果有人愿意，我可以添加额外的日志记录

【参考方案1】：

在创建windows服务等待句柄的代码中，如果失败（如拒绝访问），你可以尝试通过

“打开一个现有的等待句柄”

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

不过，我不完全确定当时的行为是否会保持不变。

注意：非常感谢您的反馈。这是一个潜在的答案，所以我再次回答我自己的问题，非常欢迎大量的 cmets！

注意 2：令人惊讶的是，应用 EventWaitHandleRights.FullControl 而不是上述标志 (Synchronize + Modify) 效果不佳。您必须使用上面的示例。

【讨论】：

哇！更新代码后，我能够再次复制问题并修复它。但是，Windows 服务的后续重新启动总是会导致 Windows 服务无法创建等待句柄，并且总是不得不打开现有的等待句柄。到目前为止，没有功能丢失。我将等待 30 分钟，然后尝试重新启动服务以查看它是否能够创建它，或者它是否仍需要打开现有的服务

30 分钟后，我重新启动了 Windows 服务，它能够创建 EventWaitHandle，就好像它是新的一样。 ctor 中的 out 参数表示它是新创建的。

我们有同样的问题，但上面的代码对我们不起作用。 :(

您不需要执行 OpenExitsing。首先，您只需在创建 EventWaitHandle 时添加正确的安全性。见：***.com/questions/15129643/…

【参考方案2】：

MSDN 说：

UnauthorizedAccessException - 指定事件存在且具有访问控制安全性，但用户没有 EventWaitHandleRights.FullControl。

和

即使 eventSecurity 拒绝或未能授予当前用户某些访问权限，调用者也可以完全控制新创建的 EventWaitHandle 对象。

您的服务无权通过 EventWaitHandle 构造函数获取现有事件。 （未指定 EventWaitHandleRights.FullControl。您的命名事件在已打开句柄时存在。）您可以使用 EventWaitHandle.OpenExisting 打开现有事件。

【讨论】：

hrm，有趣的是，我已经阅读了文档，但略过了上面写着“命名事件存在”的部分......所以显然它可以存在并且它会通过设计抛出异常。不完全确定这有什么用（例外是，不是你的答案）:) 谢谢男人