Message 2 of 2
06 Sep 17 19:40
Join Date: 17 Feb 2012
Posts To This List: 684
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.
Windows File System and Device Driver Consulting
------ Original Message ------
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
>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
<...excess quoted lines suppressed...>