Question

我在Windows 7中的采样分析器上遇到了一个奇怪的问题（在之前的Windows操作系统上没有AFAICT问题，无论是32位还是64位）。

分析器通过定期挂起SuspendThread的线程，然后在调用GetThreadContext重启进程之前查看带有ResumeThread的上下文。所有这些都是从多媒体定时器的线程环境完成的（准确度大约为1kHZ，在Windows 7之前的操作系统通常会导致可忽略的性能损失）。

仅在Windows 7和Windows 7下，即使对SuspendThread（和ResumeThread）的调用都成功，对GetThreadContext的调用也会失败并显示错误：

ERROR_NOACCESS
  998（0x3E6）
  对内存位置的访问无效。

有很高的可能性，但并不是所有的时间。

我的意思是，对于一些分析运行，一切都会像在其他操作系统上一样工作（所有GetThreadContext调用都会成功），但对于其他运行，它们几乎都会失败（除了十几个，千分之几。）它使用完全相同的二进制文件，相同的参数。

我已经尝试过关于重复GetThreadContext调用的模糊相似问题的建议，但没有取得更多成功。我还尝试在Sleep和SuspendThread之间进行GetThreadContext，然后GetThreadContext更频繁地取得成功，但这会导致严重的减速。

但是，它建议Windows 7操作系统从SuspendThread返回，而线程可能尚未暂停 - 但是，如果是这种情况，我不知道如何或是否正确等待暂停，在线程中循环并且敲击GetThreadContext不会这样做。

编辑：16个字节对齐GetThreadContext的{{3}}结构的地址，正如Dan Bartlett建议的那样，似乎正在做这个伎俩！

Answer 1

查看GetThreadContext函数，它提到了

CONTEXT结构具有高度的处理器特性。有关此结构的处理器特定定义和任何对齐要求，请参阅WinNt.h头文件。

查看此文件，_CONTEXT用

声明

typedef struct DECLSPEC_ALIGN(16) _CONTEXT {
...

所以它可能是一个对齐问题。