Question

在测试应用程序时，我遇到了一种奇怪的行为。一些测试使用模拟以不同的用户身份运行代码，但它们总是挂起，永远不会完成。

经过一番调查后，问题被缩小到使用互斥锁。最初，我们使用了基于MSDN documentation的我们自己的模拟代码，但即使使用SimpleImpersonation library，问题仍然存在。以下是重现问题的最小示例：

using (Impersonation.LogonUser(DOMAIN, USER, PASSWORD, LogonType.Interactive))
{
    Console.WriteLine("Impersonated");
    bool mine;
    using (new Mutex(true, "Mutex", out mine))
    {
        if (!mine)
            throw new Exception("Couldn't get mutex");
        Console.WriteLine("Got mutex");
    }
}

Console.WriteLine("Finished");

这永远不会完成，它会与互斥锁创建一起停留在线上。 documentation表示它应该抛出异常或返回一些东西，但是没有提到阻塞。

其他一些可能相关或不相关的观察结果：

如果我们＆＃34;冒充＆＃34;当前用户，它立即返回
如果我们运行实际的应用程序并启动另一个实例作为不同的用户，一切都按预期工作

可能存在基础系统资源的问题，但我们无法弄明白。如何使这项工作？

更新：根据Hans＆＃39;评论，我试过禁用Windows Defender，它没有帮助。这是它挂起的地方的堆栈跟踪：

    ntdll.dll!_NtWaitForSingleObject@12()
    KernelBase.dll!_WaitForSingleObjectEx@12()
    mscorlib.ni.dll!719c1867()
    [Frames below may be incorrect and/or missing, native debugger attempting to walk managed call stack]   
    mscorlib.ni.dll!719c1852()
    [Managed to Native Transition]  
    mscorlib.dll!System.Threading.Mutex.CreateMutexHandle(bool initiallyOwned, string name, Microsoft.Win32.Win32Native.SECURITY_ATTRIBUTES securityAttribute, out Microsoft.Win32.SafeHandles.SafeWaitHandle mutexHandle)
        mscorlib.dll!System.Threading.Mutex.MutexTryCodeHelper.MutexTryCode(object userData)
    [Native to Managed Transition]  
    [Managed to Native Transition]  
    mscorlib.dll!System.Threading.Mutex.CreateMutexWithGuaranteedCleanup(bool initiallyOwned, string name, out bool createdNew, Microsoft.Win32.Win32Native.SECURITY_ATTRIBUTES secAttrs)   
    mscorlib.dll!System.Threading.Mutex.Mutex(bool initiallyOwned, string name, out bool createdNew, System.Security.AccessControl.MutexSecurity mutexSecurity) 
    mscorlib.dll!System.Threading.Mutex.Mutex(bool initiallyOwned, string name, out bool createdNew)    
    MutexImpersonationTest.exe!MutexImpersonationTest.Program.Main(string[] args) Line 16

Answer 1

看起来获取Mutex的代码陷入了无限循环，在我的测试中，它在new Mutex(...)的调用中将一个核心固定为100％。

原因似乎是框架代码首先尝试调用Win32 CreateMutex，如果失败且出现“拒绝访问”错误，请尝试调用OpenMutex。如果OpenMutex调用失败并指示互斥锁不存在，则会再次重复整个过程，因此如果互斥锁不存在则会陷入无限循环。

根据CreateMutex documentation，这本质上是正确的方法，但似乎没有考虑到初始CreateMutex因访问被拒绝而不由于对现有互斥锁的权限。

当我尝试它时，似乎有效的一件事是将互斥锁名称加上“Global \”的前缀，希望这对你来说是一个合适的解决方法。

使用模拟时，互斥锁创建会挂起

1 个答案: