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

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


"Marc Sherman" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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

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/de...g/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" wrote:

> 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?

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

"Pavel Lebedinsky" <m_pll ./. hotmail ./. com> wrote in message news:<(E-Mail Removed)>...
> 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/de...g/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" wrote:
>
> > 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?