Waiting for lock in FltClose

A call to FltClose is causing a deadlock in my minifilter (Win7 x64) when performing a copy on write functionality during PreWrite.

Below is the output of !locks along with the stack trace and some IRP info. My filter is not taking any locks during this operation so I’m not sure what it is waiting for exclusive access to. But because I use the same copying code in other code paths in the filter, I’m assuming there is a conflict with the it being called during PreWrite. However because the file does copy fine I don’t understand what that conflict might be.

nt!RtlpBreakWithStatusInstruction:
fffff800`028cbcf0 cc int 3
kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks…

Resource @ 0xfffffa8002b46888 Shared 1 owning threads
Contention Count = 17
Threads: fffffa80026ecb50-02<*>
KD: Scanning for held locks

Resource @ 0xfffffa8001fc7f38 Shared 2 owning threads
Threads: fffffa80025fc060-01<*> fffffa80018e1b50-01<*>
KD: Scanning for held locks

Resource @ 0xfffffa8001fbd698 Shared 1 owning threads
Contention Count = 1
NumberOfExclusiveWaiters = 1
Threads: fffffa80026ecb50-02<*>
Threads Waiting On Exclusive Access:
fffffa80026ecb50

KD: Scanning for held locks…
17237 total locks, 3 locks currently held
kd> .thread fffffa80026ecb50
Implicit thread is now fffffa80`026ecb50

kd> k
*** Stack trace for last set context - .thread/.cxr resets it
Child-SP RetAddr Call Site
fffff880058cf7c0 fffff800028d90f2 nt!KiSwapContext+0x7a
fffff880058cf900 fffff800028db90f nt!KiCommitThreadWait+0x1d2
fffff880058cf990 fffff800028b4b46 nt!KeWaitForSingleObject+0x19f
fffff880058cfa30 fffff800028d9d2c nt!ExpWaitForResource+0xae
fffff880058cfaa0 fffff880012dc244 nt!ExAcquireResourceExclusiveLite+0x14f
fffff880058cfb10 fffff8800124b639 Ntfs!NtfsCommonCleanup+0x2721
fffff880058cff30 fffff800028cb9b7 Ntfs!NtfsCommonCleanupCallout+0x19
fffff880058cff60 fffff800028cb978 nt!KxSwitchKernelStackCallout+0x27
fffff88005839600 fffff800028e0982 nt!KiSwitchKernelStackContinue
fffff88005839620 fffff8800124b6b2 nt!KeExpandKernelStackAndCalloutEx+0x2a2
fffff88005839700 fffff880012e8ba4 Ntfs!NtfsCommonCleanupOnNewStack+0x42
fffff88005839770 fffff88001180bcf Ntfs!NtfsFsdCleanup+0x144
fffff880058399e0 fffff8800117f6df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff88005839a70 fffff80002bdf2ef fltmgr!FltpDispatch+0xcf
fffff88005839ad0 fffff80002bcd2e4 nt!IopCloseFile+0x11f
fffff88005839b60 fffff80002bcd0a1 nt!ObpDecrementHandleCount+0xb4
fffff88005839be0 fffff80002bcd664 nt!ObpCloseHandleTableEntry+0xb1
fffff88005839c70 fffff800028d3153 nt!ObpCloseHandle+0x94
fffff88005839cc0 fffff800028cf710 nt!KiSystemServiceCopyEnd+0x13
fffff88005839e58 fffff88003542f81 nt!KiServiceLinkage
fffff8800583a070 fffff88001180067 MYFILTER!PreWrite
fffff8800583a1b0 fffff88001181329 fltmgr!FltpPerformPreCallbacks+0x2f7
fffff8800583a2b0 fffff8800117f6c7 fltmgr!FltpPassThrough+0x2d9
fffff8800583a330 fffff800028b9ebf fltmgr!FltpDispatch+0xb7
fffff8800583a390 fffff80002917d0b nt!IoSynchronousPageWrite+0x24f
fffff8800583a410 fffff80002916398 nt!MiFlushSectionInternal+0xb7b
fffff8800583a650 fffff80002915729 nt!MmFlushSection+0x1f4
fffff8800583a710 fffff880012c12e7 nt!CcFlushCache+0x5e9
fffff8800583a810 fffff880012c0aa2 Ntfs!NtfsFlushUserStream+0xb7
fffff8800583a890 fffff880012bf9af Ntfs!NtfsPerformOptimisticFlush+0x62
fffff8800583a8e0 fffff880012c041d Ntfs!NtfsCommonFlushBuffers+0x12f
fffff8800583a9c0 fffff88001180bcf Ntfs!NtfsFsdFlushBuffers+0x10d
fffff8800583aa30 fffff8800117f6df fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff8800583aac0 fffff80002bdfafb fltmgr!FltpDispatch+0xcf
fffff8800583ab20 fffff80002b74721 nt!IopSynchronousServiceTail+0xfb
fffff8800583ab90 fffff800028d3153 nt!NtFlushBuffersFile+0x171
fffff8800583ac20 0000000077a6176a nt!KiSystemServiceCopyEnd+0x13
000000000220e7f8 000000007450b42b ntdll!NtFlushBuffersFile+0xa
000000000220e800 00000000744fd18f wow64!whNtFlushBuffersFile+0x33
000000000220e840 0000000074fd2776 wow64!Wow64SystemServiceEx+0xd7
000000000220f100 00000000744fd286 wow64cpu!ServiceNoTurbo+0x2d
000000000220f1c0 00000000744fc69e wow64!RunCpuSimulation+0xa
000000000220f210 0000000077a8d447 wow64!Wow64LdrpInitialize+0x42a
000000000220f760 0000000077a3c34e ntdll! ?? ::FNODOBFM::string'+0x29134 000000000220f7d0 00000000`00000000 ntdll!LdrInitializeThunk+0xe

kd> !thread fffffa80026ecb50
THREAD fffffa80026ecb50 Cid 0d1c.0d80 Teb: 000000007efa1000 Win32Thread: 0000000000000000 WAIT: (WrResource) KernelMode Non-Alertable
fffffa8003650d90 SynchronizationEvent
IRP List:
fffffa8002d17c60: (0006,03a0) Flags: 00000404 Mdl: 00000000
fffffa8003c385f0: (0006,03a0) Flags: 00060043 Mdl: fffff8800583a540
fffffa8002436c60: (0006,03a0) Flags: 00060000 Mdl: 00000000

kd> !irp fffffa8002d17c60
Irp is active with 10 stacks 9 is current (= 0xfffffa8002d17f70)
No Mdl: No System Buffer: Thread fffffa80026ecb50: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[12, 0] 0 e0 fffffa8002b46030 fffffa8003a4f2d0 fffff88001183e40-fffffa80025da770 Success Error Cancel
\FileSystem\Ntfs fltmgr!FltpPassThroughCompletion
Args: 00000000 00000000 00000000 00000000
[12, 0] 0 1 fffffa8002d158b0 fffffa8003a4f2d0 00000000-00000000 pending
\FileSystem\FltMgr
Args: 00000000 00000000 00000000 00000000
kd> !irp fffffa8003c385f0
Irp is active with 10 stacks 10 is current (= 0xfffffa8003c38948)
Mdl=fffff8800583a540: No System Buffer: Thread fffffa80026ecb50: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[4, 0] 0 1 fffffa8002d158b0 fffffa8002b0c500 00000000-00000000 pending
\FileSystem\FltMgr
Args: 00003000 00000000 00000000 00000000
kd> !irp fffffa8002436c60
Irp is active with 10 stacks 10 is current (= 0xfffffa8002436fb8)
No Mdl: No System Buffer: Thread fffffa80026ecb50: Irp stack trace.
cmd flg cl Device File Completion-Context
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000

[9, 0] 0 0 fffffa8002b46030 fffffa8002b0c500 00000000-00000000
\FileSystem\Ntfs
Args: 00000000 00000000 00000000 00000000

From the !locks output:

NTFS acquired the resource shared before calling CcFlushCache. The flush
from the cache resulted in your minifilter being called in preWrite. I
think you did FltClose() on the same file which resulted in NTFS again
trying to acquire the same resource exclusively and resulting in a
single-thread deadlock.

Thanks

On Sat, May 23, 2015 at 12:16 PM, wrote:

> A call to FltClose is causing a deadlock in my minifilter (Win7 x64) when
> performing a copy on write functionality during PreWrite.
>
> Below is the output of !locks along with the stack trace and some IRP
> info. My filter is not taking any locks during this operation so I’m not
> sure what it is waiting for exclusive access to. But because I use the
> same copying code in other code paths in the filter, I’m assuming there is
> a conflict with the it being called during PreWrite. However because the
> file does copy fine I don’t understand what that conflict might be.
>
> nt!RtlpBreakWithStatusInstruction:
> fffff800028cbcf0 cc int 3<br>&gt; kd&gt; !locks<br>&gt; ****DUMP OF ALL RESOURCE OBJECTS**** <br>&gt; KD: Scanning for held locks....<br>&gt;<br>&gt; Resource @ 0xfffffa8002b46888 Shared 1 owning threads<br>&gt; Contention Count = 17<br>&gt; Threads: fffffa80026ecb50-02&lt;*&gt;<br>&gt; KD: Scanning for held locks<br>&gt;<br>&gt; Resource @ 0xfffffa8001fc7f38 Shared 2 owning threads<br>&gt; Threads: fffffa80025fc060-01&lt;*&gt; fffffa80018e1b50-01&lt;*&gt;<br>&gt; KD: Scanning for held locks<br>&gt;<br>&gt; Resource @ 0xfffffa8001fbd698 Shared 1 owning threads<br>&gt; Contention Count = 1<br>&gt; NumberOfExclusiveWaiters = 1<br>&gt; Threads: fffffa80026ecb50-02&lt;*&gt;<br>&gt; Threads Waiting On Exclusive Access:<br>&gt; fffffa80026ecb50<br>&gt;<br>&gt; KD: Scanning for held locks......<br>&gt; 17237 total locks, 3 locks currently held<br>&gt; kd&gt; .thread fffffa80026ecb50<br>&gt; Implicit thread is now fffffa80026ecb50
>
> kd> k
> *** Stack trace for last set context - .thread/.cxr resets it
> Child-SP RetAddr Call Site
> fffff880058cf7c0 fffff800028d90f2 nt!KiSwapContext+0x7a
> fffff880058cf900 fffff800028db90f nt!KiCommitThreadWait+0x1d2
> fffff880058cf990 fffff800028b4b46 nt!KeWaitForSingleObject+0x19f
> fffff880058cfa30 fffff800028d9d2c nt!ExpWaitForResource+0xae
> fffff880058cfaa0 fffff880012dc244 nt!ExAcquireResourceExclusiveLite+0x14f
> fffff880058cfb10 fffff8800124b639 Ntfs!NtfsCommonCleanup+0x2721
> fffff880058cff30 fffff800028cb9b7 Ntfs!NtfsCommonCleanupCallout+0x19
> fffff880058cff60 fffff800028cb978 nt!KxSwitchKernelStackCallout+0x27
> fffff88005839600 fffff800028e0982 nt!KiSwitchKernelStackContinue
> fffff88005839620 fffff8800124b6b2
> nt!KeExpandKernelStackAndCalloutEx+0x2a2
> fffff88005839700 fffff880012e8ba4 Ntfs!NtfsCommonCleanupOnNewStack+0x42
> fffff88005839770 fffff88001180bcf Ntfs!NtfsFsdCleanup+0x144
> fffff880058399e0 fffff8800117f6df
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
> fffff88005839a70 fffff80002bdf2ef fltmgr!FltpDispatch+0xcf
> fffff88005839ad0 fffff80002bcd2e4 nt!IopCloseFile+0x11f
> fffff88005839b60 fffff80002bcd0a1 nt!ObpDecrementHandleCount+0xb4
> fffff88005839be0 fffff80002bcd664 nt!ObpCloseHandleTableEntry+0xb1
> fffff88005839c70 fffff800028d3153 nt!ObpCloseHandle+0x94
> fffff88005839cc0 fffff800028cf710 nt!KiSystemServiceCopyEnd+0x13
> fffff88005839e58 fffff88003542f81 nt!KiServiceLinkage
> fffff8800583a070 fffff88001180067 MYFILTER!PreWrite
> fffff8800583a1b0 fffff88001181329 fltmgr!FltpPerformPreCallbacks+0x2f7
> fffff8800583a2b0 fffff8800117f6c7 fltmgr!FltpPassThrough+0x2d9
> fffff8800583a330 fffff800028b9ebf fltmgr!FltpDispatch+0xb7
> fffff8800583a390 fffff80002917d0b nt!IoSynchronousPageWrite+0x24f
> fffff8800583a410 fffff80002916398 nt!MiFlushSectionInternal+0xb7b
> fffff8800583a650 fffff80002915729 nt!MmFlushSection+0x1f4
> fffff8800583a710 fffff880012c12e7 nt!CcFlushCache+0x5e9
> fffff8800583a810 fffff880012c0aa2 Ntfs!NtfsFlushUserStream+0xb7
> fffff8800583a890 fffff880012bf9af Ntfs!NtfsPerformOptimisticFlush+0x62
> fffff8800583a8e0 fffff880012c041d Ntfs!NtfsCommonFlushBuffers+0x12f
> fffff8800583a9c0 fffff88001180bcf Ntfs!NtfsFsdFlushBuffers+0x10d
> fffff8800583aa30 fffff8800117f6df
> fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
> fffff8800583aac0 fffff80002bdfafb fltmgr!FltpDispatch+0xcf
> fffff8800583ab20 fffff80002b74721 nt!IopSynchronousServiceTail+0xfb
> fffff8800583ab90 fffff800028d3153 nt!NtFlushBuffersFile+0x171
> fffff8800583ac20 0000000077a6176a nt!KiSystemServiceCopyEnd+0x13
> 000000000220e7f8 000000007450b42b ntdll!NtFlushBuffersFile+0xa
> 000000000220e800 00000000744fd18f wow64!whNtFlushBuffersFile+0x33
> 000000000220e840 0000000074fd2776 wow64!Wow64SystemServiceEx+0xd7
> 000000000220f100 00000000744fd286 wow64cpu!ServiceNoTurbo+0x2d
> 000000000220f1c0 00000000744fc69e wow64!RunCpuSimulation+0xa
> 000000000220f210 0000000077a8d447 wow64!Wow64LdrpInitialize+0x42a
> 000000000220f760 0000000077a3c34e ntdll! ?? ::FNODOBFM::string'+0x29134<br>&gt; 000000000220f7d0 00000000`00000000 ntdll!LdrInitializeThunk+0xe
>
> kd> !thread fffffa80026ecb50
> THREAD fffffa80026ecb50 Cid 0d1c.0d80 Teb: 000000007efa1000 Win32Thread:
> 0000000000000000 WAIT: (WrResource) KernelMode Non-Alertable
> fffffa8003650d90 SynchronizationEvent
> IRP List:
> fffffa8002d17c60: (0006,03a0) Flags: 00000404 Mdl: 00000000
> fffffa8003c385f0: (0006,03a0) Flags: 00060043 Mdl: fffff8800583a540
> fffffa8002436c60: (0006,03a0) Flags: 00060000 Mdl: 00000000
>
> kd> !irp fffffa8002d17c60
> Irp is active with 10 stacks 9 is current (= 0xfffffa8002d17f70)
> No Mdl: No System Buffer: Thread fffffa80026ecb50: Irp stack trace.
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> >[12, 0] 0 e0 fffffa8002b46030 fffffa8003a4f2d0
> fffff88001183e40-fffffa80025da770 Success Error Cancel
> \FileSystem\Ntfs fltmgr!FltpPassThroughCompletion
> Args: 00000000 00000000 00000000 00000000
> [12, 0] 0 1 fffffa8002d158b0 fffffa8003a4f2d0 00000000-00000000
> pending
> \FileSystem\FltMgr
> Args: 00000000 00000000 00000000 00000000
> kd> !irp fffffa8003c385f0
> Irp is active with 10 stacks 10 is current (= 0xfffffa8003c38948)
> Mdl=fffff8800583a540: No System Buffer: Thread fffffa80026ecb50: Irp
> stack trace.
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> >[4, 0] 0 1 fffffa8002d158b0 fffffa8002b0c500 00000000-00000000
> pending
> \FileSystem\FltMgr
> Args: 00003000 00000000 00000000 00000000
> kd> !irp fffffa8002436c60
> Irp is active with 10 stacks 10 is current (= 0xfffffa8002436fb8)
> No Mdl: No System Buffer: Thread fffffa80026ecb50: Irp stack trace.
> cmd flg cl Device File Completion-Context
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> [0, 0] 0 0 00000000 00000000 00000000-00000000
>
> Args: 00000000 00000000 00000000 00000000
> >[9, 0] 0 0 fffffa8002b46030 fffffa8002b0c500 00000000-00000000
> \FileSystem\Ntfs
> Args: 00000000 00000000 00000000 00000000
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Thanks.

I guess I’m a little confused then how to fix it. Currently, I use FltCreateFileEx to reopen the file and FltClose is called on that handle.

InitializeObjectAttributes(&toCopyAttr, toCopyFileName, OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);
status = FltCreateFileEx(gFilter.Filter, Instance, &toCopyHandle, &toCopyObj, READ_CONTROL | GENERIC_READ, &toCopyAttr, &iob, 0, FILE_ATTRIBUTE_NORMAL, 0, FILE_OPEN, 0, NULL, 0, 0);

FltClose(toCopyHandle);
ObDereferenceObject(toCopyObj);

So instead of reopening the file, should I just use the FileObject from the callback? Then I wouldn’t have to worry about closing the handle.

Can you elaborate a bit on what operations you do from your preWrite
callback? Is it possible for you to do all those operations when you get an
IRP_MJ_CLEANUP or IRP_MJ_CLOSE if the file has been written to, instead of
doing them on every IRP_MJ_WRITE??

Thanks

On Sat, May 23, 2015 at 8:05 PM, wrote:

> Thanks.
>
> I guess I’m a little confused then how to fix it. Currently, I use
> FltCreateFileEx to reopen the file and FltClose is called on that handle.
>
> InitializeObjectAttributes(&toCopyAttr, toCopyFileName,
> OBJ_CASE_INSENSITIVE | OBJ_KERNEL_HANDLE, NULL, NULL);
> status = FltCreateFileEx(gFilter.Filter, Instance, &toCopyHandle,
> &toCopyObj, READ_CONTROL | GENERIC_READ, &toCopyAttr, &iob, 0,
> FILE_ATTRIBUTE_NORMAL, 0, FILE_OPEN, 0, NULL, 0, 0);
>
> …
>
> FltClose(toCopyHandle);
> ObDereferenceObject(toCopyObj);
>
> So instead of reopening the file, should I just use the FileObject from
> the callback? Then I wouldn’t have to worry about closing the handle.
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Besides the fact that CLOSE can be delayed for a long time, how would a copy from CLEANUP or CLOSE work because the original file has already been overwritten at that point.

Either way, I don’t copy on every write just on the first write that I see for a particular stream and if some other conditions are met. This is a not for a full backup system but meant for very specific purposes so it’s not copying every time. When I use the existing FILE_OBJECT passed to PreWrite (vice opening a new instance myself) it works fine. Back to my original problem though, I don’t understand what lock was being held in the first place that made my code deadlock.

File System Mini-Filter questions are best directed to the NTFSD list… that’s where all the cool file system kids hang out.

Peter
OSR
@OSRDrivers

My mistake. When I first posted at close to 3am, I just wasn’t thinking clearly. Can it be moved or do I need to repost?

Given NTDEV and NTFSD are fundamentally mailing lists, you’ll. have to repost.

Peter
OSR
@OSRDrivers

>NTFS again trying to acquire the same resource exclusively and resulting in a single-thread

deadlock.

IIRC ERESOURCE is safe from this.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

If a thread is holding an ERESOURCE shared and tries to acquire it exclusive
you always get a deadlock.

OP: Grab the file system internals book and read about how paging I/O works:

https://store.osr.com/product/osrs-classic-reprints-windows-nt-file-system-internals/

The memory manager acquires locks in the file system before sending down a
paging I/O. This makes it dangerous to do pretty much anything in the
context of a paging I/O (gross oversimplification, but it’s a good place to
start).

-scott
OSR
@OSRDrivers.

“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…

NTFS again trying to acquire the same resource exclusively and resulting in
a single-thread
deadlock.

IIRC ERESOURCE is safe from this.


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com