我们有一个Windows 32应用程序，其中一个线程可以通过执行SuspendThread/GetThreadContext/ResumeThread来停止另一个线程以检查其状态[PC等]。

if (SuspendThread((HANDLE)hComputeThread[threadId])<0)  // freeze thread
   ThreadOperationFault("SuspendThread","InterruptGranule");
CONTEXT Context, *pContext;
Context.ContextFlags = (CONTEXT_INTEGER | CONTEXT_CONTROL);
if (!GetThreadContext((HANDLE)hComputeThread[threadId],&Context))
   ThreadOperationFault("GetThreadContext","InterruptGranule");

在极少数情况下，在多核系统上，GetThreadContext返回错误代码5（Windows系统错误代码“拒绝访问”）。
SuspendThread文档似乎清楚地表明，如果没有返回错误，目标线程将被挂起。我们正在检查SuspendThread和ResumeThread的返回状态;他们从不抱怨
为什么我可以挂起一个线程，但不能访问它的上下文？
此博客http://www.dcl.hpi.uni-potsdam.de/research/WRK/2009/01/what-does-suspendthread-really-do/
提示SuspendThread在返回时可能已经开始挂起另一个线程，但该线程尚未挂起。在这种情况下，我可以看到GetThreadContext是有问题的，但这似乎是一种定义SuspendThread的愚蠢方法。（SuspendThread的调用如何知道目标线程实际上何时被挂起？）
编辑：* 我撒谎了 * 我说这是Windows。
好吧，奇怪的事实是，我在Windows XP 64下没有看到这种行为（至少在上周没有，我真的不知道在那之前发生了什么）。但我们一直在Ubuntu 10.x上的Wine下测试这个Windows应用程序。GetThreadContext核心的Wine源代码在第819行包含一个Access Denied返回响应，当尝试获取线程状态由于某种原因失败时。我猜，但似乎Wine GetThreadStatus认为线程可能无法重复访问。我不明白为什么在一个悬浮头之后会是这样，但这是代码。想法呢？
第2章：我又说谎了我说我们只看到Wine的行为。不...我们现在已经找到了一个Vista终极系统，似乎产生同样的错误（再次，很少）。因此，Wine和Windows似乎在一个模糊的案例上达成了一致。它也似乎只是启用Sysinternals进程监视程序的情况下，并导致问题出现在Windows XP 64;我怀疑是海森堡虫。（进程监视器甚至不存在于Wine-tasting（：-）机器或我用于开发的XP 64系统中）。
这到底是什么？
编辑3：2010年9月15日。我已经为SuspendThread、ResumeThread和GetContext添加了对错误返回状态的仔细检查，而不会干扰代码。自从我这样做以来，我还没有在Windows系统上看到这种行为的任何暗示。我还没有回到葡萄酒实验。
2010年11月：奇怪。看起来如果我在VisualStudio 2005下编译这个，它在Windows Vista和7上失败，但在更早的操作系统上不会。如果我在VisualStudio 2010下编译，它不会在任何地方失败。有人可能会把矛头指向VisualStudio 2005，但我怀疑这是一个位置敏感的问题，VS 2005和VS 2010中的不同优化器将代码放置在稍微不同的地方。
2012年11月： Saga 继续。我们在许多XP和Windows 7机器上都看到了这种故障，发生率相当低（每运行几千次就有一次）。我们的Suspend活动应用于主要执行纯计算代码但有时会调用Windows的线程。我不记得在我们的计算代码中线程的PC时看到过这个问题。当然，我看不到线程挂起时的PC，因为GetContext不会给予给我，所以我不能直接确认问题只发生在执行系统调用时。但是，我们所有的系统调用都是通过一个点进行的，到目前为止，证据是当我们挂起时，该点被执行。因此，间接证据表明，线程上的GetContext只有在该线程正在执行系统调用时才会失败。我还没有足够的精力来建立一个批判性的实验来验证这个假设。