在Windows 7中成功挂起后，GetThreadContext失败 [英] GetThreadContext fails after a successful SuspendThread in Windows 7
问题描述
我在Windows 7中遇到了一个奇怪的问题（在以前的Windows操作系统上没有AFAICT，不管是32位还是64位）分析器可以通过定期挂起一个线程来工作，其中 SuspendThread ，然后查看上下文与 GetThreadContext msdn.microsoft.com/en-us/library/windows/desktop/ms685086(v=vs.85).aspxrel =nofollow noreferrer> ResumeThread 重新启动过程。所有这一切都是从多媒体定时器的线程（准确性，大约1kHZ，在Windows 7之前的Windows 7操作系统通常会导致可忽略的性能损失）的上下文中完成。
在Windows 7和Windows 7下，即使对 SuspendThread （和 ResumeThread ）的调用都成功，对 GetThreadContext 的调用失败，出现错误：
ERROR_NOACCESS
998（0x3E6）
访问内存位置无效。
非常高的可能性，虽然不是所有的时间。
我的意思是，对于某些剖析运行，所有内容都可以像其他操作系统一样工作（所有的 GetThreadContext 调用将成功），但对于其他运行，它们几乎都会失败（保存十几个，可能是几千分之一）。发生与完全相同的二进制文件，相同的参数。
我已经尝试了关于模糊相似的问题的建议来重复 GetThreadContext 通话，没有更多的成功。我也尝试在 SuspendThread 和 GetThreadContext Sleep c>，那么$ code> GetThreadContext 更经常地成功，尽管它导致剧烈的放缓。然而，建议Windows 7操作系统从 SuspendThread 返回，而线程可能尚未暂停 - 尽管如果是这样，我不知道如何或者如果正确地等待暂停，循环线程并敲击 GetThreadContext 不这样做。
编辑： 16个字节对齐 CONTEXT 结构 GetThreadContext 由丹·巴特利特（Dan Bartlett）似乎正在诀窍！
查看 GetThreadContext 函数，它提到
CONTEXT结构具有高度的处理器特定性。请参阅WinNt.h头文件，了解处理器特定于此结构的定义和任何对齐要求。
查看此文件， _CONTEXT声明为
typedef struct DECLSPEC_ALIGN（16）_CONTEXT {
...
所以这可能是一个对齐问题。
I'm encountering an odd issue on a sampling profiler in Windows 7 (no such issues AFAICT on previous Windows OSes, be they 32 or 64 bit).
The profiler works by periodically suspending a thread with SuspendThread, then looks at the context with GetThreadContext, before invoking ResumeThread to restart the process. All this is done from the context of the thread of a multimedia timer (for accuracy, at about 1kHZ, which on pre-Windows 7 OSes usually incurs a negligible performance penalty).
Under Windows 7, and Windows 7 only, even though the calls to SuspendThread (and ResumeThread) all succeed, the calls to GetThreadContext fail with error:
ERROR_NOACCESS
998 (0x3E6)
Invalid access to memory location.
with a very high likeliness, though not all the time.
By that I mean that for some profiling runs, everything will work as it does on other OSes (all the GetThreadContext calls will succeed), but for other runs, they will almost all fail (save a dozen maybe, out of tens of thousandths). It's happening with the exact same binaries, the same parameters.
I've tried suggestions on vaguely similar looking issues to repeat the GetThreadContext call, with no more success. I've also tried doing a Sleep between the SuspendThread and GetThreadContext, then the GetThreadContext succeeds more often, though it results in drastic slowdowns.
It suggests however that Windows 7 OS is returning from SuspendThread while the thread has probably not been suspended yet - though, if that's the case, I've no idea how or if to properly wait on the suspension, looping in the thread and pounding GetThreadContext doesn't do it.
Edit: 16 byte aligning the address of the CONTEXT structure for GetThreadContext as suggested by Dan Bartlett seems to be doing the trick!
Looking at the GetThreadContext function, it mentions that
The CONTEXT structure is highly processor specific. Refer to the WinNt.h header file for processor-specific definitions of this structures and any alignment requirements.
And looking at this file, _CONTEXT is declared with
typedef struct DECLSPEC_ALIGN(16) _CONTEXT {
...
So it's possible it could be an alignment issue.
这篇关于在Windows 7中成功挂起后，GetThreadContext失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
