Hanging problem

Mark_Roddy · November 20, 2004, 4:20pm

You are the OP

Original Poster. Opie is also of course the name of a chacter from a famous
TV show of the 60’s.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Anurag Sarin
Sent: Saturday, November 20, 2004 2:43 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

BTW what is an OP??

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Sunday, November 21, 2004 12:43 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

Yep, You’r right otherwise he would be making the same mistake !

Hard to judge if it is written by OP or someone else, also he did not
mention in his logic if there is any hierarchy problem. IF THE CODE IS
ENCAPSULATED IN ONE OR TWO ROUTINE SOMETIME IT IS BETTER TO
PUT THAT AS
IS THAN SOME PSEUDO CODE ( I still remember lost in translation Mark )
…

Oh well, I think he is on his way to figure it out !

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Mark Roddy
Sent: Saturday, November 20, 2004 10:58 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

I think the OP indicated that he has two lists, each with their own
locks. Nothing in itself wrong with that, although he should of course
be sure that he doesn’t have a lock hierarchy problem.

If he has a lock recursion problem it will be obvious from the thread
stack trace. What he should not do is just start changing lock
mechanisms in the hope that the problem will get more
obscure. Instead,
the OP should use the ‘open the window wide’ rule. When
looking for the
cause of a software defect, try to make the problem MORE reproducible
not LESS.

It is unlikely that anybody with the skill set required to analyze a
dump is going to volunteer to grovel through the OP’s !process 0 7
output. That is the OP’s job, and he is being paid for it. He’s been
given excellent pointers on how to proceed. Now he should just get on
with it. Once he has a clue as to what the deadlock is, he should
perhaps come back here for advice on how to resolve it.

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Prokash Sinha
> Sent: Saturday, November 20, 2004 1:37 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Hanging problem
>
> No you should use One and only one lock per list usually (specially
> when any of the OPeration is destructive ( ie modify, add,
write some
> such )…
>
> May be you should try just mutex, since fast mutex is not
recursive (
> hence if a thread tries to acquire it again, it is a dead lock if I
> could recall ).
>
> -pro
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Anurag Sarin
> Sent: Saturday, November 20, 2004 10:23 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Hanging problem
>
>
> Wanted to check my Use of Fast Mutex. I see that WRITE Dispatch
> routine has some thing wrong as removing it gives no hanging.
> --------------------------------
> In my CREATE Dispatch Routine
>
> If (Condition A)
> { I do (A-link list) operation under (Lock A)} If (Condition
> B) { I do (B-link list) operation under (Lock B)}
> ---------------------------------------
> In my WRITE Dispatch Routine
> If (Condition C)
> { I do (A-link list) operation under (Lock A)} If (Condition
> D) { I do (B-link list) operation under (Lock B)}
>
> In all I have used one lock each for my 2 Link Lists.
> Both Locks are initialized in driver entry.
>
> Same lock always protects the same Link List in two
different Dispatch

> routines. Like (Lock A) protects (A-link list) in both
CREATE Dispatch

> Routine and WRITE Dispatch Routine.
>
> Now do I use a new lock for the same link list used in
different link
> list?? I.e. do I uses Like (Lock Z) to protect (A-link
list) in WRITE
> Dispatch Routine and let (Lock A) protects (A-link list) in CREATE
> Dispatch Routine ??
>
>
> Any ideas ???
>
> Anurag
>
>
>
>
> -----Original Message-----
> From: Prokash Sinha [mailto:xxxxx@garlic.com]
> Sent: Saturday, November 20, 2004 11:12 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Hanging problem
>
>
> Anurag,
>
> Dont take it personally, but I’ve always thought about selling just
> one of a pair of shoes ( and hold the other one ). Would it
be useful
> ??? Sure why not ? if I can manage to walk on one foot …
>
> When it comes down to debugging ( or for that matter in
every stage of

> life ) look for a simple solution and go for complex one if simple
> does not solve it.
>
> In priority order -
>
> 1) if it is your own code, and you understand the locks,
rough crosss
> checking about how you define and uses those locks should give you
> some idea or to catch .
>
> 2) if it is not your own code then DV (only for xp ) is good idea
>
> 3) if the !locks commamnd catches it is in order to try, you can
> supress or make it verbose, but I bet you have not seen the article
> from osr
>
> 4) then ! process 0 7 or verbose !locks to go thru and checking and
> you can prun using filter (grep) as Max said …
>
> Debugging deadlock(s) can be painful at times, so hold tight for a
> rocky ride !
>
> -pro
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com]On Behalf Of Anurag Sarin
> Sent: Saturday, November 20, 2004 9:13 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Hanging problem
>
>
> Thankyou all for your help. But !process 0 7 is a whole Bible of
> things . Sorry to ask for spoon feeding. But can some one
look at this

> and help me as what does it all mean, which area to
concentrate? . Or
> is there a specific article to read on OSR ?. I see many general
> articles on lock but explaing to track a deadlock and DV
will not help

> as I am on WIN 2K.
>
> I probably will be taking some inputs from this and use some more
> commands to get to the bottom right??
>
> I am using Fast Mutex locks on link lists. I see a hang
only at high
> stress of CREATE and WRITE operations like installation of
MS office.
>
> I am giving a small part of its output.
>
> kd> !process 0 7
> **** NT ACTIVE PROCESS DUMP ****
> .
> .
> .
>
> PROCESS 81564ce0 SessionId: 0 Cid: 0458 Peb: 7ffdf000
ParentCid:
> 0070
> DirBase: 008d4000 ObjectTable: 81564f88 TableSize: 644.
> Image: msiexec.exe
> VadRoot 81564588 Clone 0 Private 182. Modified 0. Locked 0.
> DeviceMap 8189e668
> Token e2b3f2d0
> ElapsedTime 0:06:32.0125
> UserTime 0:00:00.0078
> KernelTime 0:00:00.0546
> QuotaPoolUsage[PagedPool] 27232
> QuotaPoolUsage[NonPagedPool] 3320
> Working Set Sizes (now,min,max) (784, 50, 345) (3136KB, 200KB,
> 1380KB)
> PeakWorkingSetSize 876
> VirtualSize 22 Mb
> PeakVirtualSize 29 Mb
> PageFaultCount 2161
> MemoryPriority BACKGROUND
> BasePriority 8
> CommitCharge 235
>
> THREAD 81564960 Cid 458.3b0 Teb: 7ffde000 Win32Thread:
> e2bdc008 WAIT: (UserRequest) UserMode Non-Alertable
> 8159bcc0 ProcessObject
> 81563e40 NotificationEvent
> 81564260 SynchronizationEvent
> Not impersonating
> Owning Process 81564ce0
> Wait Start TickCount 11712 Elapsed Ticks: 23772
> Context Switch Count 454 LargeStack
> UserTime 0:00:00.0000
> KernelTime 0:00:00.0015
> Start Address 0x7c4e87b3
> Win32 Start Address 0x0100be5e
> Stack Init f13c9000 Current f13c8930 Base f13c9000 Limit
> f13c6000 Call 0
> Priority 8 BasePriority 8 PriorityDecrement 0
DecrementCount 0

> Kernel stack not resident.
>
> ChildEBP RetAddr Args to Child
> f13c8948 8042dba9 00000008 e2bb9868 81564f88
> nt!KiSwapThread+0xc5
> f13c897c 80450b9b 00000003 f13c89f8 00000001
> nt!KeWaitForMultipleObjects+0x266
> f13c8d48 80465691 00000003 0006da88 00000001
> nt!NtWaitForMultipleObjects+0x3a0
> f13c8d48 77f9323e 00000003 0006da88 00000001
> nt!KiSystemService+0xc4
> 0006da60 00000000 00000000 00000000 00000000 +0x77f9323e
>
> THREAD 81519da0 Cid 458.4a0 Teb: 7ffd8000 Win32Thread:
> e2bf5008 WAIT: (WrLpcReceive) UserMode Non-Alertable
> 81711288 Semaphore Limit 0x7fffffff
> Not impersonating
> Owning Process 81564ce0
> Wait Start TickCount 29857 Elapsed Ticks: 5627
> Context Switch Count 39 LargeStack
> UserTime 0:00:00.0000
> KernelTime 0:00:00.0000
> Start Address 0x7c4e9824
> Stack Init f130d000 Current f130cc48 Base f130d000 Limit
> f130a000 Call 0
> Priority 8 BasePriority 8 PriorityDecrement 0
DecrementCount 0

> Kernel stack not resident.
>
> ChildEBP RetAddr Args to Child
> f130cc60 8042de88 f130cd64 e2bdbbc0 00000000
> nt!KiSwapThread+0xc5
> f130cc88 80434d74 81711288 00000010 00000301
> nt!KeWaitForSingleObject+0x1a1
> f130cd48 80465691 000000f0 0193ff54 00000000
> nt!NtReplyWaitReceivePortEx+0x45e
> f130cd48 77f839c7 000000f0 0193ff54 00000000
> nt!KiSystemService+0xc4
> 0193fe24 00000000 00000000 00000000 00000000 +0x77f839c7
>
>
> PROCESS 8149cb20 SessionId: 0 Cid: 04c8 Peb: 7ffdf000
ParentCid:
> 0070
> DirBase: 0fe01000 ObjectTable: 8153a188 TableSize: 656.
> Image: msiexec.exe
> VadRoot 815478e8 Clone 0 Private 196. Modified 0. Locked 0.
> DeviceMap 8189e668
> Token e2c9aa70
> ElapsedTime 0:06:18.0125
> UserTime 0:00:00.0093
> KernelTime 0:00:00.0562
> QuotaPoolUsage[PagedPool] 27704
> QuotaPoolUsage[NonPagedPool] 3632
> Working Set Sizes (now,min,max) (831, 50, 345) (3324KB, 200KB,
> 1380KB)
> PeakWorkingSetSize 963
> VirtualSize 23 Mb
> PeakVirtualSize 29 Mb
> PageFaultCount 2729
> MemoryPriority BACKGROUND
> BasePriority 8
> CommitCharge 251
>
> THREAD 8149c8a0 Cid 4c8.4c4 Teb: 7ffde000 Win32Thread:
> e2c9ada8 WAIT: (UserRequest) UserMode Non-Alertable
> 815a4440 ProcessObject
> 815126c0 NotificationEvent
> 8150e9a0 SynchronizationEvent
> Not impersonating
> Owning Process 8149cb20
> Wait Start TickCount 11806 Elapsed Ticks: 23678
> Context Switch Count 67 LargeStack
> UserTime 0:00:00.0000
> KernelTime 0:00:00.0015
> Start Address 0x7c4e87b3
> Win32 Start Address 0x0100be5e
> Stack Init f1591000 Current f1590930 Base f1591000 Limit
> f158e000 Call 0
> Priority 8 BasePriority 8 PriorityDecrement 0
DecrementCount 0

> Kernel stack not resident.
>
> ChildEBP RetAddr Args to Child
> f1590948 8042dba9 00000008 e2c99868 8153a188
> nt!KiSwapThread+0xc5
> f159097c 80450b9b 00000003 f15909f8 00000001
> nt!KeWaitForMultipleObjects+0x266
> f1590d48 80465691 00000003 0006da88 00000001
> nt!NtWaitForMultipleObjects+0x3a0
> f1590d48 77f9323e 00000003 0006da88 00000001
> nt!KiSystemService+0xc4
> 0006da60 00000000 00000000 00000000 00000000 +0x77f9323e
>
> THREAD 814b9a40 Cid 4c8.4cc Teb: 7ffdd000 Win32Thread:
> e2c9e008 WAIT: (WrLpcReceive) UserMode Non-Alertable
> 8154db88 Semaphore Limit 0x7fffffff
> Not impersonating
> Owning Process 8149cb20
> Wait Start TickCount 30869 Elapsed Ticks: 4615
> Context Switch Count 97 LargeStack
> UserTime 0:00:00.0000
> KernelTime 0:00:00.0000
> Start Address 0x7c4e9824
> Stack Init f14d1000 Current f14d0c48 Base f14d1000 Limit
> f14ce000 Call 0
> Priority 9 BasePriority 8 PriorityDecrement 0
DecrementCount 0

> Kernel stack not resident.
>
> ChildEBP RetAddr Args to Child
> f14d0c60 8042de88 f14d0d64 e2c83420 00000000
> nt!KiSwapThread+0xc5
> f14d0c88 80434d74 8154db88 00000010 f14d0d01
> nt!KeWaitForSingleObject+0x1a1
> f14d0d48 80465691 000000f0 00d9ff54 00000000
> nt!NtReplyWaitReceivePortEx+0x45e
> f14d0d48 77f839c7 000000f0 00d9ff54 00000000
> nt!KiSystemService+0xc4
> 00d9fe24 00000000 00000000 00000000 00000000 +0x77f839c7
>
>
> PROCESS 81334b20 SessionId: 0 Cid: 0554 Peb: 7ffdf000
ParentCid:
> 0070
> DirBase: 09f71000 ObjectTable: 814da6e8 TableSize: 79.
> Image: msiexec.exe
> VadRoot 813342a8 Clone 0 Private 144. Modified 0. Locked 0.
> DeviceMap 8189e668
> Token e2cc7bb0
> ElapsedTime 0:06:12.0031
> UserTime 0:00:00.0015
> KernelTime 0:00:00.0000
> QuotaPoolUsage[PagedPool] 19676
> QuotaPoolUsage[NonPagedPool] 2956
> Working Set Sizes (now,min,max) (579, 50, 345) (2316KB, 200KB,
> 1380KB)
> PeakWorkingSetSize 619
> VirtualSize 19 Mb
> PeakVirtualSize 24 Mb
> PageFaultCount 625
> MemoryPriority BACKGROUND
> BasePriority 8
> CommitCharge 184
>
> THREAD 813348a0 Cid 554.1b4 Teb: 7ffde000 Win32Thread:
> e2cc6448 WAIT: (UserRequest) UserMode Non-Alertable
> 815a4440 ProcessObject
> 81416c00 NotificationEvent
> 814734c0 SynchronizationEvent
> Not impersonating
> Owning Process 81334b20
> Wait Start TickCount 11806 Elapsed Ticks: 23678
> Context Switch Count 65 LargeStack
> UserTime 0:00:00.0000
> KernelTime 0:00:00.0000
> Start Address 0x7c4e87b3
> Win32 Start Address 0x0100be5e
> Stack Init f12fd000 Current f12fc930 Base f12fd000 Limit
> f12f9000 Call 0
> Priority 8 BasePriority 8 PriorityDecrement 0
DecrementCount 0

> Kernel stack not resident.
>
> ChildEBP RetAddr Args to Child
> f12fc948 8042dba9 00000008 e2cc8868 814da6e8
> nt!KiSwapThread+0xc5
> f12fc97c 80450b9b 00000003 f12fc9f8 00000001
> nt!KeWaitForMultipleObjects+0x266
> f12fcd48 80465691 00000003 0006da88 00000001
> nt!NtWaitForMultipleObjects+0x3a0
> f12fcd48 77f9323e 00000003 0006da88 00000001
> nt!KiSystemService+0xc4
> 0006da60 00000000 00000000 00000000 00000000 +0x77f9323e
>
> THREAD 81307920 Cid 554.558 Teb: 7ffdd000 Win32Thread:
> 00000000 WAIT: (WrLpcReceive) UserMode Non-Alertable
> 81509b08 Semaphore Limit 0x7fffffff
> Not impersonating
> Owning Process 81334b20
> Wait Start TickCount 30875 Elapsed Ticks: 4609
> Context Switch Count 8
> UserTime 0:00:00.0000
> KernelTime 0:00:00.0000
> Start Address 0x7c4e9824
> Stack Init f14e1000 Current f14e0c48 Base f14e1000 Limit
> f14de000 Call 0
> Priority 8 BasePriority 8 PriorityDecrement 0
DecrementCount 0

> Kernel stack not resident.
>
> ChildEBP RetAddr Args to Child
> f14e0c60 8042de88 f14e0d64 e2be9560 00000000
> nt!KiSwapThread+0xc5
> f14e0c88 80434d74 81509b08 00000010 8044af01
> nt!KeWaitForSingleObject+0x1a1
> f14e0d48 80465691 000000f4 00d9ff54 00000000
> nt!NtReplyWaitReceivePortEx+0x45e
> f14e0d48 77f839c7 000000f4 00d9ff54 00000000
> nt!KiSystemService+0xc4
> 00d9fe24 00000000 00000000 00000000 00000000 +0x77f839c7
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument:
> ‘’ To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
xxxxx@divassoftware.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: unknown lmsubst tag
> argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hollistech.com To
> unsubscribe send a blank email to xxxxx@lists.osr.com
>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Lyndon_J_Clarke-2 · November 20, 2004, 4:28pm

I wonder if I am right. You have just three processes running all with
miamge name msiexec.exe? You do not even have System process?

“Anurag Sarin” wrote in message
news:xxxxx@ntdev…
Thankyou all for your help. But !process 0 7 is a whole Bible of things
. Sorry to ask for spoon feeding.
But can some one look at this and help me as what does it all mean,
which area to concentrate? . Or is there a specific article to read on
OSR ?. I see many general articles on lock but explaing to track a
deadlock and DV will not help as I am on WIN 2K.

I probably will be taking some inputs from this and use some more
commands to get to the bottom right??

I am using Fast Mutex locks on link lists. I see a hang only at high
stress of CREATE and WRITE operations like installation of MS office.

I am giving a small part of its output.

kd> !process 0 7
NT ACTIVE PROCESS DUMP
.
.
.

PROCESS 81564ce0 SessionId: 0 Cid: 0458 Peb: 7ffdf000 ParentCid:
0070
DirBase: 008d4000 ObjectTable: 81564f88 TableSize: 644.
Image: msiexec.exe
VadRoot 81564588 Clone 0 Private 182. Modified 0. Locked 0.
DeviceMap 8189e668
Token e2b3f2d0
ElapsedTime 0:06:32.0125
UserTime 0:00:00.0078
KernelTime 0:00:00.0546
QuotaPoolUsage[PagedPool] 27232
QuotaPoolUsage[NonPagedPool] 3320
Working Set Sizes (now,min,max) (784, 50, 345) (3136KB, 200KB,
1380KB)
PeakWorkingSetSize 876
VirtualSize 22 Mb
PeakVirtualSize 29 Mb
PageFaultCount 2161
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 235

THREAD 81564960 Cid 458.3b0 Teb: 7ffde000 Win32Thread:
e2bdc008 WAIT: (UserRequest) UserMode Non-Alertable
8159bcc0 ProcessObject
81563e40 NotificationEvent
81564260 SynchronizationEvent
Not impersonating
Owning Process 81564ce0
Wait Start TickCount 11712 Elapsed Ticks: 23772
Context Switch Count 454 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0015
Start Address 0x7c4e87b3
Win32 Start Address 0x0100be5e
Stack Init f13c9000 Current f13c8930 Base f13c9000 Limit
f13c6000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f13c8948 8042dba9 00000008 e2bb9868 81564f88
nt!KiSwapThread+0xc5
f13c897c 80450b9b 00000003 f13c89f8 00000001
nt!KeWaitForMultipleObjects+0x266
f13c8d48 80465691 00000003 0006da88 00000001
nt!NtWaitForMultipleObjects+0x3a0
f13c8d48 77f9323e 00000003 0006da88 00000001
nt!KiSystemService+0xc4
0006da60 00000000 00000000 00000000 00000000 +0x77f9323e

THREAD 81519da0 Cid 458.4a0 Teb: 7ffd8000 Win32Thread:
e2bf5008 WAIT: (WrLpcReceive) UserMode Non-Alertable
81711288 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 81564ce0
Wait Start TickCount 29857 Elapsed Ticks: 5627
Context Switch Count 39 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Stack Init f130d000 Current f130cc48 Base f130d000 Limit
f130a000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f130cc60 8042de88 f130cd64 e2bdbbc0 00000000
nt!KiSwapThread+0xc5
f130cc88 80434d74 81711288 00000010 00000301
nt!KeWaitForSingleObject+0x1a1
f130cd48 80465691 000000f0 0193ff54 00000000
nt!NtReplyWaitReceivePortEx+0x45e
f130cd48 77f839c7 000000f0 0193ff54 00000000
nt!KiSystemService+0xc4
0193fe24 00000000 00000000 00000000 00000000 +0x77f839c7

PROCESS 8149cb20 SessionId: 0 Cid: 04c8 Peb: 7ffdf000 ParentCid:
0070
DirBase: 0fe01000 ObjectTable: 8153a188 TableSize: 656.
Image: msiexec.exe
VadRoot 815478e8 Clone 0 Private 196. Modified 0. Locked 0.
DeviceMap 8189e668
Token e2c9aa70
ElapsedTime 0:06:18.0125
UserTime 0:00:00.0093
KernelTime 0:00:00.0562
QuotaPoolUsage[PagedPool] 27704
QuotaPoolUsage[NonPagedPool] 3632
Working Set Sizes (now,min,max) (831, 50, 345) (3324KB, 200KB,
1380KB)
PeakWorkingSetSize 963
VirtualSize 23 Mb
PeakVirtualSize 29 Mb
PageFaultCount 2729
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 251

THREAD 8149c8a0 Cid 4c8.4c4 Teb: 7ffde000 Win32Thread:
e2c9ada8 WAIT: (UserRequest) UserMode Non-Alertable
815a4440 ProcessObject
815126c0 NotificationEvent
8150e9a0 SynchronizationEvent
Not impersonating
Owning Process 8149cb20
Wait Start TickCount 11806 Elapsed Ticks: 23678
Context Switch Count 67 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0015
Start Address 0x7c4e87b3
Win32 Start Address 0x0100be5e
Stack Init f1591000 Current f1590930 Base f1591000 Limit
f158e000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f1590948 8042dba9 00000008 e2c99868 8153a188
nt!KiSwapThread+0xc5
f159097c 80450b9b 00000003 f15909f8 00000001
nt!KeWaitForMultipleObjects+0x266
f1590d48 80465691 00000003 0006da88 00000001
nt!NtWaitForMultipleObjects+0x3a0
f1590d48 77f9323e 00000003 0006da88 00000001
nt!KiSystemService+0xc4
0006da60 00000000 00000000 00000000 00000000 +0x77f9323e

THREAD 814b9a40 Cid 4c8.4cc Teb: 7ffdd000 Win32Thread:
e2c9e008 WAIT: (WrLpcReceive) UserMode Non-Alertable
8154db88 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 8149cb20
Wait Start TickCount 30869 Elapsed Ticks: 4615
Context Switch Count 97 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Stack Init f14d1000 Current f14d0c48 Base f14d1000 Limit
f14ce000 Call 0
Priority 9 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f14d0c60 8042de88 f14d0d64 e2c83420 00000000
nt!KiSwapThread+0xc5
f14d0c88 80434d74 8154db88 00000010 f14d0d01
nt!KeWaitForSingleObject+0x1a1
f14d0d48 80465691 000000f0 00d9ff54 00000000
nt!NtReplyWaitReceivePortEx+0x45e
f14d0d48 77f839c7 000000f0 00d9ff54 00000000
nt!KiSystemService+0xc4
00d9fe24 00000000 00000000 00000000 00000000 +0x77f839c7

PROCESS 81334b20 SessionId: 0 Cid: 0554 Peb: 7ffdf000 ParentCid:
0070
DirBase: 09f71000 ObjectTable: 814da6e8 TableSize: 79.
Image: msiexec.exe
VadRoot 813342a8 Clone 0 Private 144. Modified 0. Locked 0.
DeviceMap 8189e668
Token e2cc7bb0
ElapsedTime 0:06:12.0031
UserTime 0:00:00.0015
KernelTime 0:00:00.0000
QuotaPoolUsage[PagedPool] 19676
QuotaPoolUsage[NonPagedPool] 2956
Working Set Sizes (now,min,max) (579, 50, 345) (2316KB, 200KB,
1380KB)
PeakWorkingSetSize 619
VirtualSize 19 Mb
PeakVirtualSize 24 Mb
PageFaultCount 625
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 184

THREAD 813348a0 Cid 554.1b4 Teb: 7ffde000 Win32Thread:
e2cc6448 WAIT: (UserRequest) UserMode Non-Alertable
815a4440 ProcessObject
81416c00 NotificationEvent
814734c0 SynchronizationEvent
Not impersonating
Owning Process 81334b20
Wait Start TickCount 11806 Elapsed Ticks: 23678
Context Switch Count 65 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e87b3
Win32 Start Address 0x0100be5e
Stack Init f12fd000 Current f12fc930 Base f12fd000 Limit
f12f9000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f12fc948 8042dba9 00000008 e2cc8868 814da6e8
nt!KiSwapThread+0xc5
f12fc97c 80450b9b 00000003 f12fc9f8 00000001
nt!KeWaitForMultipleObjects+0x266
f12fcd48 80465691 00000003 0006da88 00000001
nt!NtWaitForMultipleObjects+0x3a0
f12fcd48 77f9323e 00000003 0006da88 00000001
nt!KiSystemService+0xc4
0006da60 00000000 00000000 00000000 00000000 +0x77f9323e

THREAD 81307920 Cid 554.558 Teb: 7ffdd000 Win32Thread:
00000000 WAIT: (WrLpcReceive) UserMode Non-Alertable
81509b08 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 81334b20
Wait Start TickCount 30875 Elapsed Ticks: 4609
Context Switch Count 8
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Stack Init f14e1000 Current f14e0c48 Base f14e1000 Limit
f14de000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f14e0c60 8042de88 f14e0d64 e2be9560 00000000
nt!KiSwapThread+0xc5
f14e0c88 80434d74 81509b08 00000010 8044af01
nt!KeWaitForSingleObject+0x1a1
f14e0d48 80465691 000000f4 00d9ff54 00000000
nt!NtReplyWaitReceivePortEx+0x45e
f14e0d48 77f839c7 000000f4 00d9ff54 00000000
nt!KiSystemService+0xc4
00d9fe24 00000000 00000000 00000000 00000000 +0x77f839c7

Lyndon_J_Clarke-2 · November 20, 2004, 4:29pm

Maxim, have we never seen also seen deadlock with dispatcher objects, such
as Mutant and Semaphore and Event …

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
> >Thankyou all for your help. But !process 0 7 is a whole Bible of things
>
> Correct. Then find the strings which contain “FastMutex” or “Resource” in
> it,
> these will be the stacks of offending threads.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>

OSR_Community_User · November 21, 2004, 10:00am

>> 2) if it is not your own code then DV (only for xp ) is good idea

I am on W2k hence DV would not help.

Driver Verifier is available under Windows 2000.

Start / Run / verifier.exe

Select your driver and turn on everything but low resources simulation (you
should do that later, after this problem has been solved, to make sure your
driver handles low resource conditions properly). That might help you find
where things are going wrong.

http://support.microsoft.com/kb/244617/EN-US/

-Dan

Mark_Roddy · November 21, 2004, 1:17pm

Filesystems use resource locks almost exclusively.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke
Sent: Saturday, November 20, 2004 4:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Hanging problem

Maxim, have we never seen also seen deadlock with dispatcher
objects, such as Mutant and Semaphore and Event …

“Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> > >Thankyou all for your help. But !process 0 7 is a whole Bible of
> > >things
> >
> > Correct. Then find the strings which contain “FastMutex” or
> “Resource”
> > in it, these will be the stacks of offending threads.
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>

OSR_Community_User · November 22, 2004, 7:45am

I do have system proceses but did’nt show them. Like

PROCESS 8189eae0 SessionId: 0 Cid: 0008 Peb: 00000000 ParentCid:
0000
DirBase: 00030000 ObjectTable: 818c35a8 TableSize: 149.
Image: System
VadRoot 8189b6e8 Clone 0 Private 4. Modified 3458. Locked 0.
DeviceMap 8189e668
Token e10017d0
ElapsedTime 16:34:31.0828
UserTime 0:00:00.0000
KernelTime 0:00:06.0078
QuotaPoolUsage[PagedPool] 0
QuotaPoolUsage[NonPagedPool] 0
Working Set Sizes (now,min,max) (53, 0, 345) (212KB, 0KB, 1380KB)
PeakWorkingSetSize 162
VirtualSize 1 Mb
PeakVirtualSize 1 Mb
PageFaultCount 2170
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 6

THREAD 8189e860 Cid 8.4 Teb: 00000000 Win32Thread: 00000000
WAIT: (WrFreePage) KernelMode Non-Alertable
80483250 SynchronizationEvent
80483ba0 NotificationTimer
Not impersonating
Owning Process 8189eae0
Wait Start TickCount 35424 Elapsed Ticks: 60
Context Switch Count 9042
UserTime 0:00:00.0000
KernelTime 0:00:02.0343
Start Address nt!Phase1Initialization (0x8054f660)
Stack Init eb41c000 Current eb41b9c4 Base eb41c000 Limit
eb419000 Call 0
Priority 0 BasePriority 0 PriorityDecrement 0 DecrementCount 0

ChildEBP RetAddr Args to Child
eb41b9dc 8042dba9 0000295d 80064bd4 00000000
nt!KiSwapThread+0xc5
eb41ba10 80449e9e 00000002 eb41ba44 00000001
nt!KeWaitForMultipleObjects+0x266
eb41ba5c 805502e9 00000000 00000000 00000000
nt!MmZeroPageThread+0x5f
eb41bda8 80455a16 80087000 00000000 00000000
nt!Phase1Initialization+0xc32
eb41bddc 80469bb2 8054f660 80087000 00000000
nt!PspSystemThreadStartup+0x69
00000000 00000000 00000000 00000000 00000000
nt!KiThreadStartup+0x16

THREAD 8189d020 Cid 8.c Teb: 00000000 Win32Thread: 00000000
WAIT: (WrEventPairLow) UserMode Non-Alertable
8046dc20 Unknown
Not impersonating
Owning Process 8189eae0
Wait Start TickCount 7 Elapsed Ticks: 35477
Context Switch Count 1
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address nt!ExpWorkerThread (0x804190f0)
Stack Init eb424000 Current eb423d34 Base eb424000 Limit
eb421000 Call 0
Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

THREAD 8189dda0 Cid 8.10 Teb: 00000000 Win32Thread: 00000000
WAIT: (WrEventPairLow) UserMode Non-Alertable
8046dc20 Unknown
Not impersonating
Owning Process 8189eae0
Wait Start TickCount 595 Elapsed Ticks: 34889
Context Switch Count 2
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address nt!ExpWorkerThread (0x804190f0)
Stack Init eb428000 Current eb427d34 Base eb428000 Limit
eb425000 Call 0
Priority 13 BasePriority 13 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

-----Original Message-----
From: Lyndon J Clarke [mailto:xxxxx@neverfailgroup.com]
Sent: Sunday, November 21, 2004 2:55 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Hanging problem

I wonder if I am right. You have just three processes running all with
miamge name msiexec.exe? You do not even have System process?

“Anurag Sarin” wrote in message
news:xxxxx@ntdev…
Thankyou all for your help. But !process 0 7 is a whole Bible of things
. Sorry to ask for spoon feeding. But can some one look at this and help
me as what does it all mean, which area to concentrate? . Or is there a
specific article to read on OSR ?. I see many general articles on lock
but explaing to track a deadlock and DV will not help as I am on WIN 2K.

I probably will be taking some inputs from this and use some more
commands to get to the bottom right??

I am using Fast Mutex locks on link lists. I see a hang only at high
stress of CREATE and WRITE operations like installation of MS office.

I am giving a small part of its output.

kd> !process 0 7
NT ACTIVE PROCESS DUMP
.
.
.

PROCESS 81564ce0 SessionId: 0 Cid: 0458 Peb: 7ffdf000 ParentCid:
0070
DirBase: 008d4000 ObjectTable: 81564f88 TableSize: 644.
Image: msiexec.exe
VadRoot 81564588 Clone 0 Private 182. Modified 0. Locked 0.
DeviceMap 8189e668
Token e2b3f2d0
ElapsedTime 0:06:32.0125
UserTime 0:00:00.0078
KernelTime 0:00:00.0546
QuotaPoolUsage[PagedPool] 27232
QuotaPoolUsage[NonPagedPool] 3320
Working Set Sizes (now,min,max) (784, 50, 345) (3136KB, 200KB,
1380KB)
PeakWorkingSetSize 876
VirtualSize 22 Mb
PeakVirtualSize 29 Mb
PageFaultCount 2161
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 235

THREAD 81564960 Cid 458.3b0 Teb: 7ffde000 Win32Thread:
e2bdc008 WAIT: (UserRequest) UserMode Non-Alertable
8159bcc0 ProcessObject
81563e40 NotificationEvent
81564260 SynchronizationEvent
Not impersonating
Owning Process 81564ce0
Wait Start TickCount 11712 Elapsed Ticks: 23772
Context Switch Count 454 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0015
Start Address 0x7c4e87b3
Win32 Start Address 0x0100be5e
Stack Init f13c9000 Current f13c8930 Base f13c9000 Limit
f13c6000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f13c8948 8042dba9 00000008 e2bb9868 81564f88
nt!KiSwapThread+0xc5
f13c897c 80450b9b 00000003 f13c89f8 00000001
nt!KeWaitForMultipleObjects+0x266
f13c8d48 80465691 00000003 0006da88 00000001
nt!NtWaitForMultipleObjects+0x3a0
f13c8d48 77f9323e 00000003 0006da88 00000001
nt!KiSystemService+0xc4
0006da60 00000000 00000000 00000000 00000000 +0x77f9323e

THREAD 81519da0 Cid 458.4a0 Teb: 7ffd8000 Win32Thread:
e2bf5008 WAIT: (WrLpcReceive) UserMode Non-Alertable
81711288 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 81564ce0
Wait Start TickCount 29857 Elapsed Ticks: 5627
Context Switch Count 39 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Stack Init f130d000 Current f130cc48 Base f130d000 Limit
f130a000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f130cc60 8042de88 f130cd64 e2bdbbc0 00000000
nt!KiSwapThread+0xc5
f130cc88 80434d74 81711288 00000010 00000301
nt!KeWaitForSingleObject+0x1a1
f130cd48 80465691 000000f0 0193ff54 00000000
nt!NtReplyWaitReceivePortEx+0x45e
f130cd48 77f839c7 000000f0 0193ff54 00000000
nt!KiSystemService+0xc4
0193fe24 00000000 00000000 00000000 00000000 +0x77f839c7

PROCESS 8149cb20 SessionId: 0 Cid: 04c8 Peb: 7ffdf000 ParentCid:
0070
DirBase: 0fe01000 ObjectTable: 8153a188 TableSize: 656.
Image: msiexec.exe
VadRoot 815478e8 Clone 0 Private 196. Modified 0. Locked 0.
DeviceMap 8189e668
Token e2c9aa70
ElapsedTime 0:06:18.0125
UserTime 0:00:00.0093
KernelTime 0:00:00.0562
QuotaPoolUsage[PagedPool] 27704
QuotaPoolUsage[NonPagedPool] 3632
Working Set Sizes (now,min,max) (831, 50, 345) (3324KB, 200KB,
1380KB)
PeakWorkingSetSize 963
VirtualSize 23 Mb
PeakVirtualSize 29 Mb
PageFaultCount 2729
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 251

THREAD 8149c8a0 Cid 4c8.4c4 Teb: 7ffde000 Win32Thread:
e2c9ada8 WAIT: (UserRequest) UserMode Non-Alertable
815a4440 ProcessObject
815126c0 NotificationEvent
8150e9a0 SynchronizationEvent
Not impersonating
Owning Process 8149cb20
Wait Start TickCount 11806 Elapsed Ticks: 23678
Context Switch Count 67 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0015
Start Address 0x7c4e87b3
Win32 Start Address 0x0100be5e
Stack Init f1591000 Current f1590930 Base f1591000 Limit
f158e000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f1590948 8042dba9 00000008 e2c99868 8153a188
nt!KiSwapThread+0xc5
f159097c 80450b9b 00000003 f15909f8 00000001
nt!KeWaitForMultipleObjects+0x266
f1590d48 80465691 00000003 0006da88 00000001
nt!NtWaitForMultipleObjects+0x3a0
f1590d48 77f9323e 00000003 0006da88 00000001
nt!KiSystemService+0xc4
0006da60 00000000 00000000 00000000 00000000 +0x77f9323e

THREAD 814b9a40 Cid 4c8.4cc Teb: 7ffdd000 Win32Thread:
e2c9e008 WAIT: (WrLpcReceive) UserMode Non-Alertable
8154db88 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 8149cb20
Wait Start TickCount 30869 Elapsed Ticks: 4615
Context Switch Count 97 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Stack Init f14d1000 Current f14d0c48 Base f14d1000 Limit
f14ce000 Call 0
Priority 9 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f14d0c60 8042de88 f14d0d64 e2c83420 00000000
nt!KiSwapThread+0xc5
f14d0c88 80434d74 8154db88 00000010 f14d0d01
nt!KeWaitForSingleObject+0x1a1
f14d0d48 80465691 000000f0 00d9ff54 00000000
nt!NtReplyWaitReceivePortEx+0x45e
f14d0d48 77f839c7 000000f0 00d9ff54 00000000
nt!KiSystemService+0xc4
00d9fe24 00000000 00000000 00000000 00000000 +0x77f839c7

PROCESS 81334b20 SessionId: 0 Cid: 0554 Peb: 7ffdf000 ParentCid:
0070
DirBase: 09f71000 ObjectTable: 814da6e8 TableSize: 79.
Image: msiexec.exe
VadRoot 813342a8 Clone 0 Private 144. Modified 0. Locked 0.
DeviceMap 8189e668
Token e2cc7bb0
ElapsedTime 0:06:12.0031
UserTime 0:00:00.0015
KernelTime 0:00:00.0000
QuotaPoolUsage[PagedPool] 19676
QuotaPoolUsage[NonPagedPool] 2956
Working Set Sizes (now,min,max) (579, 50, 345) (2316KB, 200KB,
1380KB)
PeakWorkingSetSize 619
VirtualSize 19 Mb
PeakVirtualSize 24 Mb
PageFaultCount 625
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 184

THREAD 813348a0 Cid 554.1b4 Teb: 7ffde000 Win32Thread:
e2cc6448 WAIT: (UserRequest) UserMode Non-Alertable
815a4440 ProcessObject
81416c00 NotificationEvent
814734c0 SynchronizationEvent
Not impersonating
Owning Process 81334b20
Wait Start TickCount 11806 Elapsed Ticks: 23678
Context Switch Count 65 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e87b3
Win32 Start Address 0x0100be5e
Stack Init f12fd000 Current f12fc930 Base f12fd000 Limit
f12f9000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f12fc948 8042dba9 00000008 e2cc8868 814da6e8
nt!KiSwapThread+0xc5
f12fc97c 80450b9b 00000003 f12fc9f8 00000001
nt!KeWaitForMultipleObjects+0x266
f12fcd48 80465691 00000003 0006da88 00000001
nt!NtWaitForMultipleObjects+0x3a0
f12fcd48 77f9323e 00000003 0006da88 00000001
nt!KiSystemService+0xc4
0006da60 00000000 00000000 00000000 00000000 +0x77f9323e

THREAD 81307920 Cid 554.558 Teb: 7ffdd000 Win32Thread:
00000000 WAIT: (WrLpcReceive) UserMode Non-Alertable
81509b08 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 81334b20
Wait Start TickCount 30875 Elapsed Ticks: 4609
Context Switch Count 8
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Stack Init f14e1000 Current f14e0c48 Base f14e1000 Limit
f14de000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f14e0c60 8042de88 f14e0d64 e2be9560 00000000
nt!KiSwapThread+0xc5
f14e0c88 80434d74 81509b08 00000010 8044af01
nt!KeWaitForSingleObject+0x1a1
f14e0d48 80465691 000000f4 00d9ff54 00000000
nt!NtReplyWaitReceivePortEx+0x45e
f14e0d48 77f839c7 000000f4 00d9ff54 00000000
nt!KiSystemService+0xc4
00d9fe24 00000000 00000000 00000000 00000000 +0x77f839c7

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · November 22, 2004, 7:46am

I know But The deadlock detection tick does not exists in the WIN2K
version.
I wonder if there is any other tool for deadlock detection in WIN2K.

anurag

-----Original Message-----
From: Daniel E. Germann [mailto:xxxxx@visi.com]
Sent: Sunday, November 21, 2004 8:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Hanging problem

> 2) if it is not your own code then DV (only for xp ) is good idea
I am on W2k hence DV would not help.

Driver Verifier is available under Windows 2000.

Start / Run / verifier.exe

Select your driver and turn on everything but low resources simulation
(you should do that later, after this problem has been solved, to make
sure your driver handles low resource conditions properly). That might
help you find where things are going wrong.

http://support.microsoft.com/kb/244617/EN-US/

-Dan

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · November 22, 2004, 8:18am

I didn't know abt lock hierarchy and found that It was missing in my
code. I want to know how can I implement it. As I doubt if I can have an
definate order for aquirring and releasing Fast Muitex locks. I aquire a
lock based on a condition - This may or may not occur.

To keep a definative sequence, do I acquire lock even if I do not need
so??

I have explained my code of 3 routines in Pseudo below , Will be
grateful if some body guides in terms of lock hierarchy.

I have three Dispatch Routines. In Total I have 3 Link Lists , each
protected by a different lock.
LL1 protected by Lock A
LL2 protected by Lock B
LL3 protected by Lock C

WRITE Dispatch Routine
{
If Condition
Aquire Lock A
Do Work in LL1
Release Lock A

Aquire Lock B
Do Work in LL2
Release Lock B

some code

Aquire Lock B
Do Work in LL2
Release Lock B
Else

Aquire Lock A
Do Work in LL1
Release Lock A

Aquire Lock A
Do Work in LL1
Release Lock A
}

CREATE Dispatch Routine
{
If Condition

Aquire Lock B
Do Work in LL2
Release Lock B
Else

Aquire Lock A
Do Work in LL1
Release Lock A

}

SET_INFORMATION Dispatch Routine
{
If Condition 1

Aquire Lock B
Do Work in LL2
Release Lock B

Else Condition 2

Aquire Lock A
Do Work in LL1
Release Lock A

Aquire Lock C
Do Work in LL3
Release Lock C

Else Condition 3

Aquire Lock C
Do Work in LL3
Release Lock C

Aquire Lock A
Do Work in LL1
Release Lock A

Else Condition 4

Aquire Lock C
Do Work in LL3
Release Lock C

Aquire Lock A
Do Work in LL1
Release Lock A
}

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Sunday, November 21, 2004 12:55 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

Since you found that taking out the locks letting you avoid the
deadlock, it is quite fair to assume that you have a locking problem,
hope everyone would agree some what on it --

Now take the very basic case, (a) everywhere you try to access the list
you would be PASSIVE LEVEL (b) Assume that you never going to think
about artificial partitioning on a list, that means you would be
allowing only one thread to access the list at any given point in time.
IF THE ABOVE ASSUMPTIONS ARE TRUE your one lock per list is fine.

Now you are using two locks for two lists, so you should be careful
about lock hierarchy ( that is every places you try to acquire two
locks, you acquire in the same order, make sure you releases too. BTW,
there are osr articles on this that are online and you can look at it.

Anytime you manage to get out of the deadlock, make sure you sit back
and clean it out properly, in otherwords justify why you ( or whoever )
using those locks, why they should be deadlock free etc.,etc

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Anurag Sarin
Sent: Saturday, November 20, 2004 11:09 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

>No you should use One and only one lock per list usually

One lock per list in all dispatch routines (same in CREATE and WRITE).??
In short- I am write in my flow for Fast Mutex, right????

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Sunday, November 21, 2004 12:07 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

No you should use One and only one lock per list usually (specially when
any of the OPeration is destructive ( ie modify, add, write some such
)...

May be you should try just mutex, since fast mutex is not recursive (
hence if a thread tries to acquire it again, it is a dead lock if I
could recall ).

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Anurag Sarin
Sent: Saturday, November 20, 2004 10:23 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

Wanted to check my Use of Fast Mutex. I see that WRITE Dispatch routine
has some thing wrong as removing it gives no hanging.

In my CREATE Dispatch Routine

If (Condition A)
{ I do (A-link list) operation under (Lock A)}
If (Condition B)
{ I do (B-link list) operation under (Lock B)}

In my WRITE Dispatch Routine
If (Condition C)
{ I do (A-link list) operation under (Lock A)}
If (Condition D)
{ I do (B-link list) operation under (Lock B)}

In all I have used one lock each for my 2 Link Lists.
Both Locks are initialized in driver entry.

Same lock always protects the same Link List in two different Dispatch
routines. Like (Lock A) protects (A-link list) in both CREATE Dispatch
Routine and WRITE Dispatch Routine.

Now do I use a new lock for the same link list used in different link
list?? I.e. do I uses Like (Lock Z) to protect (A-link list) in WRITE
Dispatch Routine and let (Lock A) protects (A-link list) in CREATE
Dispatch Routine ??

Any ideas ????

Anurag

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Saturday, November 20, 2004 11:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

Anurag,

Dont take it personally, but I've always thought about selling just one
of a pair of shoes ( and hold the other one ). Would it be useful ???
Sure why not ? if I can manage to walk on one foot ...

When it comes down to debugging ( or for that matter in every stage of
life ) look for a simple solution and go for complex one if simple does
not solve it.

In priority order -

if it is your own code, and you understand the locks, rough crosss
checking about how you define and uses those locks should give you some
idea or to catch .
if it is not your own code then DV (only for xp ) is good idea
if the !locks commamnd catches it is in order to try, you can supress
or make it verbose, but I bet you have not seen the article from osr
then ! process 0 7 or verbose !locks to go thru and checking and you
can prun using filter (grep) as Max said ...

Debugging deadlock(s) can be painful at times, so hold tight for a rocky
ride !

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Anurag Sarin
Sent: Saturday, November 20, 2004 9:13 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

Thankyou all for your help. But !process 0 7 is a whole Bible of things
. Sorry to ask for spoon feeding. But can some one look at this and help
me as what does it all mean, which area to concentrate? . Or is there a
specific article to read on OSR ?. I see many general articles on lock
but explaing to track a deadlock and DV will not help as I am on WIN 2K.

I probably will be taking some inputs from this and use some more
commands to get to the bottom right??

I am using Fast Mutex locks on link lists. I see a hang only at high
stress of CREATE and WRITE operations like installation of MS office.

I am giving a small part of its output.

kd> !process 0 7
**** NT ACTIVE PROCESS DUMP ****
.
.
.

PROCESS 81564ce0 SessionId: 0 Cid: 0458 Peb: 7ffdf000 ParentCid:
0070
DirBase: 008d4000 ObjectTable: 81564f88 TableSize: 644.
Image: msiexec.exe
VadRoot 81564588 Clone 0 Private 182. Modified 0. Locked 0.
DeviceMap 8189e668
Token e2b3f2d0
ElapsedTime 0:06:32.0125
UserTime 0:00:00.0078
KernelTime 0:00:00.0546
QuotaPoolUsage[PagedPool] 27232
QuotaPoolUsage[NonPagedPool] 3320
Working Set Sizes (now,min,max) (784, 50, 345) (3136KB, 200KB,
1380KB)
PeakWorkingSetSize 876
VirtualSize 22 Mb
PeakVirtualSize 29 Mb
PageFaultCount 2161
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 235

THREAD 81564960 Cid 458.3b0 Teb: 7ffde000 Win32Thread:
e2bdc008 WAIT: (UserRequest) UserMode Non-Alertable
8159bcc0 ProcessObject
81563e40 NotificationEvent
81564260 SynchronizationEvent
Not impersonating
Owning Process 81564ce0
Wait Start TickCount 11712 Elapsed Ticks: 23772
Context Switch Count 454 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0015
Start Address 0x7c4e87b3
Win32 Start Address 0x0100be5e
Stack Init f13c9000 Current f13c8930 Base f13c9000 Limit
f13c6000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f13c8948 8042dba9 00000008 e2bb9868 81564f88
nt!KiSwapThread+0xc5
f13c897c 80450b9b 00000003 f13c89f8 00000001
nt!KeWaitForMultipleObjects+0x266
f13c8d48 80465691 00000003 0006da88 00000001
nt!NtWaitForMultipleObjects+0x3a0
f13c8d48 77f9323e 00000003 0006da88 00000001
nt!KiSystemService+0xc4
0006da60 00000000 00000000 00000000 00000000 +0x77f9323e

THREAD 81519da0 Cid 458.4a0 Teb: 7ffd8000 Win32Thread:
e2bf5008 WAIT: (WrLpcReceive) UserMode Non-Alertable
81711288 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 81564ce0
Wait Start TickCount 29857 Elapsed Ticks: 5627
Context Switch Count 39 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Stack Init f130d000 Current f130cc48 Base f130d000 Limit
f130a000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f130cc60 8042de88 f130cd64 e2bdbbc0 00000000
nt!KiSwapThread+0xc5
f130cc88 80434d74 81711288 00000010 00000301
nt!KeWaitForSingleObject+0x1a1
f130cd48 80465691 000000f0 0193ff54 00000000
nt!NtReplyWaitReceivePortEx+0x45e
f130cd48 77f839c7 000000f0 0193ff54 00000000
nt!KiSystemService+0xc4
0193fe24 00000000 00000000 00000000 00000000 +0x77f839c7

PROCESS 8149cb20 SessionId: 0 Cid: 04c8 Peb: 7ffdf000 ParentCid:
0070
DirBase: 0fe01000 ObjectTable: 8153a188 TableSize: 656.
Image: msiexec.exe
VadRoot 815478e8 Clone 0 Private 196. Modified 0. Locked 0.
DeviceMap 8189e668
Token e2c9aa70
ElapsedTime 0:06:18.0125
UserTime 0:00:00.0093
KernelTime 0:00:00.0562
QuotaPoolUsage[PagedPool] 27704
QuotaPoolUsage[NonPagedPool] 3632
Working Set Sizes (now,min,max) (831, 50, 345) (3324KB, 200KB,
1380KB)
PeakWorkingSetSize 963
VirtualSize 23 Mb
PeakVirtualSize 29 Mb
PageFaultCount 2729
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 251

THREAD 8149c8a0 Cid 4c8.4c4 Teb: 7ffde000 Win32Thread:
e2c9ada8 WAIT: (UserRequest) UserMode Non-Alertable
815a4440 ProcessObject
815126c0 NotificationEvent
8150e9a0 SynchronizationEvent
Not impersonating
Owning Process 8149cb20
Wait Start TickCount 11806 Elapsed Ticks: 23678
Context Switch Count 67 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0015
Start Address 0x7c4e87b3
Win32 Start Address 0x0100be5e
Stack Init f1591000 Current f1590930 Base f1591000 Limit
f158e000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f1590948 8042dba9 00000008 e2c99868 8153a188
nt!KiSwapThread+0xc5
f159097c 80450b9b 00000003 f15909f8 00000001
nt!KeWaitForMultipleObjects+0x266
f1590d48 80465691 00000003 0006da88 00000001
nt!NtWaitForMultipleObjects+0x3a0
f1590d48 77f9323e 00000003 0006da88 00000001
nt!KiSystemService+0xc4
0006da60 00000000 00000000 00000000 00000000 +0x77f9323e

THREAD 814b9a40 Cid 4c8.4cc Teb: 7ffdd000 Win32Thread:
e2c9e008 WAIT: (WrLpcReceive) UserMode Non-Alertable
8154db88 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 8149cb20
Wait Start TickCount 30869 Elapsed Ticks: 4615
Context Switch Count 97 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Stack Init f14d1000 Current f14d0c48 Base f14d1000 Limit
f14ce000 Call 0
Priority 9 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f14d0c60 8042de88 f14d0d64 e2c83420 00000000
nt!KiSwapThread+0xc5
f14d0c88 80434d74 8154db88 00000010 f14d0d01
nt!KeWaitForSingleObject+0x1a1
f14d0d48 80465691 000000f0 00d9ff54 00000000
nt!NtReplyWaitReceivePortEx+0x45e
f14d0d48 77f839c7 000000f0 00d9ff54 00000000
nt!KiSystemService+0xc4
00d9fe24 00000000 00000000 00000000 00000000 +0x77f839c7

PROCESS 81334b20 SessionId: 0 Cid: 0554 Peb: 7ffdf000 ParentCid:
0070
DirBase: 09f71000 ObjectTable: 814da6e8 TableSize: 79.
Image: msiexec.exe
VadRoot 813342a8 Clone 0 Private 144. Modified 0. Locked 0.
DeviceMap 8189e668
Token e2cc7bb0
ElapsedTime 0:06:12.0031
UserTime 0:00:00.0015
KernelTime 0:00:00.0000
QuotaPoolUsage[PagedPool] 19676
QuotaPoolUsage[NonPagedPool] 2956
Working Set Sizes (now,min,max) (579, 50, 345) (2316KB, 200KB,
1380KB)
PeakWorkingSetSize 619
VirtualSize 19 Mb
PeakVirtualSize 24 Mb
PageFaultCount 625
MemoryPriority BACKGROUND
BasePriority 8
CommitCharge 184

THREAD 813348a0 Cid 554.1b4 Teb: 7ffde000 Win32Thread:
e2cc6448 WAIT: (UserRequest) UserMode Non-Alertable
815a4440 ProcessObject
81416c00 NotificationEvent
814734c0 SynchronizationEvent
Not impersonating
Owning Process 81334b20
Wait Start TickCount 11806 Elapsed Ticks: 23678
Context Switch Count 65 LargeStack
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e87b3
Win32 Start Address 0x0100be5e
Stack Init f12fd000 Current f12fc930 Base f12fd000 Limit
f12f9000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f12fc948 8042dba9 00000008 e2cc8868 814da6e8
nt!KiSwapThread+0xc5
f12fc97c 80450b9b 00000003 f12fc9f8 00000001
nt!KeWaitForMultipleObjects+0x266
f12fcd48 80465691 00000003 0006da88 00000001
nt!NtWaitForMultipleObjects+0x3a0
f12fcd48 77f9323e 00000003 0006da88 00000001
nt!KiSystemService+0xc4
0006da60 00000000 00000000 00000000 00000000 +0x77f9323e

THREAD 81307920 Cid 554.558 Teb: 7ffdd000 Win32Thread:
00000000 WAIT: (WrLpcReceive) UserMode Non-Alertable
81509b08 Semaphore Limit 0x7fffffff
Not impersonating
Owning Process 81334b20
Wait Start TickCount 30875 Elapsed Ticks: 4609
Context Switch Count 8
UserTime 0:00:00.0000
KernelTime 0:00:00.0000
Start Address 0x7c4e9824
Stack Init f14e1000 Current f14e0c48 Base f14e1000 Limit
f14de000 Call 0
Priority 8 BasePriority 8 PriorityDecrement 0 DecrementCount 0
Kernel stack not resident.

ChildEBP RetAddr Args to Child
f14e0c60 8042de88 f14e0d64 e2be9560 00000000
nt!KiSwapThread+0xc5
f14e0c88 80434d74 81509b08 00000010 8044af01
nt!KeWaitForSingleObject+0x1a1
f14e0d48 80465691 000000f4 00d9ff54 00000000
nt!NtReplyWaitReceivePortEx+0x45e
f14e0d48 77f839c7 000000f4 00d9ff54 00000000
nt!KiSystemService+0xc4
00d9fe24 00000000 00000000 00000000 00000000 +0x77f839c7

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

OSR_Community_User · November 22, 2004, 8:44am

Does this problem not occur on WinXP? If the problem is reproducable on
WinXP, you should be able to find it with XP verifier.

If it doesn’t show on WinXP, then that’s also an indication, and it’s
telling you that it’s a Win2K specific problem. This could either be that
you’re using different code-paths for Win2K, or you’re doing something that
internally acts different in Win2K and WinXP, and thus causes a deadlock.

You should consider that there may well be situations where YOU are only
holding one lock, but some other component(s) in the system is holding
another lock that causes a deadlock. Tecnically, it doesn’t even have to be
a single lock in your driver, just that your driver calls some part of the
functionality surrounding it that isn’t capable of doing what you ask for
at that point, due to some lock being held by the function that you’re
being called from.

For example, we’ve got a lock in the display driver. There’s also a lock in
GDI (the grapics driver interface), which is supposed to prevent calls from
coming into our driver when it’s already doing something. If we hold our
lock and call back into GDI, a deadlock will occur if the driver is being
called again from another thread that also needs to call into GDI. So we
have to make sure we’re NOT holding our lock when calling back into GDI.

–
Mats

xxxxx@lists.osr.com wrote on 11/22/2004 12:46:59 PM:

I know But The deadlock detection tick does not exists in the WIN2K
version.
I wonder if there is any other tool for deadlock detection in WIN2K.

anurag

-----Original Message-----
From: Daniel E. Germann [mailto:xxxxx@visi.com]
Sent: Sunday, November 21, 2004 8:26 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Hanging problem

>> 2) if it is not your own code then DV (only for xp ) is good idea
> I am on W2k hence DV would not help.

Driver Verifier is available under Windows 2000.

Start / Run / verifier.exe

Select your driver and turn on everything but low resources simulation
(you should do that later, after this problem has been solved, to make
sure your driver handles low resource conditions properly). That might
help you find where things are going wrong.

http://support.microsoft.com/kb/244617/EN-US/

-Dan

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at http://www.
osronline.com/article.cfm?id=256

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

ForwardSourceID:NT00007B1A

Prokash_Sinha-1 · November 22, 2004, 10:19am

Your p_code looks fine.

If you dont need to acquire more than one lock simulaneously, you dont
have to follow hierarchy. But if you need to acquire more than one lock
before critical section starts, you have to follow an order(sequence) to
hold them. btw, this is well explained in lot of os literature, and one
bullete can shoot multiple birds if you look at the other osr online
articles on synchronization. This applies to any any lock, not just fast
mutex.
fast mutex (well nothing comes for free, neither fast ) is not recursive.
If this is a new word, again get online to osronline.
make sure you release locks properly in every exit point of a routine,
often it is overlooked.

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Anurag Sarin
Sent: Monday, November 22, 2004 5:18 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

I didn't know abt lock hierarchy and found that It was missing in my
code. I want to know how can I implement it. As I doubt if I can have an
definate order for aquirring and releasing Fast Muitex locks. I aquire a
lock based on a condition - This may or may not occur.

To keep a definative sequence, do I acquire lock even if I do not need
so??

I have explained my code of 3 routines in Pseudo below , Will be
grateful if some body guides in terms of lock hierarchy.

I have three Dispatch Routines. In Total I have 3 Link Lists , each
protected by a different lock.
LL1 protected by Lock A
LL2 protected by Lock B
LL3 protected by Lock C

WRITE Dispatch Routine
{
If Condition
Aquire Lock A
Do Work in LL1
Release Lock A

Aquire Lock B
Do Work in LL2
Release Lock B

some code

Aquire Lock B
Do Work in LL2
Release Lock B
Else

Aquire Lock A
Do Work in LL1
Release Lock A

Aquire Lock A
Do Work in LL1
Release Lock A
}

CREATE Dispatch Routine
{
If Condition

Aquire Lock B
Do Work in LL2
Release Lock B
Else

Aquire Lock A
Do Work in LL1
Release Lock A

}

SET_INFORMATION Dispatch Routine
{
If Condition 1

Aquire Lock B
Do Work in LL2
Release Lock B

Else Condition 2

Aquire Lock A
Do Work in LL1
Release Lock A

Aquire Lock C
Do Work in LL3
Release Lock C

Else Condition 3

Aquire Lock C
Do Work in LL3
Release Lock C

Aquire Lock A
Do Work in LL1
Release Lock A

Else Condition 4

Aquire Lock C
Do Work in LL3
Release Lock C

Aquire Lock A
Do Work in LL1
Release Lock A
}

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Sunday, November 21, 2004 12:55 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

Since you found that taking out the locks letting you avoid the
deadlock, it is quite fair to assume that you have a locking problem,
hope everyone would agree some what on it --

Now take the very basic case, (a) everywhere you try to access the list
you would be PASSIVE LEVEL (b) Assume that you never going to think
about artificial partitioning on a list, that means you would be
allowing only one thread to access the list at any given point in time.
IF THE ABOVE ASSUMPTIONS ARE TRUE your one lock per list is fine.

Now you are using two locks for two lists, so you should be careful
about lock hierarchy ( that is every places you try to acquire two
locks, you acquire in the same order, make sure you releases too. BTW,
there are osr articles on this that are online and you can look at it.

Anytime you manage to get out of the deadlock, make sure you sit back
and clean it out properly, in otherwords justify why you ( or whoever )
using those locks, why they should be deadlock free etc.,etc

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Anurag Sarin
Sent: Saturday, November 20, 2004 11:09 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

>No you should use One and only one lock per list usually

One lock per list in all dispatch routines (same in CREATE and WRITE).??
In short- I am write in my flow for Fast Mutex, right????

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Sunday, November 21, 2004 12:07 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

No you should use One and only one lock per list usually (specially when
any of the OPeration is destructive ( ie modify, add, write some such
)...

May be you should try just mutex, since fast mutex is not recursive (
hence if a thread tries to acquire it again, it is a dead lock if I
could recall ).

-pro

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Anurag Sarin
Sent: Saturday, November 20, 2004 10:23 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

Wanted to check my Use of Fast Mutex. I see that WRITE Dispatch routine
has some thing wrong as removing it gives no hanging.

In my CREATE Dispatch Routine

If (Condition A)
{ I do (A-link list) operation under (Lock A)}
If (Condition B)
{ I do (B-link list) operation under (Lock B)}

In my WRITE Dispatch Routine
If (Condition C)
{ I do (A-link list) operation under (Lock A)}
If (Condition D)
{ I do (B-link list) operation under (Lock B)}

In all I have used one lock each for my 2 Link Lists.
Both Locks are initialized in driver entry.

Same lock always protects the same Link List in two different Dispatch
routines. Like (Lock A) protects (A-link list) in both CREATE Dispatch
Routine and WRITE Dispatch Routine.

Now do I use a new lock for the same link list used in different link
list?? I.e. do I uses Like (Lock Z) to protect (A-link list) in WRITE
Dispatch Routine and let (Lock A) protects (A-link list) in CREATE
Dispatch Routine ??

Any ideas ????

Anurag

-----Original Message-----
From: Prokash Sinha [mailto:xxxxx@garlic.com]
Sent: Saturday, November 20, 2004 11:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Hanging problem

Anurag,

Dont take it personally, but I've always thought about selling just one
of a pair of shoes ( and hold the other one ). Would it be useful ???
Sure why not ? if I can manage to walk on one foot ...

When it comes down to debugging ( or for that matter in every stage of
life ) look for a simple solution and go for complex one if simple does
not solve it.

In priority order -

if it is your own code, and you understand the locks, rough crosss
checking about how you define and uses those locks should give you some
idea or to catch .
if it is not your own code then DV (only for xp ) is good idea
if the !locks commamnd catches it is in order to try, you can supress
or make it verbose, but I bet you have not seen the article from osr
then ! process 0 7 or verbose !locks to go thru and checking and you
can prun using filter (grep) as Max said ...