I currently have a filter driver implementing a shadow file object model that I wrote a while. Primarily I use it for redirection and logging for certain .exe and .dll files (endpoint security).
Basically most of the driver is a pass through, and in IRP_MJ_CLEANUP I use MmFlushImageSection and CcPurgeCacheSection. This implementation follows what I saw in FAT and another OSR thread that had a similar issue (though I don’t remember the title off-hand). My ultimate goal is that once a user application closes the final handle to a process I can clean up all the FILE_OBJECTs at that point and decide whether to still allow access to the file, so I reference count the files and flush once no one’s touching them.
My issue at the moment is that for some cases, depending on what is done with the file (I haven’t RE’d the specific file to see what it’s doing), the memory manager is holding on to a reference to one of the FILE_OBJECTs I’m touching.
After some analysis I found that my file objects will always eventually (on the order of minutes) receive the missing IRP_MJ_CLOSE from MiDereferenceSegmentThread->MiSegmentDelete.
Am I just missing a function call to get Mm to let go of the other FILE_OBJECT? Looking at the function it looks like MiDereferenceSegmentThread is just looping on a couple events but I didn’t see any quick indication of what causes them to get set.
> After some analysis I found that my file objects will always eventually
(on the order of minutes) receive the missing
IRP_MJ_CLOSE from MiDereferenceSegmentThread->MiSegmentDelete.
This is just what you’d expect if an application had mapped a section to the
file and then closed the handle. The file object is going to hang on until
the SECTION handle is closed.
That’s what I assumed it was, since it’s only happening under certain conditions with DLL files. But similarly handles are held open until MmFlushImageSection and CcPurgeCacheSection are called as well. So that brings me back to my original question - is there a way to tell the OS to close the section object sooner? In this scenario everything is already unmapped from the process and no one is touching the file anymore.
wrote in message news:xxxxx@ntfsd… > That’s what I assumed it was, since it’s only happening under certain conditions with DLL files. But similarly handles are held open until MmFlushImageSection and CcPurgeCacheSection are called as well. So that brings me back to my original question - is there a way to tell the OS to close the section object sooner? In this scenario everything is already unmapped from the process and no one is touching the file anymore. >
MmForceSectionClosed is the biggest hammer possible. It won’t make existing
references go away, but it will make the section go away once the reference
counts go to zero.
What is the output of !ca on the image section object?
wrote in message news:xxxxx@ntfsd… > That’s what I assumed it was, since it’s only happening under certain > conditions with DLL files. But similarly handles are held open until > MmFlushImageSection and CcPurgeCacheSection are called as well. So that > brings me back to my original question - is there a way to tell the OS to > close the section object sooner? In this scenario everything is already > unmapped from the process and no one is touching the file anymore. >