Hey!
So generally memory mapped files writes mark the PTE dirty , PFN modified so the lazy writer thread writes those pages back to storage
this can be filtered by the acquire for mod write callback
what if a program calls FlushViewOfFile explicitly?
Disk I/O still initiated by lazy writer ? or another thread from the caller’s process context ?
After some debugging , can tell in case of a call to FlushViewOfFile/ZwFlushVirtualMemory the write irp is initiated from the caller’s process
1 Like
That seems like it should be true, and seems unlikely to change, but I'm not sure I would rely on it.
It also goes without saying that FlushViewOfFile can be called from multiple threads concurrently. And in parallel with further modifications to the memory itself (marking the page as dirty) from multiple other threads within the process or calls to WriteProcessMemory from other processes. In general those things shouldn't be done, but lots of programs do some daft things
whilst on the topic of mapped I/O -> I'm trying to filter IRP_MJ_ACQUIRE/RELEASE_FOR_MOD_WRITE but the callbacks are not triggered at all for some reason...
in Procmon I can see fastio acquires / releases for mod write are happening , which , despite being fasio - should get the callbacks invoked by the fltmgr ...?
Yes, these certainly work (I just confirmed on Win11 23H2). Are you sure there's actually MPW activity?