winapi – GetThreadContext在Windows 7中成功挂起后,失败

前端之家收集整理的这篇文章主要介绍了winapi – GetThreadContext在Windows 7中成功挂起后,失败前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
Windows 7中的抽样分析器遇到了一个奇怪的问题(在以前的Windows操作系统上没有这样的问题AFAICT,不论是32位还是64位)。

分析器通过定期挂起一个带有SuspendThread的线程,然后在调用ResumeThread重新启动过程之前查看与GetThreadContext的上下文。所有这一切都是从多媒体定时器的线程(准确性,大约1kHZ,其在Windows 7之前的操作系统通常导致可忽略的性能损失)的上下文中完成。

仅在Windows 7和Windows 7下,即使对SuspendThread(和ResumeThread)的调用都成功,对GetThreadContext的调用失败,出现错误

ERROR_NOACCESS
998 (0x3E6)
Invalid access to memory location.

有非常高的可能性,虽然不是所有的时间。

我的意思是,对于某些剖析运行,一切都将像在其他操作系统上一样工作(所有的GetThreadContext调用都会成功),但是对于其他运行,它们几乎都会失败(保存十几个可能是几千分之一) 。正是发生与完全相同的二进制文件,相同的参数。

我已经对模糊的类似的问题尝试了重复GetThreadContext调用的建议,没有更多的成功。我也尝试在SuspendThread和GetThreadContext之间做一个Sleep,然后GetThreadContext更经常地成功,尽管它导致剧烈的放缓。

然而,它建议Windows 7操作系统从SuspendThread返回,而线程可能尚未暂停 – 尽管如此,我不知道如何或如果正确等待暂停,循环线程并敲击GetThreadContext不这样做

编辑:16位字节对齐GetThreadContext的CONTEXT结构的地址,正如丹·巴特利特所建议的那样,似乎在诀窍!

看着 GetThreadContext功能,它提到

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.

并查看此文件,_CONTEXT声明为

typedef struct DECLSPEC_ALIGN(16) _CONTEXT {
...

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

猜你在找的Windows相关文章