views:

1533

answers:

3

How do I find out which thread is the owner of my Event handle in windbg:

I'm running

!handle 00003aec f

and get

Handle 00003aec
  Type          Event
  Attributes    0
  GrantedAccess 0x1f0003:
     Delete,ReadControl,WriteDac,WriteOwner,Synch
     QueryState,ModifyState
  HandleCount   2
  PointerCount  4
  Name          <none>
  No object specific information available

back, and as there is no Name I haven't figured out how to get the owner out to prove which thread my thread is waiting on

[Edit] I must work against a dump as the original process needs to be restarted on the users machine, so can't debug a live session

The best discussion on the subject I've found so far is on this blog, but unfortunately we end up using different lock methods (I end up using WaitForMultipleObjectsEx and the description is for WaitForSingleObject), and he seems to have access to a live process

the stacktrace of my thread (the one that is blocked on something and where I'm looking for the current owner) is:

0:045> k9
ChildEBP RetAddr 
1130e050 7c90e9ab ntdll!KiFastSystemCallRet
1130e054 7c8094e2 ntdll!ZwWaitForMultipleObjects+0xc
1130e0f0 79ed98fd kernel32!WaitForMultipleObjectsEx+0x12c
1130e158 79ed9889 mscorwks!WaitForMultipleObjectsEx_SO_TOLERANT+0x6f
1130e178 79ed9808 mscorwks!Thread::DoAppropriateAptStateWait+0x3c
1130e1fc 79ed96c4 mscorwks!Thread::DoAppropriateWaitWorker+0x13c
1130e24c 79ed9a62 mscorwks!Thread::DoAppropriateWait+0x40
1130e2a8 79e78944 mscorwks!CLREvent::WaitEx+0xf7
1130e2bc 7a162d84 mscorwks!CLREvent::Wait+0x17
1130e33c 7a02fd94 mscorwks!CRWLock::RWWaitForSingleObject+0x6d
1130e364 79ebd3af mscorwks!CRWLock::StaticAcquireWriterLock+0x12e
1130e410 00f24557 mscorwks!CRWLock::StaticAcquireWriterLockPublic+0xc9
A: 
I can't use !htrace -enable as I need to grab the dump from a user's machine (and quickly restart so he can continue his work), otherwise it looks very promising
Oskar
+1  A: 
AaronBa
I didn't see a lock owner from !dso at the time, and doing a clrstack on all other threads doesn't show who has the lock as the owning thread is unlikely to still be running locking statements (it already has the lock and is doing real work somewhere, or is also blocked on another lock)
Oskar
+1  A: 

Use the !htrace command to get the thread ID. You must first, possibly at the start of the program, enable the collection of traces with !htrace -enable.

0:001> !htrace 00003aec
--------------------------------------
Handle = 0x00003aec - OPEN
Thread ID = 0x00000b48, Process ID = 0x000011e8

...

The above output is fictional, it will be different for your system. But it will give you the piece of information you need - the thread ID (0x00000b48 in my example).

I must work against a dump as the original process needs to be restarted on the users machine, so can't debug a live session.

I am not 100% sure but I think this will work:

  1. Attach to the process and run !htrace -enable
  2. Detach from the process with qd. The executable will continue.
  3. You can now take a dump file and use the above command - I think you will have the described results.
smink