Exactly. You are calling NTFS with some combination of parameters that
hasn’t been tested in the W2K environment and doesn’t work right. You’ll
have to figure out what that call is. Having done that you can start
looking at the specifics of the call and change your pattern of behavior
so that it DOES work right.
Its still easier than trying to figure out why Explorer does some of the
strange things it does - at least NTFS makes sense…
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Sunday, August 06, 2006 5:16 PM
To: ntfsd redirect
Subject: RE: [ntfsd] Strange Win2k NTFS deadlock
Thanks Tony. Ugh. So I was thinking it would be next to impossible to
see
what you are describing. Basically, you are saying there could be a bug
in
the NTFS code that fails to release the lock in some code path, right?
And
if this is the case, I would have to just “deal” and work around it I
suppose…
Matt
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tony Mason
Sent: Sunday, August 06, 2006 4:58 PM
To: Windows File Systems Devs Interest List
Subject: RE: [ntfsd] Strange Win2k NTFS deadlock
If a thread owns an ERESOURCE shared and then tries to acquire it
exclusive,
that thread WILL deadlock (and that is the case here.) Since there’s no
obvious path in THIS stack that acquires the lock shared, you should be
looking for a path previously (in this thread) that failed to release
the
lock.
For example, we recently saw this when we sent an asynchronous rename
request to NTFS on W2K - it works fine on later versions, but exits the
rename logic with the lock held on W2K.
I’ve also seen cases where NTFS uses try/except, catches the exception
but
leaves the lock held. You have to identify the suspect operation, which
can
definitely be an interesting challenge - in a work queue like you have
there, it can often be some previous work item. I’ve found that
tracking
these issues down is rather challenging.
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Matthew N. White
Sent: Sunday, August 06, 2006 4:46 PM
To: ntfsd redirect
Subject: [ntfsd] Strange Win2k NTFS deadlock
Has anyone ever seen anything like this? On win2k, NTFS, a write (with
a
rolled IRP) into NTFS causes a deadlock. The IRP is paging/noncached,
and
seems to make NTFS grab the NTFS file FCB’s main resource first shared,
and
then it tries exclusive, resulting in the thread deadlocking on itself.
Or
at least that’s what this looks like. Any ideas of why this could be
happening? I’ve shown the stack trace and !locks output below for the
offending ERESOURCE.
Also, this does not happen on WinXP or Win2K3. But it is fairly
consistent
on 2K.
***************************************************
kd> kv
*** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr Args to Child
f2473678 8043b7da 00000000 825de008 82783da0 nt!KiSwapThread+0x1b1 (FPO:
[Uses EBP] [0,0,4])
f24736a0 8041961a 823373a8 00000000 00000000
nt!KeWaitForSingleObject+0x1dd
(FPO: [Non-Fpo])
f24736e0 80417b45 825de008 825de008 f2473704 nt!ExpWaitForResource+0x1b4
(FPO: [Non-Fpo])
f24736f0 80417c7a 80063110 825de008 825de03c
nt!ExpAcquireResourceExclusiveLite+0x7b (FPO: [Non-Fpo])
f2473704 80417b2a 825de000 00000001 825de03c
nt!ExAcquireResourceExclusiveLite+0x92 (FPO: [Non-Fpo])
f2473724 80417c7a 00000000 e201b978 825cd188
nt!ExpAcquireResourceExclusiveLite+0x60 (FPO: [Non-Fpo])
f2473738 bfe4d3d4 825de000 00000001 00000000
nt!ExAcquireResourceExclusiveLite+0x92 (FPO: [Non-Fpo]) f2473ab0
bfe4b34a
825cd188 82321a28 8276c800 Ntfs!NtfsCommonWrite+0x1df2
(FPO: [Non-Fpo])
f2473b18 80424f7c 8276c800 82321a28 00000000 Ntfs!NtfsFsdWrite+0xee
(FPO:
[Non-Fpo])
f2473b30 bff2196b 00000000 00000000 00000000 nt!IopfCallDriver+0x4f
(FPO:
[0,0,3])
f2473d10 bff1f3cb 82452688 82476d90 00001000
mydriver!MyDrivChunkProcessLowerWriteIo+0x1a1b (FPO: [Non-Fpo]) (CONV:
stdcall) [c:\somefile @ 870]
f2473d64 bff15d2c 82476d88 12345678 12345678
mydriver!MyDrivChunkProcessLowerIo+0x2fb (FPO: [Non-Fpo]) (CONV:
stdcall)
[c:\somefile @ 142]
f2473da8 804aa09a bff5e3e0 00000000 00000000
mydriver!MyDrivWorkerWork+0x35c
(FPO: [Non-Fpo]) (CONV: stdcall) [c:\somefile @ 142] f2473ddc 804c526a
bff159d0 bff5e3e0 00000000
nt!PspSystemThreadStartup+0x54
(FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
***************************************************
Resource @ 0x825de008 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: 82783da0-01<*>
Threads Waiting On Exclusive Access:
82783da0
KD: Scanning for held locks…
***************************************************
Thanks,
Matt
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com To unsubscribe
send
a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com