How correct close file with mapped section on it ?

_Yy_

i try implement basic support for cache on file.
but unclear how correct process IRP_MJ_CLEANUP / IRP_MJ_CLOSE - how uninitialize cache

if i not create section on file, but only write to, read from file - all until look like ok.
i view both cached I/O and than non cached paged I/O.
after i close (last) file handle - driver receive both IRP_MJ_CLEANUP / IRP_MJ_CLOSE and all ok. file references reached 0

but in case i create and map section on file - file reference count never reach 0

basically i do from user mode :

NtOpenFile(&hFile, FILE_ALL_ACCESS, ..., FILE_SYNCHRONOUS_IO_NONALERT);
NtCreateSection(&hSection, SECTION_ALL_ACCESS, 0, 0, PAGE_READWRITE, SEC_COMMIT, hFile);
NtClose(hFile);
ZwMapViewOfSection(hSection, ... PAGE_READWRITE);
NtClose(hSection);
ZwUnmapViewOfSection(NtCurrentProcess(), BaseAddress);

section created and mapped ok. i can read data from view - driver receive IRP_NOCACHE|IRP_PAGING_IO requests .
but after ZwUnmapViewOfSection - i not got any notification in driver. and cache manager still hold several references to my file.
because i not got notification on last ZwUnmapViewOfSection i can not call say CcPurgeCacheSection/CcUninitializeCacheMap or something else

how correct handle this situation ?

rod_widdowson

how correct handle this situation ?

I'm not seeing you close the section, but I'd not stress if it doesn't go away immediately. Mm and Cc and subtle and can hang on to file objects long after you think you are do with them. Applying memory pressure to the system is a good way of forcing things along. You could even IRP_MJ_FLUSH_BUFFERS / IRP_MN_FLUSH_AND_PURGE

_Yy_

@rod_widdowson said:

how correct handle this situation ?

I'm not seeing you close the section

NtOpenFile(&hFile, FILE_ALL_ACCESS, ..., FILE_SYNCHRONOUS_IO_NONALERT);
NtCreateSection(&hSection, SECTION_ALL_ACCESS, 0, 0, PAGE_READWRITE, SEC_COMMIT, hFile);
NtClose(hFile);
ZwMapViewOfSection(hSection, ... PAGE_READWRITE);
NtClose(hSection); // <---------------------- here
ZwUnmapViewOfSection(NtCurrentProcess(), BaseAddress);

i close section just after i map it - all calls return STATUS_SUCCESS ( i execute this code under debugger)

question - are possible get notification in driver, immediately after last view on file was closed - when no more handles, sections or views on file exist. and i can not send IRP_MJ_FLUSH_BUFFERS ( ZwFlushBuffersFile )or any else - because i already have no handle to file or pointer to file object - only cc manager have pointers. may be i not register some callback for this or do something wrong..

rod_widdowson

are possible get notification in driver, immediately after last view on file was closed - when no more handles, sections or views on file exist.

Not at the file system level (and I don't think so at the Mm level).

Why do you need to know? I think this is the critical question. If you just want to know that your driver is working you can run experiments to try to get Mm to drop the FO, but if you need to know because of some functional requirement you are probably short of luck.

i already have no handle to file or pointer to file object

You'd need to open one (or just postpone the close of hFile until after you unmap and close the section). That would do for a "test all is working" situation.

_Yy_

You'd need to open one

i not write the file system driver. file system have except general FILE_OBJECT, another named "files" . so we can open the same file system file (by name or unique id) multiple times. so the FileObject1 != FileObject2 but FileObject1->FsContext == FileObject2->FsContext

in my case every FILE_OBJECT is unique. it can not be reopened after close.

or just postpone the close of hFile until after you unmap and close the section

i of course can do this in test code. but really not my code will be use files on my device, so i can not force client not close file handle before unmap section

Why do you need to know?

simply interesting. i think i do some wrong if not all memory and objects cleanup after usage

and you correct - if i move NtClose(hFile); after ZwUnmapViewOfSection(NtCurrentProcess(), BaseAddress); all become ok.

but driver must correct handle any correct user mode code. and it is legal close file handle just after section is created and we not need m

_Yy_

actual minimal test code is - https://pastebin.com/V1GpjPUv

if i move NtClose(hFile); after ZwUnmapViewOfSection(NtCurrentProcess(), BaseAddress); all become ok.

https://pastebin.com/PrrVzfW4

Scott_Noone_(OSR)

The Memory Manager will make the reference to the section go away when it feels like it. Try using RAMMap to empty all the working sets and standby lists. You should see the IRP_MJ_CLOSE arrive then:

https://docs.microsoft.com/en-us/sysinternals/downloads/rammap

Though note that it's not the job of the FS to try and force sections closed arbitrarily. Let the Cc/Mm do their caching and only try to purge/force if necessary (e.g. on dismount, delete, etc.)