I don't have a question, but I wanted to let you know that you can enumerate processes and threads via NtQuerySystemInformation instead of CreateToolhelp32Snapshot, and it's much faster. The latter is slow only due to weird file section mapping behavior and not due to the actual query.
Thanks for the tip, I tried that. It might be a bit faster, but in my tests, it wasn't significant, and it still enumerates all system threads which means that it becomes slower the more threads your system has.
A truly fast and documented solution is using PssCaptureSnapshot, it can enumerate only threads of the target process. It uses NtGetNextThread under the hood. The downside: it's only available from Windows 8.1.
Using NtGetNextThread is not only fast and available from Windows Vista, it also allows avoiding race conditions - what happens if a new thread is created after the snapshot is created? A snapshot returns thread ids, what happens if one of the threads is destroyed? What happens if the thread id is reused (unlikely but possible)? I believe all the benefits I'm getting by using NtGetNextThread are worth using an undocumented function.
dataflow|3 years ago
m417z|3 years ago
A truly fast and documented solution is using PssCaptureSnapshot, it can enumerate only threads of the target process. It uses NtGetNextThread under the hood. The downside: it's only available from Windows 8.1.
Using NtGetNextThread is not only fast and available from Windows Vista, it also allows avoiding race conditions - what happens if a new thread is created after the snapshot is created? A snapshot returns thread ids, what happens if one of the threads is destroyed? What happens if the thread id is reused (unlikely but possible)? I believe all the benefits I'm getting by using NtGetNextThread are worth using an undocumented function.
See also the research that I linked in the blog post: https://github.com/diversenok/Suspending-Techniques#snapshot...