Deadlock

Filter Driver Win2k:

Does this output show a dead lock ???
If so can I get to know what are the name of the locks who are in dead
lock ???

Can some one explain me what are the following :

Contention Count
NumberOfSharedWaiters
NumberOfExclusiveWaiters
Threads Waiting On Exclusive Access


kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8046db80) Shared 1 owning threads
Contention Count = 59
Threads: 8189d3a0-01<*>
KD: Scanning for held locks…

Resource @ 0x81856cd4 Shared 1 owning threads
Contention Count = 95
NumberOfSharedWaiters = 5
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<*> 816d2da0-01 8189d3a0-01 8189dda0-01

81641ce0-01 81748da0-01

Threads Waiting On Exclusive Access:
81563020
KD: Scanning for held
locks…

Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<*>

Threads Waiting On Exclusive Access:
816ee740
KD: Scanning for held locks…

Resource @ 0x816596c0 Shared 1 owning threads
Threads: 8189db23-01<*> *** Actual Thread 8189DB20
2592 total locks, 4 locks currently held

ComponentManagerRegistry Lock … synchronizes write access to registry.
check where the owning thread hangs!

Usual szenario: a thread owns this lock and hangs in 3rd party filterdriver
or somewhere else …
most every other thread sooner or later stops when trying to write to reg.

cu

----- Original Message -----
From: “Anurag Sarin”
To: “Kernel Debugging Interest List”
Sent: Thursday, November 25, 2004 12:36 PM
Subject: [windbg] Deadlock

Filter Driver Win2k:

Does this output show a dead lock ???
If so can I get to know what are the name of the locks who are in dead
lock ???

Can some one explain me what are the following :

Contention Count
NumberOfSharedWaiters
NumberOfExclusiveWaiters
Threads Waiting On Exclusive Access

------------------------------------------------------------------------
kd> !locks
DUMP OF ALL RESOURCE OBJECTS
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8046db80) Shared 1 owning threads
Contention Count = 59
Threads: 8189d3a0-01<>
KD: Scanning for held locks…

Resource @ 0x81856cd4 Shared 1 owning threads
Contention Count = 95
NumberOfSharedWaiters = 5
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<
> 816d2da0-01 8189d3a0-01 8189dda0-01

81641ce0-01 81748da0-01

Threads Waiting On Exclusive Access:
81563020
KD: Scanning for held
locks…


Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<>

Threads Waiting On Exclusive Access:
816ee740
KD: Scanning for held locks…

Resource @ 0x816596c0 Shared 1 owning threads
Threads: 8189db23-01<
> *** Actual Thread 8189DB20
2592 total locks, 4 locks currently held


You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

This one looks bad to me:

Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<*>

Threads Waiting On Exclusive Access:
816ee740

Note the same thread has it shared and is now waiting for exclusive;
definitely worth looking at the stack for this one… (note - if it was
trying to convert shared to exclusive it would have worked since it’s the
only thread with shared access - this looks like two code paths that don’t
expect to be called recursively…)

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Thursday, November 25, 2004 6:36 AM
To: Kernel Debugging Interest List
Subject: [windbg] Deadlock

Filter Driver Win2k:

Does this output show a dead lock ???
If so can I get to know what are the name of the locks who are in dead
lock ???

Can some one explain me what are the following :

Contention Count
NumberOfSharedWaiters
NumberOfExclusiveWaiters
Threads Waiting On Exclusive Access


kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8046db80) Shared 1 owning threads
Contention Count = 59
Threads: 8189d3a0-01<*>
KD: Scanning for held locks…

Resource @ 0x81856cd4 Shared 1 owning threads
Contention Count = 95
NumberOfSharedWaiters = 5
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<*> 816d2da0-01 8189d3a0-01 8189dda0-01

81641ce0-01 81748da0-01

Threads Waiting On Exclusive Access:
81563020
KD: Scanning for held
locks…

Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<*>

Threads Waiting On Exclusive Access:
816ee740
KD: Scanning for held locks…

Resource @ 0x816596c0 Shared 1 owning threads
Threads: 8189db23-01<*> *** Actual Thread 8189DB20
2592 total locks, 4 locks currently held


You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

You are write , I produce the same output every time the driver hangs .
I have the !thread stack trace . Can I any how get to know which area of
my code is this if , its my code.

BTW, I earlier had 3 Fast Mutes locks used for three link lists , I
switched to Normal Mutex . That too One for all the three. But the
hang output is the same.

Any Ideas???

kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8046db80) Shared 1 owning threads
Contention Count = 23
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 3
Threads: 8189d3a0-01<*> 8169aba0-01

Threads Waiting On Exclusive Access:
816924e0 816a1020 816ee160
KD: Scanning for held locks…

Resource @ 0x81856cd4 Shared 1 owning threads
Contention Count = 30
NumberOfSharedWaiters = 7
NumberOfExclusiveWaiters = 1
Threads: 8150d9e0-01<*> 816873a0-01 81607da0-01 8162bae0-01

8189d3a0-01 816d5860-01 8163dcc0-01 81748da0-01

Threads Waiting On Exclusive Access:
814d4200
KD: Scanning for held
locks…

Resource @ 0x815101c8 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 8150d9e0-01<*>

Threads Waiting On Exclusive Access:
8150d9e0
KD: Scanning for held locks.

Resource @ 0x81898fc0 Shared 1 owning threads
Threads: 8189d8a3-01<*> *** Actual Thread 8189D8A0
1645 total locks, 4 locks currently held

kd> !thread 8150d9e0
THREAD 8150d9e0 Cid 2e0.448 Teb: 7ffd8000 Win32Thread: e2f69848 WAIT:
(Executive) KernelMode Non-Alertable
8155f148 SynchronizationEvent
8150dac8 NotificationTimer
IRP List:
bcc36e48: (0006,01b4) Flags: 00000404 Mdl: 00000000
Not impersonating
Owning Process 81642020
Wait Start TickCount 6071 Elapsed Ticks: 133
Context Switch Count 56 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Win32 Start Address 0x65c4b770
Stack Init f148d000 Current f148c3a0 Base f148d000 Limit f1489000 Call 0
Priority 14 BasePriority 8 PriorityDecrement 6 DecrementCount 16

ChildEBP RetAddr Args to Child
f148c3b8 8042de88 00000000 815101c8 8150d9e0 nt!KiSwapThread+0xc5
f148c3e0 8041766c 8155f148 00000000 00000000
nt!KeWaitForSingleObject+0x1a1
f148c420 80416b4d 815101c8 005101c8 f148c438 nt!ExpWaitForResource+0x1ac
f148c430 80416b92 f148c454 80416b3d 815101c8
nt!ExpAcquireResourceExclusiveLite+0x64
f148c438 80416b3d 815101c8 00000001 00000000
nt!ExAcquireResourceExclusiveLite+0x4b
f148c454 80416b92 f148c6bc bff05e49 815101c8
nt!ExpAcquireResourceExclusiveLite+0x55
f148c45c bff05e49 815101c8 00000001 00000000
nt!ExAcquireResourceExclusiveLite+0x4b
f148c6bc bff0ad63 f148c704 bcc36e48 81856800 +0xbff05e49
f148c834 8041fb8b 81856800 bcc36e48 816e9780 +0xbff0ad63
f148c894 8041fb8b 816e9780 bcc36e48 8150c6e8 nt!IopfCallDriver+0x35
f148c8a8 8049d134 80064fac 81896340 00000001 nt!IopfCallDriver+0x35
f148c8dc 804a5d99 81642020 816e9780 00100000 nt!IopCloseFile+0x275
f148c908 8044fbc8 81642020 8150c6d4 8150c6e8
nt!ObpDecrementHandleCount+0x13c
f148c9bc 80465691 00000290 0048ca34 f148ca34 nt!NtClose+0x1f0
f148c9bc 804009d1 00000290 0048ca34 f148ca34 nt!KiSystemService+0xc4
f148ca58 804af3d9 00000001 00000010 e1001610 nt!ZwClose+0xb
f148cba0 8041fb8b 816e9780 bcc00e48 8153d0e8
nt!SepMaximumAccessCheck+0x65
f148cc0c 80432a6d 816b0ca8 8150d9e0 00000001 nt!IopfCallDriver+0x35
f148cc44 80442c8a f148cc70 65aa9009 00000000 nt!KiUnwaitThread+0xcd
f148cc94 804a0a6a e2f6a000 e2f6a004 00000019
nt!MiAddValidPageToWorkingSet+0xa1
f148ccec 804a07b5 00000000 e2f6a000 8153d040
nt!MmFlushVirtualMemory+0x364
f148cd4c 80465691 ffffffff 013afc70 013afc7c
nt!NtFlushVirtualMemory+0x104
f148cd4c 77f8a424 ffffffff 013afc70 013afc7c nt!KiSystemService+0xc4
013afc74 00000000 00000000 00000000 00000000 +0x77f8a424

-----Original Message-----
From: Graham, Simon [mailto:xxxxx@stratus.com]
Sent: Thursday, November 25, 2004 8:10 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Deadlock

This one looks bad to me:

Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<*>

Threads Waiting On Exclusive Access:
816ee740

Note the same thread has it shared and is now waiting for exclusive;
definitely worth looking at the stack for this one… (note - if it was
trying to convert shared to exclusive it would have worked since it’s
the only thread with shared access - this looks like two code paths that
don’t expect to be called recursively…)

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Thursday, November 25, 2004 6:36 AM
To: Kernel Debugging Interest List
Subject: [windbg] Deadlock

Filter Driver Win2k:

Does this output show a dead lock ???
If so can I get to know what are the name of the locks who are in dead
lock ???

Can some one explain me what are the following :

Contention Count
NumberOfSharedWaiters
NumberOfExclusiveWaiters
Threads Waiting On Exclusive Access


kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8046db80) Shared 1 owning threads
Contention Count = 59
Threads: 8189d3a0-01<*>
KD: Scanning for held locks…

Resource @ 0x81856cd4 Shared 1 owning threads
Contention Count = 95
NumberOfSharedWaiters = 5
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<*> 816d2da0-01 8189d3a0-01 8189dda0-01

81641ce0-01 81748da0-01

Threads Waiting On Exclusive Access:
81563020
KD: Scanning for held
locks…

Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<*>

Threads Waiting On Exclusive Access:
816ee740
KD: Scanning for held locks…

Resource @ 0x816596c0 Shared 1 owning threads
Threads: 8189db23-01<*> *** Actual Thread 8189DB20
2592 total locks, 4 locks currently held


You are currently subscribed to windbg as: unknown lmsubst tag argument:
‘’ To unsubscribe send a blank email to
xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@divassoftware.com To
unsubscribe send a blank email to xxxxx@lists.osr.com

RE: [windbg] DeadlockAnurag

If you have fast mutex or dispatcher mutex I think !locks in either case is not a help for you. Say why do you not instead use ERESOURCE then !locks is a help for you?

If you know what things yo rcode uses to synchronize then why not just look at the threads that have and wait for these things to start? Like start by looking at thesr things be htem fast muetx or dispatcher mutex or resource or whatever?

I just debug today a deadlock from crash dump Maybe that story is ueful fo ryou. I start with “!process 0 7” and have a look around. I see lot of thread in similar calls CmpLockRgeistry. Look a bit more at that next call acquires a resource look at the resource using !lock almost forty threads waiting on one resource and once thread has the resource. That is all my threads in CmpLockRegistry. So then I look at this thread who has he lock. He is waitng for some other resource in some routine something or other SharedVcb. So have a look at that resource. Somehtinbg like ten threads wait there. See a thread has that resource. Find he is waiting on another reousrce the Paging io resource for some file FCB. Keep going I find the thread has that resource is waiting on something else … in the end you find the loop.

Cheers
Lyndon
“Anurag Sarin” wrote in message news:xxxxx@windbg…

You are write , I produce the same output every time the driver hangs . I have the !thread stack trace . Can I any how get to know which area of my code is this if , its my code.

BTW, I earlier had 3 Fast Mutes locks used for three link lists , I switched to Normal Mutex . That too One for all the three. But the hang output is the same.

Any Ideas???

kd> !locks
DUMP OF ALL RESOURCE OBJECTS
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8046db80) Shared 1 owning threads
Contention Count = 23
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 3
Threads: 8189d3a0-01<> 8169aba0-01

Threads Waiting On Exclusive Access:
816924e0 816a1020 816ee160
KD: Scanning for held locks…

Resource @ 0x81856cd4 Shared 1 owning threads
Contention Count = 30
NumberOfSharedWaiters = 7
NumberOfExclusiveWaiters = 1
Threads: 8150d9e0-01<
> 816873a0-01 81607da0-01 8162bae0-01
8189d3a0-01 816d5860-01 8163dcc0-01 81748da0-01

Threads Waiting On Exclusive Access:
814d4200
KD: Scanning for held locks…

Resource @ 0x815101c8 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 8150d9e0-01<>

Threads Waiting On Exclusive Access:
8150d9e0
KD: Scanning for held locks.

Resource @ 0x81898fc0 Shared 1 owning threads
Threads: 8189d8a3-01<
> Actual Thread 8189D8A0
1645 total locks, 4 locks currently held

kd> !thread 8150d9e0
THREAD 8150d9e0 Cid 2e0.448 Teb: 7ffd8000 Win32Thread: e2f69848 WAIT: (Executive) KernelMode Non-Alertable
8155f148 SynchronizationEvent
8150dac8 NotificationTimer
IRP List:
bcc36e48: (0006,01b4) Flags: 00000404 Mdl: 00000000
Not impersonating
Owning Process 81642020
Wait Start TickCount 6071 Elapsed Ticks: 133
Context Switch Count 56 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Win32 Start Address 0x65c4b770
Stack Init f148d000 Current f148c3a0 Base f148d000 Limit f1489000 Call 0
Priority 14 BasePriority 8 PriorityDecrement 6 DecrementCount 16

ChildEBP RetAddr Args to Child
f148c3b8 8042de88 00000000 815101c8 8150d9e0 nt!KiSwapThread+0xc5
f148c3e0 8041766c 8155f148 00000000 00000000 nt!KeWaitForSingleObject+0x1a1
f148c420 80416b4d 815101c8 005101c8 f148c438 nt!ExpWaitForResource+0x1ac
f148c430 80416b92 f148c454 80416b3d 815101c8 nt!ExpAcquireResourceExclusiveLite+0x64
f148c438 80416b3d 815101c8 00000001 00000000 nt!ExAcquireResourceExclusiveLite+0x4b
f148c454 80416b92 f148c6bc bff05e49 815101c8 nt!ExpAcquireResourceExclusiveLite+0x55
f148c45c bff05e49 815101c8 00000001 00000000 nt!ExAcquireResourceExclusiveLite+0x4b
f148c6bc bff0ad63 f148c704 bcc36e48 81856800 +0xbff05e49
f148c834 8041fb8b 81856800 bcc36e48 816e9780 +0xbff0ad63
f148c894 8041fb8b 816e9780 bcc36e48 8150c6e8 nt!IopfCallDriver+0x35
f148c8a8 8049d134 80064fac 81896340 00000001 nt!IopfCallDriver+0x35
f148c8dc 804a5d99 81642020 816e9780 00100000 nt!IopCloseFile+0x275
f148c908 8044fbc8 81642020 8150c6d4 8150c6e8 nt!ObpDecrementHandleCount+0x13c
f148c9bc 80465691 00000290 0048ca34 f148ca34 nt!NtClose+0x1f0
f148c9bc 804009d1 00000290 0048ca34 f148ca34 nt!KiSystemService+0xc4
f148ca58 804af3d9 00000001 00000010 e1001610 nt!ZwClose+0xb
f148cba0 8041fb8b 816e9780 bcc00e48 8153d0e8 nt!SepMaximumAccessCheck+0x65
f148cc0c 80432a6d 816b0ca8 8150d9e0 00000001 nt!IopfCallDriver+0x35
f148cc44 80442c8a f148cc70 65aa9009 00000000 nt!KiUnwaitThread+0xcd
f148cc94 804a0a6a e2f6a000 e2f6a004 00000019 nt!MiAddValidPageToWorkingSet+0xa1
f148ccec 804a07b5 00000000 e2f6a000 8153d040 nt!MmFlushVirtualMemory+0x364
f148cd4c 80465691 ffffffff 013afc70 013afc7c nt!NtFlushVirtualMemory+0x104
f148cd4c 77f8a424 ffffffff 013afc70 013afc7c nt!KiSystemService+0xc4
013afc74 00000000 00000000 00000000 00000000 +0x77f8a424

-----Original Message-----
From: Graham, Simon [mailto:xxxxx@stratus.com]
Sent: Thursday, November 25, 2004 8:10 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Deadlock

This one looks bad to me:

Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<
>

Threads Waiting On Exclusive Access:
816ee740

Note the same thread has it shared and is now waiting for exclusive; definitely worth looking at the stack for this one… (note - if it was trying to convert shared to exclusive it would have worked since it’s the only thread with shared access - this looks like two code paths that don’t expect to be called recursively…)

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Thursday, November 25, 2004 6:36 AM
To: Kernel Debugging Interest List
Subject: [windbg] Deadlock

Filter Driver Win2k:

Does this output show a dead lock ???
If so can I get to know what are the name of the locks who are in dead lock ???

Can some one explain me what are the following :

Contention Count
NumberOfSharedWaiters
NumberOfExclusiveWaiters
Threads Waiting On Exclusive Access

------------------------------------------------------------------------
kd> !locks
** DUMP OF ALL RESOURCE OBJECTS
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8046db80) Shared 1 owning threads
Contention Count = 59
Threads: 8189d3a0-01<
>
KD: Scanning for held locks…

Resource @ 0x81856cd4 Shared 1 owning threads
Contention Count = 95
NumberOfSharedWaiters = 5
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<
> 816d2da0-01 8189d3a0-01 8189dda0-01

81641ce0-01 81748da0-01

Threads Waiting On Exclusive Access:
81563020
KD: Scanning for held locks…


Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<
>

Threads Waiting On Exclusive Access:
816ee740
KD: Scanning for held locks…

Resource @ 0x816596c0 Shared 1 owning threads
Threads: 8189db23-01<
>*** Actual Thread 8189DB20
2592 total locks, 4 locks currently held


You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@divassoftware.com To unsubscribe send a blank email to xxxxx@lists.osr.com

The stack trace looks bogus to me - you are missing some symbols, and the
other stuff looks odd to me (SepMaximumAccessCheck calling ZwClose for
example).

Anyway, if you are not using ERESOURCE’s in your code then your locking is
not the cause of this (but your processing of IRPs, system calls made, etc
probably is the cause). You need to get the right symbols for NT (you are
using the Microsoft symbol server, right???) and your driver(s)…

/simgr


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Friday, November 26, 2004 5:36 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Deadlock

You are write , I produce the same output every time the driver hangs . I
have the !thread stack trace . Can I any how get to know which area of my
code is this if , its my code.

BTW, I earlier had 3 Fast Mutes locks used for three link lists , I switched
to Normal Mutex . That too One for all the three. But the hang output is
the same.

Any Ideas???

kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8046db80) Shared 1 owning threads
Contention Count = 23
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 3
Threads: 8189d3a0-01<*> 8169aba0-01

Threads Waiting On Exclusive Access:
816924e0 816a1020 816ee160
KD: Scanning for held locks…

Resource @ 0x81856cd4 Shared 1 owning threads
Contention Count = 30
NumberOfSharedWaiters = 7
NumberOfExclusiveWaiters = 1
Threads: 8150d9e0-01<*> 816873a0-01 81607da0-01 8162bae0-01
8189d3a0-01 816d5860-01 8163dcc0-01 81748da0-01

Threads Waiting On Exclusive Access:
814d4200
KD: Scanning for held locks…

Resource @ 0x815101c8 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 8150d9e0-01<*>

Threads Waiting On Exclusive Access:
8150d9e0
KD: Scanning for held locks.

Resource @ 0x81898fc0 Shared 1 owning threads
Threads: 8189d8a3-01<*> *** Actual Thread 8189D8A0
1645 total locks, 4 locks currently held

kd> !thread 8150d9e0
THREAD 8150d9e0 Cid 2e0.448 Teb: 7ffd8000 Win32Thread: e2f69848 WAIT:
(Executive) KernelMode Non-Alertable
8155f148 SynchronizationEvent
8150dac8 NotificationTimer
IRP List:
bcc36e48: (0006,01b4) Flags: 00000404 Mdl: 00000000
Not impersonating
Owning Process 81642020
Wait Start TickCount 6071 Elapsed Ticks: 133
Context Switch Count 56 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Win32 Start Address 0x65c4b770
Stack Init f148d000 Current f148c3a0 Base f148d000 Limit f1489000 Call 0
Priority 14 BasePriority 8 PriorityDecrement 6 DecrementCount 16

ChildEBP RetAddr Args to Child
f148c3b8 8042de88 00000000 815101c8 8150d9e0 nt!KiSwapThread+0xc5
f148c3e0 8041766c 8155f148 00000000 00000000 nt!KeWaitForSingleObject+0x1a1
f148c420 80416b4d 815101c8 005101c8 f148c438 nt!ExpWaitForResource+0x1ac
f148c430 80416b92 f148c454 80416b3d 815101c8
nt!ExpAcquireResourceExclusiveLite+0x64
f148c438 80416b3d 815101c8 00000001 00000000
nt!ExAcquireResourceExclusiveLite+0x4b
f148c454 80416b92 f148c6bc bff05e49 815101c8
nt!ExpAcquireResourceExclusiveLite+0x55
f148c45c bff05e49 815101c8 00000001 00000000
nt!ExAcquireResourceExclusiveLite+0x4b
f148c6bc bff0ad63 f148c704 bcc36e48 81856800 +0xbff05e49
f148c834 8041fb8b 81856800 bcc36e48 816e9780 +0xbff0ad63
f148c894 8041fb8b 816e9780 bcc36e48 8150c6e8 nt!IopfCallDriver+0x35
f148c8a8 8049d134 80064fac 81896340 00000001 nt!IopfCallDriver+0x35
f148c8dc 804a5d99 81642020 816e9780 00100000 nt!IopCloseFile+0x275
f148c908 8044fbc8 81642020 8150c6d4 8150c6e8
nt!ObpDecrementHandleCount+0x13c
f148c9bc 80465691 00000290 0048ca34 f148ca34 nt!NtClose+0x1f0
f148c9bc 804009d1 00000290 0048ca34 f148ca34 nt!KiSystemService+0xc4
f148ca58 804af3d9 00000001 00000010 e1001610 nt!ZwClose+0xb
f148cba0 8041fb8b 816e9780 bcc00e48 8153d0e8 nt!SepMaximumAccessCheck+0x65
f148cc0c 80432a6d 816b0ca8 8150d9e0 00000001 nt!IopfCallDriver+0x35
f148cc44 80442c8a f148cc70 65aa9009 00000000 nt!KiUnwaitThread+0xcd
f148cc94 804a0a6a e2f6a000 e2f6a004 00000019
nt!MiAddValidPageToWorkingSet+0xa1
f148ccec 804a07b5 00000000 e2f6a000 8153d040 nt!MmFlushVirtualMemory+0x364
f148cd4c 80465691 ffffffff 013afc70 013afc7c nt!NtFlushVirtualMemory+0x104
f148cd4c 77f8a424 ffffffff 013afc70 013afc7c nt!KiSystemService+0xc4
013afc74 00000000 00000000 00000000 00000000 +0x77f8a424

-----Original Message-----
From: Graham, Simon [mailto:xxxxx
mailto:xxxxx@stratus.com]
Sent: Thursday, November 25, 2004 8:10 PM
To: Kernel Debugging Interest List
Subject: RE: [windbg] Deadlock

This one looks bad to me:

Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<>

Threads Waiting On Exclusive Access:
816ee740

Note the same thread has it shared and is now waiting for exclusive;
definitely worth looking at the stack for this one… (note - if it was
trying to convert shared to exclusive it would have worked since it’s the
only thread with shared access - this looks like two code paths that don’t
expect to be called recursively…)

/simgr

-----Original Message-----
From: xxxxx@lists.osr.com [
mailto:xxxxx
mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Thursday, November 25, 2004 6:36 AM
To: Kernel Debugging Interest List
Subject: [windbg] Deadlock

Filter Driver Win2k:

Does this output show a dead lock ???
If so can I get to know what are the name of the locks who are in dead lock
???

Can some one explain me what are the following :

Contention Count
NumberOfSharedWaiters
NumberOfExclusiveWaiters
Threads Waiting On Exclusive Access

------------------------------------------------------------------------
kd> !locks
DUMP OF ALL RESOURCE OBJECTS
KD: Scanning for held locks…

Resource @ nt!CmpRegistryLock (0x8046db80) Shared 1 owning threads
Contention Count = 59
Threads: 8189d3a0-01<
>
KD: Scanning for held locks…

Resource @ 0x81856cd4 Shared 1 owning threads
Contention Count = 95
NumberOfSharedWaiters = 5
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<> 816d2da0-01 8189d3a0-01 8189dda0-01

81641ce0-01 81748da0-01

Threads Waiting On Exclusive Access:
81563020
KD: Scanning for held
locks…


Resource @ 0x81631148 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 816ee740-01<
>

Threads Waiting On Exclusive Access:
816ee740
KD: Scanning for held locks…

Resource @ 0x816596c0 Shared 1 owning threads
Threads: 8189db23-01<*> *** Actual Thread 8189DB20
2592 total locks, 4 locks currently held


You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: xxxxx@divassoftware.com To
unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to windbg as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx></mailto:xxxxx>