Hey, that's my post :)
I don't remember the details, but I think in my case the problem was that
the target process was deadlocked on the loader lock. Toolhelp32 tries
to inject a remote thread into the process, and if the loader lock is held,
this remote thread cannot initialize itself and hangs.
Similar hangs can occur if you try to attach a de *** to the target
process. Many de *** s inject a remote thread on attach which then
calls DebugBreak(). Windbg is smart enough to notice that the process
seems to be hung, and after some timeout it automatically switches to
"non-invasive attach" which simply suspends all threads in the target and
allows you to examine memory/call stacks (but you can't set breakpoints
or continue execution).
I don't know if this problem was ever fixed. What OS are you using?
You can check if the loader lock is causing the hang in your case. Attach
windbg (get the latest version from
to the target process (use -pv for non-invasive attach, or wait until normal
attach times out) then do !locks. If your symbol path is right then you
should see that ntdll!loaderlock critical section is locked and which
thread locked it.