Mutex构造函数传入类GUID名称时莫名抛出未授权访问异常

这个异常和GUID是否为系统保留值、名称字符串命中特殊规则没有任何关系，本质是Windows命名内核对象的权限隔离机制 + 故障服务器上残留了其他安全上下文创建的同名Mutex对象导致的。

核心逻辑很简单：

• 你调用new Mutex(false, 名称)时，系统不会直接新建对象，会先查找内核对象表中是否存在同名称的Mutex。
  • 如果不存在：用当前进程的运行身份创建新Mutex，当前进程默认对这个对象拥有完全控制权限，不会报错。
  • 如果已存在：尝试用当前进程所需的访问权限打开这个已有对象，如果对象的创建者是其他用户/其他权限等级的安全主体，且没有给当前运行身份开放对应权限，就会直接抛出UnauthorizedAccessException。
• 你使用的纯GUID格式名称没有加Global\或Local\前缀，默认创建在会话0的Local命名空间下——IIS的w3wp工作进程默认就运行在会话0，这个命名空间下的内核对象对所有会话0内的进程可见，不管进程属于哪个应用池、哪个软件，只要名称完全一致就会命中同一个对象。

所有服务器配置一致但只有一台出问题，唯一的差异就是这台服务器的内核对象表中存在对应名称的残留Mutex，常见的残留来源有这几种：

• 之前曾经用管理员身份、SYSTEM身份在这台服务器上运行过包含同名Mutex逻辑的程序（比如临时调测的控制台程序、运行在服务态的运维工具/杀毒软件、其他配置错误的IIS站点），创建对象后没有正确释放，句柄一直残存在系统中。
• 全零GUID字符串00000000-0000-0000-0000-000000000000是非常通用的测试用名称，很容易和服务器上其他完全不相关的第三方软件创建的Mutex撞名。
• 你替换成固定GUID后，第一次在故障服务器运行该逻辑时，可能刚好遇到应用池加载异常、w3wp进程崩溃退出没有释放句柄、或者安全扫描软件提前触达了对应代码路径，用其他安全上下文创建了这个固定名称的Mutex，后续正常启动的工作进程自然没有权限打开这个已有对象。

本地调试时程序运行在当前登录用户的交互式会话中，不存在其他安全上下文创建的同名Mutex对象，每次调用都是新建对象流程，自然不会触发权限错误。

等你可以登录故障服务器操作时，可以按以下步骤验证和修复：

1. 临时验证可以直接重启服务器，清空内核中残留的无主对象，重启后首次运行应用大概率会恢复正常；也可以用Process Explorer搜索对应名称的内核对象，找到持有Mutex句柄的进程，结束进程或关闭对应句柄即可临时恢复。
2. 复现测试可以在服务器上先用管理员身份启动一个程序，创建同名Mutex后不释放，再用应用池的运行身份启动你的测试代码，就能稳定复现拒绝访问错误。
3. 长期修复建议：
   • 尽量避免使用固定字符串作为跨进程Mutex的名称，如果必须使用，给名称增加唯一的业务前缀，降低和其他软件撞名的概率。
   • 如果需要在IIS场景下使用命名Mutex，建议明确指定Global\前缀，同时在构造时传入自定义的MutexSecurity配置，给应用池运行身份开放足够的访问权限，避免对象被其他进程创建后无权限访问。
   • 如果不需要跨进程互斥，不要给Mutex传入名称，创建匿名Mutex即可，完全不会出现撞名和权限问题。

内容的提问来源于stack exchange，提问作者aoven