CreateToolhelp32Snapshot hangs on W2K SP1 (and SP2)

Discussion:

(too old to reply)

Marc Sherman

2003-12-07 22:03:56 UTC

Hello,

I found the following posting on this subject back in 2000. I'm having
the same problem and was wondering if anyone has found a solution. The
original posting follows:

----

I'm trying to enumerate modules. Sometimes CreateToolhelp32Snapshot
hangs
with the following call stack:

NTDLL! ZwWaitForSingleObject + 11 bytes
NTDLL! RtlQueryProcessDebugInformation + 285 bytes
KERNEL32! ThpCreateRawSnap + 230 bytes
KERNEL32! CreateToolhelp32Snapshot + 42 bytes

Does anyone know what might be causing this?

----

Marc

Ivan Brugiolo [MSFT]

2003-12-08 00:00:52 UTC

Permalink

most likely the remote thread that is collecting the requested data
on the remote process has not finished yet.
You should attach a debugger to the remote
process and see what that thread is doing
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

Post by Marc Sherman
Hello,
I found the following posting on this subject back in 2000. I'm having
the same problem and was wondering if anyone has found a solution. The
----
I'm trying to enumerate modules. Sometimes CreateToolhelp32Snapshot
hangs
NTDLL! ZwWaitForSingleObject + 11 bytes
NTDLL! RtlQueryProcessDebugInformation + 285 bytes
KERNEL32! ThpCreateRawSnap + 230 bytes
KERNEL32! CreateToolhelp32Snapshot + 42 bytes
Does anyone know what might be causing this?
----
Marc

unknown

2003-12-08 00:26:19 UTC

Permalink

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 debugger to the target
process. Many debuggers 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
http://www.microsoft.com/whdc/ddk/debugging/default.mspx)
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.

Marc Sherman

2003-12-08 20:25:21 UTC

Permalink

I'm using Win2k SP2. I'll try attaching with Windbg and see if it's a
loaderlock problem. If this is indeed the problem, I'm guessing there
are no good workarounds. I'll just use the psapi instead. Are there
any known problems like this with the psapi?

thanks,
Marc

Post by unknown
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 debugger to the target
process. Many debuggers 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
http://www.microsoft.com/whdc/ddk/debugging/default.mspx)
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.