Friday, April 21, 2006

How to find out on which thread a blocked thread is waiting

First get the stack of the blocked thread by

0:002> kb
ChildEBP RetAddr Args to Child
00edfdd8 7c90e9c0 7c8025db 0000026c 00000000 ntdll!KiFastSystemCallRet
00edfddc 7c8025db 0000026c 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
00edfe40 7c802542 0000026c ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
00edfe54 6640114a 0000026c ffffffff 00813190 kernel32!WaitForSingleObject+0x12

The first parameter passed to WaitForSingleObject is the handle to the thread this thread is waiting for (Precondition: we are waiting for a thread and not another synchronisation object).

We can get more information about this handle by

0:002> !handle 0000026c f
Handle 0000026c
Type Thread
Attributes 0
GrantedAccess 0x1f03ff:
HandleCount 7
PointerCount 10
Object specific information
Thread Id b94.ff4
Priority 3
Base Priority -16

Now we identified the questionable thread with b94.ff4


Anonymous said...

The entry helped me to find why my visual studio hanged. Thanks.
This is the devenv.exe hang dump by adplus.

0:000> kb
ChildEBP RetAddr Args to Child
0012f184 7c94e9c0 7c8025db 000004fc 00000000 ntdll!KiFastSystemCallRet
0012f188 7c8025db 000004fc 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
0012f1ec 7c802542 000004fc ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
0012f200 53820169 000004fc ffffffff 00000000 kernel32!WaitForSingleObject+0x12
0012f288 537fc73d 00000000 09645e10 00000000 csproj!RunProcess+0x135
0012f3c8 537fbe13 096682e0 096740b0 0012f428 csproj!CLangSatelliteAssembly::CallLinker+0x2fb

0:000> !handle 000004fc f
Handle 000004fc
Type Process
Process Id 2568
Parent Process 2364

0:000> |
. 0 id: 93c examine name: G:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\devenv.exe

0:000> ?93c
Evaluate expression: 2364 = 0000093c

// This is the parent process for waited process.
// So what process is this process waiting for?
// I checked adplus's process list...

0 64 2568 al.exe Title: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\al.exe
Command Line:

// Now I know devenv is waiting for al (linker).
// I can see csproj!CLangSatelliteAssembly::CallLinke is called before hang.
// al.exe may be launched by csproj!RunProcess.
// Pennies' dropped.

But unfortunately I didn't take al.exe's dump.
So I can't investigate any further from here.
I don't care because I killed devenv ;-)

By the way, are you willing to provide RSS feed for this blog?
I really interested in your blog and want keep myself updated. Really.

Volker von Einem said...

Hi anonymous,

Sorry for the late reply, but I didn't provide my email in the 'Moderate Comments' section. So I didn't get notified on anonymous posts.

I'm glad that my posting could help you.

You can get a here:

Anonymous said...

thanks , confirmed a deadlock in my code with help from your article. :)

zmrcic said...

I have a little problem. here is mdmp from windbg.
0012ccb4 7c90df5a 7c8025db 000000c0 00000000 ntdll!KiFastSystemCallRet
0012ccb8 7c8025db 000000c0 00000000 00000000 ntdll!ZwWaitForSingleObject+0xc
0012cd1c 79161806 000000c0 ffffffff 00000000 kernel32!WaitForSingleObjectEx+0xa8
0012cd50 79161847 000000c0 ffffffff 00000000 clr!CLREvent::CreateManualEvent+0xf6
0012cda0 7916171d 00000000 4efe7fc1 00000000 clr!CLREvent::CreateManualEvent+0x137
0012cde0 7916173e ffffffff 00000000 00000000 clr!CLREvent::WaitEx+0x126
0012cdf4 79183e9c ffffffff 00000000 00000000 clr!CLREvent::Wait+0x19
0012ce08 79183d0d 00000000 4efe7c71 0133bd14 clr!WKS::GCHeap::WaitUntilGCComplete+0x36
0012ce50 792cd58e 01691f48 4e5dad81 791443b8 clr!Thread::RareDisablePreemptiveGC+0x18b
0012ce74 79142281 0012ce80 00000000 0012cec0 clr!OnHijackScalarWorker+0x88
0012e038 79141a91 7917c0bf 4efe51b5 00000003 clr!OnHijackScalarTripThread+0x21
0012e03c 7917c0bf 4efe51b5 00000003 0012e4f8 clr!_EH_epilog3_GS+0xa
0012e390 00000000 00000000 00000000 00000000 clr!MethodTable::GetTargetFromMethodDescAndServer+0x20b

Everything is working ok on 24/7 app on 50+ machines. But, suddenly..hang. This is from pc with XP SP3. Any idea what is the problem?

Volker von Einem said...

@zmrcic: Did you try !handle 000000c0 as described in my post?