<p>我发现了一种更快的方法;不幸的是,它依赖于一个没有文档的API,<code>NtResumeProcess</code>。这就像它听起来的那样-接受一个进程句柄,并将<code>ResumeThread</code>的等价物应用于进程中的每个线程。Python/ctypes使用它的代码类似于</p>
<pre><code>import ctypes
from ctypes.wintypes import HANDLE, LONG, ULONG
ntdll = ctypes.WinDLL("ntdll.dll")
RtlNtStatusToDosError = ntdll.RtlNtStatusToDosError
NtResumeProcess = ntdll.NtResumeProcess
def errcheck_ntstatus(status, *etc):
if status < 0: raise ctypes.WinError(RtlNtStatusToDosError(status))
return status
RtlNtStatusToDosError.argtypes = (LONG,)
RtlNtStatusToDosError.restype = ULONG
# RtlNtStatusToDosError cannot fail
NtResumeProcess.argtypes = (HANDLE,)
NtResumeProcess.restype = LONG
NtResumeProcess.errcheck = errcheck_ntstatus
def resume_subprocess(proc):
NtResumeProcess(int(proc._handle))
</code></pre>
<p>我在一台闲置的windows7虚拟机上测量到,使用这种技术的进程设置开销比使用Toolhelp要少20%。正如所期望的,在Toolhelp的工作方式下,性能增量随着系统上线程的增多而变大,不管它们是否与所讨论的程序有关。在</p>
<p>鉴于<code>NtResumeProcess</code>及其对应的{<cd4>}的明显的通用性,我想知道为什么它们从未被记录下来,也没有被赋予kernel32包装器。它们被一些核心系统DLL和EXE所使用,所有这些DLL和EXE都是Windows错误报告机制的一部分(<code>faultrep.dll</code>,<code>werui.dll</code>,<code>werfault.exe</code>,<code>dwwin.exe</code>等)的一部分,并且似乎不会在文档名称下重新公开功能。这些函数似乎不太可能在不更改名称的情况下改变其语义,但应该准备一个防御性编码的程序来让它们消失(我想应该回到toolhelp)。在</p>