Any filter which takes ownership of the FO should not be allowed to
unload.
If you have a ref counting issue, verifier may not pick up the problem.
You would free the memory and later it would be accessed by some other
component, verifier will not pick this up other than when the invalid
buffer is accessed and a BSOD follows.
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: 3/21/2017 12:16:03 PM Subject: RE:[ntfsd] Isolation filter related crash
>
>The offending address is not found with !verifier 80 > >
>The FsContext is pointing to invalid memory. That too is not found >with !verifier 80. The FsContext2 does point to valid memory but it >looks like it’s was already reallocated by something else. > >
>Upper > >
>Another file on the same volume > >I haven’t been able to recreate this crash and again it doesn’t make a >lot of sense to me about how it’s happening. I was thinking that I >might have an issue with reference counting but I would assume verifier >would pick that up. > >Related to that, and your point about the forced teardown made me think >of it, should an isolation filter be allowed to unload? Because if an >app opens a file and a SFO is created but then the driver is unloaded >and FLTMGR forces an unload, as soon as that app does any operation on >that outstanding FO, it’ll BSOD with the NtfsDecode error. Or will the >driver not unload until all FOs are closed (which can take a long >time). > > >— >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:>
> Related to that, and your point about the forced teardown made me think of
it, should an isolation filter be allowed to unload?
It can only do so it is no longer managing upper file objects. In practice
these days means “never unless you are only attached to a very boring
volume”. So once I was relatively sure that I had no egregious pool leaks
I’d rip the unload code out. Certainly from release builds.
As for your problem I’m relatively convinced that you have a refcounting
issue with UpperFDileObject->FsContext.
I still haven’t been able to recreate the crash but I did a pretty thorough review the past few days and found a few areas that were not handled properly which may have contributed to it (SL_OPEN_TARGET_DIR and the situation described here http://www.osronline.com/ShowThread.cfm?link=162127). So with the changes, I’m back to square one until I get another crash. However, through my testing, I did find cases where certain directories are not being closed. So again, probably a ref count issue but I’m having trouble figuring out where and why it only happens occasionally. The same folder can be opened multiple times with the same options and access and share requests but some just stick around. After trying to unload, I get the Verifier warning.
1: kd> !fltkd.filter FFFFE00091C903D0 8 1
FLT_FILTER: ffffe00091c903d0 “141300”
InstanceList : (ffffe00091c90438)
Resource (ffffe00091c904a0) List [ffffe00091c904a0-ffffe00091c904a0] rCount=0
Object usage/reference information:
References to FLT_CONTEXT : 0
Allocations of FLT_CALLBACK_DATA : 0
Allocations of FLT_DEFERRED_IO_WORKITEM : 0
Allocations of FLT_GENERIC_WORKITEM : 0
References to FLT_FILE_NAME_INFORMATION : 0
Open files : 4
References to FLT_OBJECT : 0
List of objects used/referenced::
FLT_VERIFIER_OBJECT: ffffe000915e91b0
Object: ffffe0008f616450 Type: FILE_OBJECT RefCount: 00000001
FLT_VERIFIER_OBJECT: ffffe0008f8c9b30
Object: ffffe0008f86d520 Type: FILE_OBJECT RefCount: 00000001
FLT_VERIFIER_OBJECT: ffffe00091256a40
Object: ffffe0009176f340 Type: FILE_OBJECT RefCount: 00000001
FLT_VERIFIER_OBJECT: ffffe00091de6bb0
Object: ffffe00091acf420 Type: FILE_OBJECT RefCount: 00000001