filter unload bugcheck for FILE_OBJECT structure leak

NTFSD
1

Hi all,
I am reposting because yesterday my topic did not post correctly.

In my minfilter I have a design which reparses some specific files. I attach the source file handle to reparsed file IRPs through ECP and stream handle context. I need that handle to perform noncached IO on the reparsed file so I need to keep it up until the file is in action.

between IRP_MJ_CLOSE and IRP_MJ_CLEANUP I chose IRP_MJ_CLOSE to close the handle.

The issue is when I unload filter manually it bug checks for leaked file_objects.
It seam obvious to me. I even tested commenting read/write IRP and closing handles immediately. It removed all leaked file_objects.

The questions is, If you approve of closing file handles in IRP_MJ_CLOSE?

2

> The questions is, If you approve of closing file handles in IRP_MJ_CLOSE?

Depending on your architecture you are asking for a world of grief with
sharing violations and oddness with deletions but you can make it work if
you keep on hitting it.

But that’s not your problem, IIUC your problem is that you are tearing down
your handle in the wrong place, or rather you are not arranging for it to be
town down when the streamhandlecontext (assuming that’s where you keep the
handle) is torn down. This tear down will happen just after close
processing (opening a small window) and it will also happen when the filter
is detached (which is why you get the leak in unload).

When handling the close in context tear down you need to be aware that you
can be called at elevated IRQL and deal with that defensively. Also you may
need to work to get into the correct process for the close.

FWIW I would be inclined to do the work where you are doing it down *and* in
context tear down. Use an interlocked exchange to get the handle and close
it (or post-and-close) if its non null.

3

In general, handling the handle as the OS does, cleaning it up in the
cleanup request, allows for a clean solution. As Rod pointed out,
keeping the handle around until close processing is going to introduce a
handful of sharing problems, which can be solved but just more issues.
That said, there are some designs, such as some layered FSs, which make
it very difficult to support unload processing and sometimes it is best
to disable unloading of your filter.

Pete

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

------ Original Message ------
From: xxxxx@yahoo.com
To: “Windows File Systems Devs Interest List”
Sent: 4/20/2017 12:05:05 AM
Subject: [ntfsd] filter unload bugcheck for FILE_OBJECT structure leak

>Hi all,
>I am reposting because yesterday my topic did not post correctly.
>
>In my minfilter I have a design which reparses some specific files. I
>attach the source file handle to reparsed file IRPs through ECP and
>stream handle context. I need that handle to perform noncached IO on
>the reparsed file so I need to keep it up until the file is in action.
>
>between IRP_MJ_CLOSE and IRP_MJ_CLEANUP I chose IRP_MJ_CLOSE to close
>the handle.
>
>The issue is when I unload filter manually it bug checks for leaked
>file_objects.
>It seam obvious to me. I even tested commenting read/write IRP and
>closing handles immediately. It removed all leaked file_objects.
>
>The questions is, If you approve of closing file handles in
>IRP_MJ_CLOSE?
>
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>

4

Thanks for the useful information.

I will implement handle closing on context tear down and see how it works.

Thanks a lot.