FltUnregisterFilter->NtfsDecodeFileObject->Boom

I’m getting a BSOD in my isolation filter during FltUnregisterFilter. Most of the stacks have been pretty consistent with the crash occurring in NtfsDecodeFileObject. I know what a crash there means when the filter is running however I’m unsure about why that’s happening once FltUnregisterFilter is called. Is this just a reference counting issue thats causing a FILE_OBJECT to stick around longer than it should or something else?

I can post stacks or analyze -v output as this is 100% reproducible but I figured the file system gurus might have some ideas to look at before getting too deep into debug output.

Correct, you have taken ownership of a file object and it has not been
closed. Later when it is closed, or whatever the next request is for it,
NTFS doesn’t like it.

It can definitely be tricky to unload a layered FS. What I’ve done, for
debug builds only and not for a release driver, is when you get the
unload callback, check a list you maintain of your Fcbs. Purge the SOP
if it is there, being careful since it can be issued a close request
inline to the purge. Then return do_not_unload … and then try again to
unload, doing the same again. As long as there are no actively open
files, eventually you’ll get to an empty list and can unload.

Pete


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

------ Original Message ------
From: xxxxx@gmail.com
To: “Windows File Systems Devs Interest List”
Sent: 9/6/2017 5:10:59 PM
Subject: [ntfsd] FltUnregisterFilter->NtfsDecodeFileObject->Boom

>I’m getting a BSOD in my isolation filter during FltUnregisterFilter.
>Most of the stacks have been pretty consistent with the crash occurring
>in NtfsDecodeFileObject. I know what a crash there means when the
>filter is running however I’m unsure about why that’s happening once
>FltUnregisterFilter is called. Is this just a reference counting issue
>thats causing a FILE_OBJECT to stick around longer than it should or
>something else?
>
>I can post stacks or analyze -v output as this is 100% reproducible but
>I figured the file system gurus might have some ideas to look at before
>getting too deep into debug output.
>
>—
>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:>