Closing file handle in FS Filter

NTFSD
1

Hi, all

In my filter driver, at IRP_MJ_CREATE, I create a
duplicate of the incoming file object and also a handle
to this file object.

At IRP_MJ_CLEANUP, I must close the handle using NtClose.
This leads to issuing new, recursive IRP_MJ_CLEANUP
request that is sent through entire FS filter stack and causing
deadlocks with some filters that are above my filter.

I want to avoid this and want the IRP_MJ_CLEANUP
to be sent only to filters below me. Does anyone know
how to do it ?

L.

2

The ZwClose() will call back through the stack synchronously with the
IRP_MJ_CLEANUP, at times, but I have not encountered any deadlocks with
filters above me. Even the latest NAV doesn’t cause any deadlocks.

As long as you have dropped all of your locks before calling ZwClose() on
the handle, you ‘should’ be ok. Who are you deadlocking with?

Pete

Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ladislav Zezula
Sent: Thursday, November 03, 2005 7:44 AM
To: Windows File Systems Devs Interest List
Subject: [ntfsd] Closing file handle in FS Filter

Hi, all

In my filter driver, at IRP_MJ_CREATE, I create a
duplicate of the incoming file object and also a handle
to this file object.

At IRP_MJ_CLEANUP, I must close the handle using NtClose.
This leads to issuing new, recursive IRP_MJ_CLEANUP
request that is sent through entire FS filter stack and causing
deadlocks with some filters that are above my filter.

I want to avoid this and want the IRP_MJ_CLEANUP
to be sent only to filters below me. Does anyone know
how to do it ?

L.

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

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

3

> As long as you have dropped all of your locks before calling ZwClose() on

the handle, you ‘should’ be ok. Who are you deadlocking with?

It is client from BrightStor ARCServe backup software
from Computer Associates (driver "fsmnt.sys version 2.0.0.74).

From my deeper analysis, I found the exact reason of the
deadlock. I wonder if anyone here confirms what I think.

The fsmnt.sys driver wraps IoCallDriver in IRP_MJ_CLEANUP
handler by KeWaitForSingleObject and KeSetEvent:

// Address fa8232b9
NextIrpSp = IoGetNextStackLocation(Irp); // EAX - NextIrpSp
NextIrpSp->CompletionRoutine = 0xfa823320;
NextIrpSp->Context = Ebp18;
NextIrpSp->Control = 0xE0;
KeWaitForSingleObject(&Event_FA827E48, Executive, KernelMode, FALSE,
NULL);

// Address fa8232da
Status = IoCallDriver(DeviceExtention->LowerDevice,
Irp);

// Address fa8232da
KeSetEvent(&Event_FA827E48, IO_NO_INCREMENT, FALSE);

What if the lower driver NtClose : A new IRP_MJ_CLEANUP
will be sent through the entire driver stack. Because the event
remains not-signalled (reset by KeWaitForSingleObject),
the subsequest call to KeWaitForSingleObject will never return.

Because WinDbg said that the blocked thread waits for event
FA827E48, I wanted to confirm that the memory block
at FA827E48 is really an event:

kd> dt nt!_KEVENT FA827E48
+0x000 Header : _DISPATCHER_HEADER
kd> dt nt!_DISPATCHER_HEADER FA827E48
+0x000 Type : 0x1 ‘’
+0x001 Absolute : 0 ‘’
+0x002 Size : 0x4 ‘’
+0x003 Inserted : 0 ‘’
+0x004 SignalState : 0
+0x008 WaitListHead : _LIST_ENTRY [0x812eba08 - 0x8131de18]

Here is call stack of the deadlocked thread:
(fsmnt is driver from Brightstor, our filter is named MyFilter)

ChildEBP RetAddr Args to Child
fafce6d4 8050017a 812eba08 812eb998 804f99be nt!KiSwapContext+0x2e (FPO:
[Uses EBP] [0,0,4])
fafce6e0 804f99be 8128d198 8128d008 8128e5b4 nt!KiSwapThread+0x46 (FPO:
[0,0,0])
fafce708 fa8232da 00000000 00000000 00000000 nt!KeWaitForSingleObject+0x1c2
(FPO: [Non-Fpo])
WARNING: Stack unwind information not available. Following frames may be
wrong.
fafce730 fa82216a 8128f6e0 8128d008 8128d198 fsmnt+0x72da
fafce7a0 804eddf9 8128f6e0 8128d008 8128d008 fsmnt+0x616a
fafce7b0 80577ade 812e54e8 81309e70 00000001 nt!IopfCallDriver+0x31 (FPO:
[0,0,0])
fafce7e4 805b0c07 8131d020 8128f6e0 00000001 nt!IopCloseFile+0x27c (FPO:
[Non-Fpo])
fafce814 805b055b 8131d020 812e5500 81309e70
nt!ObpDecrementHandleCount+0x119 (FPO: [Non-Fpo])
fafce83c 805b05f9 e1001ce0 812e5500 00000088
nt!ObpCloseHandleTableEntry+0x14d (FPO: [Non-Fpo])
fafce884 805b0731 00000088 00000000 00000000 nt!ObpCloseHandle+0x87 (FPO:
[Non-Fpo])
fafce898 fa8fd28c 00000088 fafcead8 8128ee18 nt!NtClose+0x1d (FPO:
[Non-Fpo])
fafce9e4 fa8fc025 8132b408 8128ec88 fafcead8
MyFilter!MyFilterCommonCleanup+0xdbc
fafcea74 fa8f2a3f 81290370 8128ec88 8128ee18
MyFilter!MyFilterFsdCleanup+0x335
fafceb18 804eddf9 81290370 8128ec88 8128ec88
MyFilter!MyFilterFsdDispatch+0x2ff
fafceb28 fa8232e8 8128f798 812e850c 8128ec88 nt!IopfCallDriver+0x31 (FPO:
[0,0,0])
fafceb3c fa82216a 8128f6e0 8128ec88 8128ee18 fsmnt+0x72e8
fafcebac 804eddf9 8128f6e0 8128ec88 8128ec88 fsmnt+0x616a
fafcebbc 80577ade 812e5580 81309e70 00000001 nt!IopfCallDriver+0x31 (FPO:
[0,0,0])
fafcebf0 805b0c07 8131d020 8128f6e0 00000001 nt!IopCloseFile+0x27c (FPO:
[Non-Fpo])
fafcec20 805b055b 8131d020 812e5598 81309e70
nt!ObpDecrementHandleCount+0x119 (FPO: [Non-Fpo])
fafcec48 805b05f9 e1001ce0 812e5598 00000080
nt!ObpCloseHandleTableEntry+0x14d (FPO: [Non-Fpo])
fafcec90 805b0731 00000080 00000000 00000000 nt!ObpCloseHandle+0x87 (FPO:
[Non-Fpo])
fafceca4 8053c808 00000080 fafced8c 804fd479 nt!NtClose+0x1d (FPO:
[Non-Fpo])
fafceca4 804fd479 00000080 fafced8c 804fd479 nt!KiFastCallEntry+0xf8 (FPO:
[0,0] TrapFrame @ fafcecb0)
fafced20 fa8ea9a6 00000080 e14d8cf8 00000010 nt!ZwClose+0x11 (FPO: [1,0,0])
fafced8c fa8eaa52 00000000 00000000 ff676980
MyFilter!MyFilterVerifyFileExists+0x2c6
fafcedac 805c4a28 00000000 00000000 00000000
MyFilter!MyFilterInitThread+0x42
fafceddc 80540fa2 fa8eaa10 00000000 00000000 nt!PspSystemThreadStartup+0x34
(FPO: [Non-Fpo])
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

Well, I think it’s time to contact Computer Associates’
technical support. BTW, is anyone from CA member of this list ?

L.

4

Ladislav
I didn’t write this driver but I do have some knowledge of it and I have
access to the source code. Could you contact me directly at mark.cook@ca.com
and I will try to help out.

Regards

Mark

“Ladislav Zezula” wrote in message news:xxxxx@ntfsd…
>> As long as you have dropped all of your locks before calling ZwClose() on
>> the handle, you ‘should’ be ok. Who are you deadlocking with?
>
> It is client from BrightStor ARCServe backup software
> from Computer Associates (driver "fsmnt.sys version 2.0.0.74).
>
> From my deeper analysis, I found the exact reason of the
> deadlock. I wonder if anyone here confirms what I think.
>
> The fsmnt.sys driver wraps IoCallDriver in IRP_MJ_CLEANUP
> handler by KeWaitForSingleObject and KeSetEvent:
>
> // Address fa8232b9
> NextIrpSp = IoGetNextStackLocation(Irp); // EAX - NextIrpSp
> NextIrpSp->CompletionRoutine = 0xfa823320;
> NextIrpSp->Context = Ebp18;
> NextIrpSp->Control = 0xE0;
> KeWaitForSingleObject(&Event_FA827E48, Executive, KernelMode, FALSE,
> NULL);
>
> // Address fa8232da
> Status = IoCallDriver(DeviceExtention->LowerDevice,
> Irp);
>
> // Address fa8232da
> KeSetEvent(&Event_FA827E48, IO_NO_INCREMENT, FALSE);
>
> What if the lower driver NtClose : A new IRP_MJ_CLEANUP
> will be sent through the entire driver stack. Because the event
> remains not-signalled (reset by KeWaitForSingleObject),
> the subsequest call to KeWaitForSingleObject will never return.
>
> Because WinDbg said that the blocked thread waits for event
> FA827E48, I wanted to confirm that the memory block
> at FA827E48 is really an event:
>
>
> kd> dt nt!_KEVENT FA827E48
> +0x000 Header : _DISPATCHER_HEADER
> kd> dt nt!_DISPATCHER_HEADER FA827E48
> +0x000 Type : 0x1 ‘’
> +0x001 Absolute : 0 ‘’
> +0x002 Size : 0x4 ‘’
> +0x003 Inserted : 0 ‘’
> +0x004 SignalState : 0
> +0x008 WaitListHead : _LIST_ENTRY [0x812eba08 - 0x8131de18]
>
> Here is call stack of the deadlocked thread:
> (fsmnt is driver from Brightstor, our filter is named MyFilter)
>
> ChildEBP RetAddr Args to Child
> fafce6d4 8050017a 812eba08 812eb998 804f99be nt!KiSwapContext+0x2e (FPO:
> [Uses EBP] [0,0,4])
> fafce6e0 804f99be 8128d198 8128d008 8128e5b4 nt!KiSwapThread+0x46 (FPO:
> [0,0,0])
> fafce708 fa8232da 00000000 00000000 00000000
> nt!KeWaitForSingleObject+0x1c2 (FPO: [Non-Fpo])
> WARNING: Stack unwind information not available. Following frames may be
> wrong.
> fafce730 fa82216a 8128f6e0 8128d008 8128d198 fsmnt+0x72da
> fafce7a0 804eddf9 8128f6e0 8128d008 8128d008 fsmnt+0x616a
> fafce7b0 80577ade 812e54e8 81309e70 00000001 nt!IopfCallDriver+0x31 (FPO:
> [0,0,0])
> fafce7e4 805b0c07 8131d020 8128f6e0 00000001 nt!IopCloseFile+0x27c (FPO:
> [Non-Fpo])
> fafce814 805b055b 8131d020 812e5500 81309e70
> nt!ObpDecrementHandleCount+0x119 (FPO: [Non-Fpo])
> fafce83c 805b05f9 e1001ce0 812e5500 00000088
> nt!ObpCloseHandleTableEntry+0x14d (FPO: [Non-Fpo])
> fafce884 805b0731 00000088 00000000 00000000 nt!ObpCloseHandle+0x87 (FPO:
> [Non-Fpo])
> fafce898 fa8fd28c 00000088 fafcead8 8128ee18 nt!NtClose+0x1d (FPO:
> [Non-Fpo])
> fafce9e4 fa8fc025 8132b408 8128ec88 fafcead8
> MyFilter!MyFilterCommonCleanup+0xdbc
> fafcea74 fa8f2a3f 81290370 8128ec88 8128ee18
> MyFilter!MyFilterFsdCleanup+0x335
> fafceb18 804eddf9 81290370 8128ec88 8128ec88
> MyFilter!MyFilterFsdDispatch+0x2ff
> fafceb28 fa8232e8 8128f798 812e850c 8128ec88 nt!IopfCallDriver+0x31 (FPO:
> [0,0,0])
> fafceb3c fa82216a 8128f6e0 8128ec88 8128ee18 fsmnt+0x72e8
> fafcebac 804eddf9 8128f6e0 8128ec88 8128ec88 fsmnt+0x616a
> fafcebbc 80577ade 812e5580 81309e70 00000001 nt!IopfCallDriver+0x31 (FPO:
> [0,0,0])
> fafcebf0 805b0c07 8131d020 8128f6e0 00000001 nt!IopCloseFile+0x27c (FPO:
> [Non-Fpo])
> fafcec20 805b055b 8131d020 812e5598 81309e70
> nt!ObpDecrementHandleCount+0x119 (FPO: [Non-Fpo])
> fafcec48 805b05f9 e1001ce0 812e5598 00000080
> nt!ObpCloseHandleTableEntry+0x14d (FPO: [Non-Fpo])
> fafcec90 805b0731 00000080 00000000 00000000 nt!ObpCloseHandle+0x87 (FPO:
> [Non-Fpo])
> fafceca4 8053c808 00000080 fafced8c 804fd479 nt!NtClose+0x1d (FPO:
> [Non-Fpo])
> fafceca4 804fd479 00000080 fafced8c 804fd479 nt!KiFastCallEntry+0xf8 (FPO:
> [0,0] TrapFrame @ fafcecb0)
> fafced20 fa8ea9a6 00000080 e14d8cf8 00000010 nt!ZwClose+0x11 (FPO:
> [1,0,0])
> fafced8c fa8eaa52 00000000 00000000 ff676980
> MyFilter!MyFilterVerifyFileExists+0x2c6
> fafcedac 805c4a28 00000000 00000000 00000000
> MyFilter!MyFilterInitThread+0x42
> fafceddc 80540fa2 fa8eaa10 00000000 00000000
> nt!PspSystemThreadStartup+0x34 (FPO: [Non-Fpo])
> 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16
>
> Well, I think it’s time to contact Computer Associates’
> technical support. BTW, is anyone from CA member of this list ?
>
> L.
>
>
>