为何EnterCriticalSection无法触发超时并抛出EXCEPTION_POSSIBLE_DEADLOCK异常？

我太懂你这种“严格按文档操作却没得到预期结果”的挫败感了——改了注册表的超时值，甚至动手修改了PE文件的加载配置，结果测试代码里的临界区还是安安分分等完5秒，半点儿EXCEPTION_POSSIBLE_DEADLOCK的影子都没见着。咱一步步拆解问题出在哪儿：

核心误解：这个异常不是“等待超时就抛” #

你可能误以为只要线程等待临界区的时间超过设定阈值，系统就会抛出异常，但实际上它的触发逻辑要严格得多：

• EXCEPTION_POSSIBLE_DEADLOCK是系统用来检测潜在死锁场景的，而非处理普通的长时间临界区争用。
• 只有当系统判定临界区的拥有者线程已经无法释放临界区时（比如拥有者线程被挂起、终止，或者陷入无限循环根本到不了LeaveCriticalSection），才会在等待线程上触发这个异常。
• 你的测试代码里，持有临界区的线程只是在Sleep，它是完全活跃的，而且一定会执行到释放逻辑，系统会判定这是正常的资源争用，而非“可能死锁”，自然不会抛异常。

注册表与PE加载配置的生效前提 #

虽然你改的数值是对的（注册表值≤3600秒、PE配置值≤3600000毫秒才会生效），但因为触发条件不满足，这些修改自然不会有你预期的效果：

• 注册表的CriticalSectionTimeout是系统级全局阈值，PE文件的CriticalSectionDefaultTimeout是进程级的覆盖值，但两者的作用都是“当系统检测到潜在死锁时，等待多久后抛出异常”，而非“普通等待的超时时间”。

如何正确复现这个异常 #

要看到EXCEPTION_POSSIBLE_DEADLOCK，你需要构造一个拥有者线程彻底无法释放临界区的场景，比如：

1. 让持有临界区的线程进入不可恢复状态（仅用于测试）：

   void Worker() {
       var threadId = Thread.CurrentThread.ManagedThreadId;
       WriteLine($"{Stopwatch.GetElapsedTime(startTime)}: {threadId}: Before EnterCriticalSection");
       EnterCriticalSection(ref criticalSection);
       WriteLine($"{Stopwatch.GetElapsedTime(startTime)}: {threadId}: After EnterCriticalSection");
       // 让线程永久挂起（注意：Thread.Suspend已过时，仅测试用）
       Thread.CurrentThread.Suspend();
       // 下面的代码永远不会执行
       WriteLine($"{Stopwatch.GetElapsedTime(startTime)}: {threadId}: Before LeaveCriticalSection");
       LeaveCriticalSection(ref criticalSection);
   }
   

2. 或者用调试器手动干预：
   • 用WinDbg附加到进程，当线程1进入临界区并开始Sleep时，找到线程1的ID，执行~[线程ID]s命令挂起它，然后观察线程2的行为——当等待时间超过你设定的阈值后，就会触发目标异常。

额外细节：用户模式与内核模式等待的区别 #

EnterCriticalSection会先在用户模式下自旋等待（避免切换到内核态的性能开销），只有自旋等待失败后才会进入内核模式等待。只有在内核模式等待阶段，系统才会检查潜在死锁并触发超时异常。你可以通过InitializeCriticalSectionAndSpinCount调整自旋计数，让线程更快进入内核态等待，这样能更快看到触发效果。

内容来源于stack exchange