windows EnumProcesses() 与 CreateToolhelp32Snapshot()

EnumProcesses() vs CreateToolhelp32Snapshot()

提问by jay.lee

I was wondering if there are any differences - mostly performance wise - between the two Win32 API functions EnumProcesses()and CreateToolhelp32Snapshot()for enumerating all active processes and loaded modules. Or if one is better than the other to use and why.

我想知道在枚举所有活动进程和加载的模块的两个 Win32 API 函数EnumProcesses()和CreateToolhelp32Snapshot()之间是否存在任何差异 - 主要是性能方面的差异。或者，如果一个比另一个更好用，为什么。

采纳答案by Luke

I think they are pretty much the same in terms of performance (and results) as they both call the same underlying NT API, though CreateToolhelp32Snapshot() may have a slight overhead as it creates a section object and copies all the information to it whereas EnumProcesses()/EnumProcessModules() works directly with user-supplied buffers. The difference is probably negligible in real world performance, though.

我认为它们在性能（和结果）方面几乎相同，因为它们都调用相同的底层 NT API，尽管 CreateToolhelp32Snapshot() 可能有轻微的开销，因为它创建了一个部分对象并将所有信息复制到它，而 EnumProcesses ()/EnumProcessModules() 直接使用用户提供的缓冲区。不过，在现实世界的性能中，这种差异可能可以忽略不计。

I slightly prefer EnumProcesses() as it is (IMO) a simpler API to use, but CreateToolhelp32Snapshot() returns more information if you need it. The only downside to EnumProcesses() is that you are supposed to call it in a loop as you may not have allocated a large enough buffer; CreateToolhelp32Snapshot() takes care of the buffer management for you. In practice I just allocate a buffer on the stack large enough to hold 1024 process ids or module handles; so far I have not come across a system where either of these limits was even remotely close to being reached. Of course we said the same thing about MAX_PATH not so long ago and now we are running into problems with that...

我稍微更喜欢 EnumProcesses()，因为它 (IMO) 是一个更简单的 API，但如果需要，CreateToolhelp32Snapshot() 会返回更多信息。EnumProcesses() 的唯一缺点是您应该在循环中调用它，因为您可能没有分配足够大的缓冲区；CreateToolhelp32Snapshot() 为您负责缓冲区管理。实际上，我只是在堆栈上分配一个足够大的缓冲区来容纳 1024 个进程 ID 或模块句柄；到目前为止，我还没有遇到过一个系统，其中任何一个限制都远远接近于达到。当然，不久前我们对 MAX_PATH 也说了同样的话，现在我们遇到了问题......

回答by Alex

Here are results from few functions:

以下是几个函数的结果：

• EnumProcesses: 16 msec, 207 processes
• CreateToolhelp32Snapshot: 141 msec (16 msec), 207 processes
• WTSEnumerateProcesses: 16 msec, 207 processes
• WTSEnumerateProcessesEx(WTS_CURRENT_SESSION): 16 msec, 98 processes
• WTSEnumerateProcessesEx(WTS_ANY_SESSION): 16 msec, 207 processes

• EnumProcesses：16 毫秒，207 个进程
• CreateToolhelp32Snapshot：141 毫秒（16 毫秒），207 个进程
• WTSEnumerateProcesses：16 毫秒，207 个进程
• WTSEnumerateProcessesEx(WTS_CURRENT_SESSION)：16 毫秒，98 个进程
• WTSEnumerateProcessesEx(WTS_ANY_SESSION)：16 毫秒，207 个进程

Machine is running Windows 8 with UAC enabled, user is not elevated (e.g. have no access to system processes). Main process is 32-bit, machine is 64-bit, so plenty of 64-bit processes around. There are: session 0 for system, session 1 for current console user, session 2 for another fast-switch user. 207 processes in total (these are both 32- and 64-bit, including pseudo "system" process) - 207 is also confirmed by Process Explorer. Among these 207 processes: 23 processes are for session 2, 98 processes - for session 1, and remaining - for session 0.

机器在启用 UAC 的情况下运行 Windows 8，用户未被提升（例如无法访问系统进程）。主进程是 32 位的，机器是 64 位的，所以周围有很多 64 位进程。有：系统会话0，当前控制台用户会话1，另一个快速切换用户会话2。总共 207 个进程（这些都是 32 位和 64 位，包括伪“系统”进程） - Process Explorer 也确认了 207。在这 207 个进程中：23 个进程用于会话 2，98 个进程用于会话 1，其余进程用于会话 0。

Results are for cycle of 10 single function call. They are 100% reproducible on each run.

结果是针对 10 次单个函数调用的循环。它们在每次运行中都是 100% 可重现的。

For CreateToolhelp32Snapshot the main result is call of CreateToolhelp32Snapshot itself, and second result (in brackets) is cycle with First/Next.

对于 CreateToolhelp32Snapshot，主要结果是调用 CreateToolhelp32Snapshot 本身，第二个结果（括号中）是循环使用 First/Next。

I think people confuse "enumerate all processes" (get PIDs) and "get name of process/exe". The first one ("enumerate") has no issues with x32/x64 cross-bitness whatsoever. But the latter one ("get name") does have issues - not every method will work across x32/x64.

我认为人们混淆了“枚举所有进程”（获取 PID）和“获取进程/exe 的名称”。第一个（“枚举”）在 x32/x64 交叉位方面没有任何问题。但后一个（“获取名称”）确实有问题——并非每种方法都适用于 x32/x64。

回答by Dmitriy

I don't remember exactly, but unlike CreateToolhelp32Snapshot(), EnumProcesses() has one of two or both limitations: 1. Doesn't enumerate 64-bit processes if called from 32-bit process on x64 OS. 2. Doesn't enumerate elevated processes on Vista and Win7.

我记不太清楚了，但与 CreateToolhelp32Snapshot() 不同的是，EnumProcesses() 有两个或两个限制之一： 1. 如果从 x64 操作系统上的 32 位进程调用，则不会枚举 64 位进程。2. 不枚举 Vista 和 Win7 上的提升进程。

回答by neo85

CreateToolhelp32Snapshot FTW. EnumProcesses doesnt enumerate all system processes like all instances of svchost.exe at least on Win XP.

CreateToolhelp32Snapshot FTW。EnumProcesses 至少在 Win XP 上不会像 svchost.exe 的所有实例那样枚举所有系统进程。

回答by sharptooth

IMO the key difference is in priviledges requirements. I've seen cases in which EnumProcesses()would fail, but CreateToolhelp32Snapshot()ran perfectly well.

IMO 的主要区别在于特权要求。我见过EnumProcesses()会失败但CreateToolhelp32Snapshot()运行良好的情况。

So once I needed to write code that would detect a certain process on a system and react appropriately. I wrote it using EnumProcesses()and it worked fine on my machine, but not on testers' machines. I just rewrote it with CreateToolhelp32Snapshot()and I've never heard of any problems with it anymore.

因此，有一次我需要编写代码来检测系统上的某个进程并做出适当的反应。我使用EnumProcesses()它编写了它，它在我的机器上运行良好，但在测试人员的机器上运行良好。我只是用它重写了它，CreateToolhelp32Snapshot()而且我再也没有听说过它有任何问题。