Strange deadlock in IRP_MJ_WRITE

ntfsd Hi

There is a deadlock i find in my filter, after i copy file which size is about 780 MB from d:\ to c:. during the copy, the explorer hanged.
I found explorer’s thread and a system thread tried to get each’s esource, so the deadlock accured.
In my IRP_MJ_WRITE dispatch routine, i made a irp package to query the file name.

My question is that why the threads wanna get share locks to complete the work? I don’t ask
them to hold such a lock!

Thank u in advance!!!

my dump file is below:

kd> !locks -v 817e1668

Resource @ 0x817e1668 Exclusively owned
Contention Count = 3
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 1
Threads: 815153a0-01<*>

THREAD 815153a0 Cid 340.204 Teb: 7ff96000 Win32Thread: e30ffba8 WAIT: (Executive) KernelMode Non-Alertable
81527488 Semaphore Limit 0x7fffffff
81515488 NotificationTimer
IRP List:
81485528: (0006,01fc) Flags: 00000830 Mdl: 00000000
Not impersonating
Owning Process 815c9020
Wait Start TickCount 66227
Context Switch Count 140971 LargeStack
UserTime 0:00:03.0855
KernelTime 0:00:40.0808
Start Address KERNEL32!BaseThreadStartThunk (0x77e6b700)
Win32 Start Address SHLWAPI!WrapperThreadProc (0x70c0b86c)
Stack Init bcf3c000 Current bcf3b410 Base bcf3c000 Limit bcf36000 Call 0
Priority 14 BasePriority 8 PriorityDecrement 6 DecrementCount 16

ChildEBP RetAddr Args to Child
bcf3b428 804facbd 00000000 81853740 815153a0 nt!KiSwapThread+0xc5
bcf3b450 804e48da 81527488 00000000 00000000 nt!KeWaitForSingleObject+0x1a1
bcf3b490 804e40a7 bcf3b578 bcf3b584 00000000 nt!ExpWaitForResource+0x1ac
bcf3b4a8 804e3ff5 81853760 00000001 bcf3b534 nt!ExpAcquireSharedStarveExclusive+0xad
bcf3b4b8 804dc78d 81853740 00000001 bcf3b5e0 nt!ExAcquireSharedStarveExclusive+0x41
bcf3b534 804e157c 816f4db8 bcf3b578 00001000 nt!CcPinFileData+0x313
bcf3b5a8 bfef7ab1 816f4db8 bcf3b5e0 00001000 nt!CcPinRead+0xda
bcf3b5d0 bfefda69 814be808 816f3208 00008000 Ntfs!NtfsPinStream+0x70
bcf3b5fc bfeff919 814be808 816f40f0 00040000 Ntfs!NtfsMapOrPinPageInBitmap+0xaa
bcf3b67c bfefee2b 814be808 816f40f0 00041b63 Ntfs!NtfsAllocateBitmapRun+0x64
bcf3b7ac bfefe608 814be808 816f40f0 e2d4ad78 Ntfs!NtfsAllocateClusters+0x918
bcf3b8d4 bfef49da 814be808 81556c28 e2d4ad78 Ntfs!NtfsAddAllocation+0x3c9
bcf3ba0c bfef4bc0 814be808 81556c28 81485528 Ntfs!NtfsSetEndOfFileInfo+0x621
bcf3baa4 bfef4b68 814be808 81485528 816f4020 Ntfs!NtfsCommonSetInformation+0x3d5
bcf3bb14 804ecc8b 816f4020 81485528 814856b0 Ntfs!NtfsFsdSetInformation+0xbf
bcf3bb28 bff75665 816f5740 81485528 81485694 nt!IopfCallDriver+0x35
bcf3bb4c bff7829b 816f5740 81485528 816f5740 Kfilter!KfPassThrough+0xf4
bcf3bb88 bff79530 816f5740 81485528 bcf3bd48 Kfilter!KfProtectSetInformation+0x96
bcf3bb98 804ecc8b 816f5740 81485528 814856d4 Kfilter!KfSetInformation+0x10
bcf3bbac ed818ab0 816f9800 81485528 00000000 nt!IopfCallDriver+0x35
bcf3bd48 80532f14 000003a0 0381edcc 0381ede0 CnsMinKP+0xab0
bcf3bd48 77f88bf7 000003a0 0381edcc 0381ede0 nt!KiSystemService+0xc4
0381ee44 00000000 00000000 00000000 00000000 ntdll!NtSetInformationFile+0xb

81857b20-01

THREAD 81857b20 Cid 8.14 Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
81612328 Semaphore Limit 0x7fffffff
81857c08 NotificationTimer
Not impersonating
Owning Process 818589e0
Wait Start TickCount 66228
Context Switch Count 6028
UserTime 0:00:00.0000
KernelTime 0:00:00.0600
Start Address nt!ExpWorkerThread (0x804e63a6)
Stack Init ed830000 Current ed82f478 Base ed830000 Limit ed82d000 Call 0
Priority 14 BasePriority 13 PriorityDecrement 1 DecrementCount 16

ChildEBP RetAddr Args to Child
ed82f490 804facbd 00000000 817e1668 81857b20 nt!KiSwapThread+0xc5
ed82f4b8 804e48da 81612328 00000000 00000000 nt!KeWaitForSingleObject+0x1a1
ed82f4f8 804e3f6a c00000d8 816f54c8 ed82f618 nt!ExpWaitForResource+0x1ac
ed82f510 804e3eb5 817e1668 817e3201 ed82f5d0 nt!ExpAcquireResourceSharedLite+0xb0
ed82f520 bfedcb60 817e1668 817e3201 ed82f618 nt!ExAcquireResourceSharedLite+0x41
ed82f538 bff00f36 ed82f618 816f54c8 816f3208 Ntfs!NtfsAcquireSharedFcb+0x1f
ed82f5d0 bff01245 ed82f618 8141c848 816f4020 Ntfs!NtfsCommonQueryInformation+0x166
ed82f744 804ecc8b 816f4020 8141c848 8182ddc8 Ntfs!NtfsFsdQueryInformation+0xd7
ed82f758 bff76216 00000001 8141c9b4 00000000 nt!IopfCallDriver+0x35
ed82f78c bff75be3 00000005 816f4db8 816f4020 Kfilter!KfQuerySetInformation+0x18d
ed82f7cc bff79fc9 816f5740 816f4db8 817f4668 Kfilter!KfGetFileFullPathName+0x63
ed82fa24 bff79570 816f5740 81483de8 ed82faf8 Kfilter!KfIRPWriteEncrypt+0x124
ed82fa34 804ecc8b 816f5740 81483de8 81483f94 Kfilter!KfWrite+0x10
ed82fa48 ed818ab0 816f9800 81483de8 00000000 nt!IopfCallDriver+0x35
ed82faf8 8050b92e 816f4db8 ed82fb20 ed82fba8 CnsMinKP+0xab0
ed82fbc4 8050b43a e1437020 e143704c 00000019 nt!MiFlushSectionInternal+0x36a
ed82fc04 804de7df 817e5920 00000006 0000b000 nt!MmFlushSection+0x1a4
ed82fcd8 804de104 817ee354 00000000 00000001 nt!CcFlushCache+0x399
ed82fd0c 804e2608 81858128 80542cc0 81857b20 nt!CcWriteBehind+0xc0
ed82fd78 804e6454 81858128 00000000 00000000 nt!CcWorkerThread+0x12c
ed82fda8 80522b64 81858128 00000000 00000000 nt!ExpWorkerThread+0xae
ed82fddc 8053786a 804e63a6 00000000 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Threads Waiting On Exclusive Access:
8154d860
1 total locks, 1 locks currently held

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

Resource @ 0x817e3248 Shared 1 owning threads
Threads: 81857b20-01<*>
KD: Scanning for held locks.

Resource @ 0x817e1668 Exclusively owned
Contention Count = 3
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 1
Threads: 815153a0-01<*> 81857b20-01

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

Resource @ 0x81853740 Exclusively owned
Contention Count = 1
NumberOfSharedWaiters = 1
Threads: 81857b20-01<*> 815153a0-01

???george
???xxxxx@hotmail.com
???2003-12-27

Explorer uses paging write, it is not safe to use a irp package to query the file name in paging I/O, you may save file name when the file was created.

Tang Hong
Mawadata Corporation
xxxxx@sina.com

----- Original Message -----
From: “george”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, December 27, 2003 4:57 PM
Subject: [ntfsd] Strange deadlock in IRP_MJ_WRITE

ntfsd Hi

There is a deadlock i find in my filter, after i copy file which size is about 780 MB from d:\ to c:. during the copy, the explorer hanged.
I found explorer’s thread and a system thread tried to get each’s esource, so the deadlock accured.
In my IRP_MJ_WRITE dispatch routine, i made a irp package to query the file name.

My question is that why the threads wanna get share locks to complete the work? I don’t ask
them to hold such a lock!

Thank u in advance!!!

my dump file is below:

kd> !locks -v 817e1668

Resource @ 0x817e1668 Exclusively owned
Contention Count = 3
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 1
Threads: 815153a0-01<>

THREAD 815153a0 Cid 340.204 Teb: 7ff96000 Win32Thread: e30ffba8 WAIT: (Executive) KernelMode Non-Alertable
81527488 Semaphore Limit 0x7fffffff
81515488 NotificationTimer
IRP List:
81485528: (0006,01fc) Flags: 00000830 Mdl: 00000000
Not impersonating
Owning Process 815c9020
Wait Start TickCount 66227
Context Switch Count 140971 LargeStack
UserTime 0:00:03.0855
KernelTime 0:00:40.0808
Start Address KERNEL32!BaseThreadStartThunk (0x77e6b700)
Win32 Start Address SHLWAPI!WrapperThreadProc (0x70c0b86c)
Stack Init bcf3c000 Current bcf3b410 Base bcf3c000 Limit bcf36000 Call 0
Priority 14 BasePriority 8 PriorityDecrement 6 DecrementCount 16

ChildEBP RetAddr Args to Child
bcf3b428 804facbd 00000000 81853740 815153a0 nt!KiSwapThread+0xc5
bcf3b450 804e48da 81527488 00000000 00000000 nt!KeWaitForSingleObject+0x1a1
bcf3b490 804e40a7 bcf3b578 bcf3b584 00000000 nt!ExpWaitForResource+0x1ac
bcf3b4a8 804e3ff5 81853760 00000001 bcf3b534 nt!ExpAcquireSharedStarveExclusive+0xad
bcf3b4b8 804dc78d 81853740 00000001 bcf3b5e0 nt!ExAcquireSharedStarveExclusive+0x41
bcf3b534 804e157c 816f4db8 bcf3b578 00001000 nt!CcPinFileData+0x313
bcf3b5a8 bfef7ab1 816f4db8 bcf3b5e0 00001000 nt!CcPinRead+0xda
bcf3b5d0 bfefda69 814be808 816f3208 00008000 Ntfs!NtfsPinStream+0x70
bcf3b5fc bfeff919 814be808 816f40f0 00040000 Ntfs!NtfsMapOrPinPageInBitmap+0xaa
bcf3b67c bfefee2b 814be808 816f40f0 00041b63 Ntfs!NtfsAllocateBitmapRun+0x64
bcf3b7ac bfefe608 814be808 816f40f0 e2d4ad78 Ntfs!NtfsAllocateClusters+0x918
bcf3b8d4 bfef49da 814be808 81556c28 e2d4ad78 Ntfs!NtfsAddAllocation+0x3c9
bcf3ba0c bfef4bc0 814be808 81556c28 81485528 Ntfs!NtfsSetEndOfFileInfo+0x621
bcf3baa4 bfef4b68 814be808 81485528 816f4020 Ntfs!NtfsCommonSetInformation+0x3d5
bcf3bb14 804ecc8b 816f4020 81485528 814856b0 Ntfs!NtfsFsdSetInformation+0xbf
bcf3bb28 bff75665 816f5740 81485528 81485694 nt!IopfCallDriver+0x35
bcf3bb4c bff7829b 816f5740 81485528 816f5740 Kfilter!KfPassThrough+0xf4
bcf3bb88 bff79530 816f5740 81485528 bcf3bd48 Kfilter!KfProtectSetInformation+0x96
bcf3bb98 804ecc8b 816f5740 81485528 814856d4 Kfilter!KfSetInformation+0x10
bcf3bbac ed818ab0 816f9800 81485528 00000000 nt!IopfCallDriver+0x35
bcf3bd48 80532f14 000003a0 0381edcc 0381ede0 CnsMinKP+0xab0
bcf3bd48 77f88bf7 000003a0 0381edcc 0381ede0 nt!KiSystemService+0xc4
0381ee44 00000000 00000000 00000000 00000000 ntdll!NtSetInformationFile+0xb

81857b20-01

THREAD 81857b20 Cid 8.14 Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
81612328 Semaphore Limit 0x7fffffff
81857c08 NotificationTimer
Not impersonating
Owning Process 818589e0
Wait Start TickCount 66228
Context Switch Count 6028
UserTime 0:00:00.0000
KernelTime 0:00:00.0600
Start Address nt!ExpWorkerThread (0x804e63a6)
Stack Init ed830000 Current ed82f478 Base ed830000 Limit ed82d000 Call 0
Priority 14 BasePriority 13 PriorityDecrement 1 DecrementCount 16

ChildEBP RetAddr Args to Child
ed82f490 804facbd 00000000 817e1668 81857b20 nt!KiSwapThread+0xc5
ed82f4b8 804e48da 81612328 00000000 00000000 nt!KeWaitForSingleObject+0x1a1
ed82f4f8 804e3f6a c00000d8 816f54c8 ed82f618 nt!ExpWaitForResource+0x1ac
ed82f510 804e3eb5 817e1668 817e3201 ed82f5d0 nt!ExpAcquireResourceSharedLite+0xb0
ed82f520 bfedcb60 817e1668 817e3201 ed82f618 nt!ExAcquireResourceSharedLite+0x41
ed82f538 bff00f36 ed82f618 816f54c8 816f3208 Ntfs!NtfsAcquireSharedFcb+0x1f
ed82f5d0 bff01245 ed82f618 8141c848 816f4020 Ntfs!NtfsCommonQueryInformation+0x166
ed82f744 804ecc8b 816f4020 8141c848 8182ddc8 Ntfs!NtfsFsdQueryInformation+0xd7
ed82f758 bff76216 00000001 8141c9b4 00000000 nt!IopfCallDriver+0x35
ed82f78c bff75be3 00000005 816f4db8 816f4020 Kfilter!KfQuerySetInformation+0x18d
ed82f7cc bff79fc9 816f5740 816f4db8 817f4668 Kfilter!KfGetFileFullPathName+0x63
ed82fa24 bff79570 816f5740 81483de8 ed82faf8 Kfilter!KfIRPWriteEncrypt+0x124
ed82fa34 804ecc8b 816f5740 81483de8 81483f94 Kfilter!KfWrite+0x10
ed82fa48 ed818ab0 816f9800 81483de8 00000000 nt!IopfCallDriver+0x35
ed82faf8 8050b92e 816f4db8 ed82fb20 ed82fba8 CnsMinKP+0xab0
ed82fbc4 8050b43a e1437020 e143704c 00000019 nt!MiFlushSectionInternal+0x36a
ed82fc04 804de7df 817e5920 00000006 0000b000 nt!MmFlushSection+0x1a4
ed82fcd8 804de104 817ee354 00000000 00000001 nt!CcFlushCache+0x399
ed82fd0c 804e2608 81858128 80542cc0 81857b20 nt!CcWriteBehind+0xc0
ed82fd78 804e6454 81858128 00000000 00000000 nt!CcWorkerThread+0x12c
ed82fda8 80522b64 81858128 00000000 00000000 nt!ExpWorkerThread+0xae
ed82fddc 8053786a 804e63a6 00000000 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Threads Waiting On Exclusive Access:
8154d860
1 total locks, 1 locks currently held

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

Resource @ 0x817e3248 Shared 1 owning threads
Threads: 81857b20-01<
>
KD: Scanning for held locks.

Resource @ 0x817e1668 Exclusively owned
Contention Count = 3
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 1
Threads: 815153a0-01<> 81857b20-01

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

Resource @ 0x81853740 Exclusively owned
Contention Count = 1
NumberOfSharedWaiters = 1
Threads: 81857b20-01<
> 815153a0-01

???george
???xxxxx@hotmail.com
???2003-12-27


Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

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

There are many times when it is not safe to do recursive operations such as name queries. Some of these are:

  • If the IRP_PAGING_IO flag is set
  • If the return value from IoGetTopLevelIrp() is non-zero and this is NOT an IRP_MJ_CREATE operation.

The reason it is not safe is because the file system is already holding a lock when the recursive operation was called. I am guessing this is what is happening to you.

This is how the file systems work and you are going to have to work around this. I would recommend that you do your name query at create time and then cache the name. Of course you will have to deal with rename operations if you are going to do this.

I recommend to everyone that you avoid doing name queries on read and write operations because of the overall performance hit on the system. In general, the overall performance of a file system in real world environments is based on the performance of read and write operations. All other operations are insignificant.

You should determine if a given file is interesting to your filter on other operations (like IRP_MJ_CREATE) and then save this information using PerStreamContexts or a private hash table of some kind. Then, when a read or write occurs (or some other operation) you do a simple lookup and test to determine what you should do.

Doing these types of simple optimizations will greatly reduce the performance impact of your filter on the system.

And now for my shameless plug for the filter manager. Its naming code knows when it is safe to do name queries plus it caches names that are retrieved.

Neal Christiansen
Microsoft File System Filter Group Lead

This posting is provided “AS IS” with no warranties, and confers no rights.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tang Hong
Sent: Saturday, December 27, 2003 1:12 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Re: Strange deadlock in IRP_MJ_WRITE

Explorer uses paging write, it is not safe to use a irp package to query the file name in paging I/O, you may save file name when the file was created.

Tang Hong
Mawadata Corporation
xxxxx@sina.com

----- Original Message -----
From: “george”
To: “Windows File Systems Devs Interest List”
Sent: Saturday, December 27, 2003 4:57 PM
Subject: [ntfsd] Strange deadlock in IRP_MJ_WRITE

ntfsd Hi

There is a deadlock i find in my filter, after i copy file which size is about 780 MB from d:\ to c:. during the copy, the explorer hanged.
I found explorer’s thread and a system thread tried to get each’s esource, so the deadlock accured.
In my IRP_MJ_WRITE dispatch routine, i made a irp package to query the file name.

My question is that why the threads wanna get share locks to complete the work? I don’t ask
them to hold such a lock!

Thank u in advance!!!

my dump file is below:

kd> !locks -v 817e1668

Resource @ 0x817e1668 Exclusively owned
Contention Count = 3
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 1
Threads: 815153a0-01<>

THREAD 815153a0 Cid 340.204 Teb: 7ff96000 Win32Thread: e30ffba8 WAIT: (Executive) KernelMode Non-Alertable
81527488 Semaphore Limit 0x7fffffff
81515488 NotificationTimer
IRP List:
81485528: (0006,01fc) Flags: 00000830 Mdl: 00000000
Not impersonating
Owning Process 815c9020
Wait Start TickCount 66227
Context Switch Count 140971 LargeStack
UserTime 0:00:03.0855
KernelTime 0:00:40.0808
Start Address KERNEL32!BaseThreadStartThunk (0x77e6b700)
Win32 Start Address SHLWAPI!WrapperThreadProc (0x70c0b86c)
Stack Init bcf3c000 Current bcf3b410 Base bcf3c000 Limit bcf36000 Call 0
Priority 14 BasePriority 8 PriorityDecrement 6 DecrementCount 16

ChildEBP RetAddr Args to Child
bcf3b428 804facbd 00000000 81853740 815153a0 nt!KiSwapThread+0xc5
bcf3b450 804e48da 81527488 00000000 00000000 nt!KeWaitForSingleObject+0x1a1
bcf3b490 804e40a7 bcf3b578 bcf3b584 00000000 nt!ExpWaitForResource+0x1ac
bcf3b4a8 804e3ff5 81853760 00000001 bcf3b534 nt!ExpAcquireSharedStarveExclusive+0xad
bcf3b4b8 804dc78d 81853740 00000001 bcf3b5e0 nt!ExAcquireSharedStarveExclusive+0x41
bcf3b534 804e157c 816f4db8 bcf3b578 00001000 nt!CcPinFileData+0x313
bcf3b5a8 bfef7ab1 816f4db8 bcf3b5e0 00001000 nt!CcPinRead+0xda
bcf3b5d0 bfefda69 814be808 816f3208 00008000 Ntfs!NtfsPinStream+0x70
bcf3b5fc bfeff919 814be808 816f40f0 00040000 Ntfs!NtfsMapOrPinPageInBitmap+0xaa
bcf3b67c bfefee2b 814be808 816f40f0 00041b63 Ntfs!NtfsAllocateBitmapRun+0x64
bcf3b7ac bfefe608 814be808 816f40f0 e2d4ad78 Ntfs!NtfsAllocateClusters+0x918
bcf3b8d4 bfef49da 814be808 81556c28 e2d4ad78 Ntfs!NtfsAddAllocation+0x3c9
bcf3ba0c bfef4bc0 814be808 81556c28 81485528 Ntfs!NtfsSetEndOfFileInfo+0x621
bcf3baa4 bfef4b68 814be808 81485528 816f4020 Ntfs!NtfsCommonSetInformation+0x3d5
bcf3bb14 804ecc8b 816f4020 81485528 814856b0 Ntfs!NtfsFsdSetInformation+0xbf
bcf3bb28 bff75665 816f5740 81485528 81485694 nt!IopfCallDriver+0x35
bcf3bb4c bff7829b 816f5740 81485528 816f5740 Kfilter!KfPassThrough+0xf4
bcf3bb88 bff79530 816f5740 81485528 bcf3bd48 Kfilter!KfProtectSetInformation+0x96
bcf3bb98 804ecc8b 816f5740 81485528 814856d4 Kfilter!KfSetInformation+0x10
bcf3bbac ed818ab0 816f9800 81485528 00000000 nt!IopfCallDriver+0x35
bcf3bd48 80532f14 000003a0 0381edcc 0381ede0 CnsMinKP+0xab0
bcf3bd48 77f88bf7 000003a0 0381edcc 0381ede0 nt!KiSystemService+0xc4
0381ee44 00000000 00000000 00000000 00000000 ntdll!NtSetInformationFile+0xb

81857b20-01

THREAD 81857b20 Cid 8.14 Teb: 00000000 Win32Thread: 00000000 WAIT: (Executive) KernelMode Non-Alertable
81612328 Semaphore Limit 0x7fffffff
81857c08 NotificationTimer
Not impersonating
Owning Process 818589e0
Wait Start TickCount 66228
Context Switch Count 6028
UserTime 0:00:00.0000
KernelTime 0:00:00.0600
Start Address nt!ExpWorkerThread (0x804e63a6)
Stack Init ed830000 Current ed82f478 Base ed830000 Limit ed82d000 Call 0
Priority 14 BasePriority 13 PriorityDecrement 1 DecrementCount 16

ChildEBP RetAddr Args to Child
ed82f490 804facbd 00000000 817e1668 81857b20 nt!KiSwapThread+0xc5
ed82f4b8 804e48da 81612328 00000000 00000000 nt!KeWaitForSingleObject+0x1a1
ed82f4f8 804e3f6a c00000d8 816f54c8 ed82f618 nt!ExpWaitForResource+0x1ac
ed82f510 804e3eb5 817e1668 817e3201 ed82f5d0 nt!ExpAcquireResourceSharedLite+0xb0
ed82f520 bfedcb60 817e1668 817e3201 ed82f618 nt!ExAcquireResourceSharedLite+0x41
ed82f538 bff00f36 ed82f618 816f54c8 816f3208 Ntfs!NtfsAcquireSharedFcb+0x1f
ed82f5d0 bff01245 ed82f618 8141c848 816f4020 Ntfs!NtfsCommonQueryInformation+0x166
ed82f744 804ecc8b 816f4020 8141c848 8182ddc8 Ntfs!NtfsFsdQueryInformation+0xd7
ed82f758 bff76216 00000001 8141c9b4 00000000 nt!IopfCallDriver+0x35
ed82f78c bff75be3 00000005 816f4db8 816f4020 Kfilter!KfQuerySetInformation+0x18d
ed82f7cc bff79fc9 816f5740 816f4db8 817f4668 Kfilter!KfGetFileFullPathName+0x63
ed82fa24 bff79570 816f5740 81483de8 ed82faf8 Kfilter!KfIRPWriteEncrypt+0x124
ed82fa34 804ecc8b 816f5740 81483de8 81483f94 Kfilter!KfWrite+0x10
ed82fa48 ed818ab0 816f9800 81483de8 00000000 nt!IopfCallDriver+0x35
ed82faf8 8050b92e 816f4db8 ed82fb20 ed82fba8 CnsMinKP+0xab0
ed82fbc4 8050b43a e1437020 e143704c 00000019 nt!MiFlushSectionInternal+0x36a
ed82fc04 804de7df 817e5920 00000006 0000b000 nt!MmFlushSection+0x1a4
ed82fcd8 804de104 817ee354 00000000 00000001 nt!CcFlushCache+0x399
ed82fd0c 804e2608 81858128 80542cc0 81857b20 nt!CcWriteBehind+0xc0
ed82fd78 804e6454 81858128 00000000 00000000 nt!CcWorkerThread+0x12c
ed82fda8 80522b64 81858128 00000000 00000000 nt!ExpWorkerThread+0xae
ed82fddc 8053786a 804e63a6 00000000 00000000 nt!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Threads Waiting On Exclusive Access:
8154d860
1 total locks, 1 locks currently held

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

Resource @ 0x817e3248 Shared 1 owning threads
Threads: 81857b20-01<
>
KD: Scanning for held locks.

Resource @ 0x817e1668 Exclusively owned
Contention Count = 3
NumberOfSharedWaiters = 1
NumberOfExclusiveWaiters = 1
Threads: 815153a0-01<> 81857b20-01

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

Resource @ 0x81853740 Exclusively owned
Contention Count = 1
NumberOfSharedWaiters = 1
Threads: 81857b20-01<
> 815153a0-01

george
xxxxx@hotmail.com
2003-12-27


Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17

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

B缍*癤沧y蓞釮Pj囟?
⑹瀀y数獕蓂鵷b豆畍礿j拢壊r⒐i瀓⒔~霒