I am writing a sample file system driver, I need to identify when a file is getting mapped and unmapped. When a file is mapped, memory manager creates a section object of which file system is not aware of. But, access to the mapped memory results in a page fault. So, read request comes to a file system driver.
Here, in IRP_MJ_READ path, Can I check for DataSectionObject and ImageSectionObject in SECTION_OBJECT_POINTERS for NONULL values, to conclude file is mapped ?
In the IRP_MJ_CLOSE path, if DataSectionObject or ImageSectionObject are NULL, can I conclude the file has been unmapped ?
I ran notepad but observed that, IRP_MJ_CLOSE for file object which mapped the file never got called, even on shutdown. Does memory manager release its reference on file object only if memory becomes low and need to purge some ? Before releasing the reference, does memory manager NULL out DataSectionObject and ImageSectionObject ?
I’m not certain if this will solve all of your problems, but for file objects created while your filter is running, you can be notified of section object creation by filtering they pseudo-IRP IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION watching for SyncType==SyncTypeCreateSection.
I am writing a sample file system not a file system filter. FsRtlRegisterFileSystemFilterCallbacks can be called from only file system filter. I cant use FsRtlRegisterFileSystemFilterCallbacks .
Any suggestions and explanations will be highly appreciated
I am writing a sample file system not a file system filter. FsRtlRegisterFileSystemFilterCallbacks can be called from only file system filter. I cant use FsRtlRegisterFileSystemFilterCallbacks .
Any suggestions and explanations will be highly appreciated
But in your fast IO dispatch table you setup callbacks to be made when
sections are initialized.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting www.KernelDrivers.com
866.263.9295
> I am writing a sample file system not a file system filter.
FsRtlRegisterFileSystemFilterCallbacks can be called
from only file system filter. I cant use
FsRtlRegisterFileSystemFilterCallbacks .
You can (check recent FAT sources)
Indeed I’d say that would be well advised to do so. You can get away with
doing it the old way, but you get more information by doing it this way.
ISTR that there are other good reasons to do this…
You have AcquireFileForNtCreateSection(sp?) &c in your fastio dispatch - see
“Life in the fast lane” http://www.osronline.com/article.cfm?id=166 and
consult fastat - good luck!
wrote in message news:xxxxx@ntfsd… >I am writing a sample file system driver, I need to identify when a file is >getting mapped and unmapped. When a file is mapped, memory manager creates >a section object of which file system is not aware of. But, access to the >mapped memory results in a page fault. So, read request comes to a file >system driver. > Here, in IRP_MJ_READ path, Can I check for DataSectionObject and > ImageSectionObject in SECTION_OBJECT_POINTERS for NONULL values, to > conclude file is mapped ? > In the IRP_MJ_CLOSE path, if DataSectionObject or ImageSectionObject are > NULL, can I conclude the file has been unmapped ? > > I ran notepad but observed that, IRP_MJ_CLOSE for file object which mapped > the file never got called, even on shutdown. Does memory manager release > its reference on file object only if memory becomes low and need to purge > some ? Before releasing the reference, does memory manager NULL out > DataSectionObject and ImageSectionObject ? >
Actually, it may be better to use
FsRtlRegisterFileSystemFilterCallbacks.
Ignore the name - this call CAN (and is) used by file systems, as it
provides greater control than the fast I/O entry point (the fast I/O
entry point is VOID and poorly specified.)
The Memory Manager will only create a single “data section object”
(which is really a control area these days) per section object pointers
structure. Thus, when someone calls NtCreateSection (or one of the
variants of this) to create a data section, they either get back a
pointer to the existing data section or a new one is created.
If a new one is to be created, the memory manager must lock down the
file object for the duration of the creation - otherwise, the state of
the file (notably it’s sizes) might change while the section is itself
being set up (it was the discovery of this race condition/timing windows
that ultimately led to creation of the fast I/O entry point, in fact.)
This is why you observe the fast I/O callback or the filter callback -
they are triggered when the memory manager locks down the file while it
sets up the section.
You can also use MmDoesFileHaveUserWriteableReferences (to determine if
the file is mapped writeable,) CcIsFileCached (to determine if the file
is mapped by the cache manager,) and CcPurgeCacheSection (which fails if
the file is memory mapped as a data section.) But the presence of
values in the SectionObjectPointers structure really isn’t sufficient to
determine if the file is memory mapped by a user.
Note: CcPurgeCacheSection is ONLY safe for the owner of the file object
to use (normally the file system.) It is NEVER safe for a filter to
invoke this function, no matter that it will work “most of the time”.
It would be unusual for the memory manager to never release its
reference on a file, but it is always possible. Normally, it will go
away as a result of memory pressure; I seriously doubt that it is
forcibly discarded during shutdown (dirty pages are written back
however.) But, I must admit I’m often mystified at the shutdown process
in Windows these days (I’ve waited as long as 12 hours for my Win 7 box
to shutdown while it warns me about the dire consequences of powering
off prematurely. I view it as being my own personal manifestation of
the halting problem.)
I ran notepad but observed that, IRP_MJ_CLOSE for file object which mapped the
file never got called, even on shutdown. Does memory manager release its
reference on file object only if memory becomes low and need to purge some ?
Before releasing the reference, does memory manager NULL out DataSectionObject
and ImageSectionObject ?
When I tried unmounting the filesystem rather shutting the system down, IRP_MJ_CLOSE got triggered.
_SECTION_OBJECT_POINTERS before calling CcPurgeCacheSection
I observed that CcPurgeCacheSection causes close to be called to release memory manager reference on the fileobject. It NULL out the DataSectionObject pointer. Can someone help me understanding how CcPurgeCacheSection works ?
One more question, is there any way to decide whether a paging IO is generated by Memory manager or cache manager ? Any guidelines regarding the same ?
“You can also use MmDoesFileHaveUserWriteableReferences…”
MmDoesFileHaveUserWriteableReferences? Wow - this seems awfully useful. Are there any MSFT lurkers on the list who can provide additional information on this API?
I’m not an MSFT lurker, but I’ll tell you that this API is not available on Windows XP and Server 03 which significantly limits its usefulness. And that the function name is actually MmDoesFileHaveUserWritableReferences