I am making a mini-filter driver and I would to improve its performance.
Right now I need to scan the contents of any file for exactly 3 IRPs:
IRP_MJ_CREATE (on PostCallback)
IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION (on PreCallback)
IRP_MJ_CLEANUP (on PostCallback)
To scan the files I have thought about 2 approaches:
Use FltObjects->Instance, FltObjects->FileObject (FltObjects is received as parameter to the callback) and passing those directly to FltReadFile;
calling FltCreateFile on the filename (after obtaining it), ObReferenceObjectByHandle to obtain a new object, and passing FltObjects->Instance, newFileObject to FltReadFile.
I find the first approach much faster, and I would like to use it on the 3 cases, but I fear it might not be that “safe”.
Do you see a problem using any of these 2 approaches?
For which IRPs or other conditions (if any) do you think it would be “safer” to use the 2nd approach at the expense of more processing?
So many people in this list, including people from Microsoft, and know one is able to answer?
Actually, I am asking this because I suspect that the calling of “FltReadFile” in my mini-filter driver is causing - not memory leaks because I have already tested it with verifier and pooltag but - placing a lot of “pressure” on the memory when a standalone file scanning tool scans the whole hard disk…
In some situations I was able to see “available physical memory” on TaskManager under XP (SP2 by the way) dropping like 10s of MBs in just couples of seconds… I was somewhat able to contain the situation by forcing unbuffered reads (by inspecting the volume’s sector size and adjusting both offset and length parameters) and, more recently, tried forcing paging reads (by passing FLTFL_IO_OPERATION_PAGING). After this change, physical memory availability was much much more stable.
However, sometimes, and I don’t know yet exactly how to reproduce it, “available physical memory” dropped in 10s of MBs. We are speaking here of a mini-filter running on a VMWare with 512MB of RAM and 768 up to 1536MB of virtual memory. Although I don’t know exactly how to reproduce this phenomenon, I have a feeling that if the driver isn’t running the problem won’t happen at all.
The fact that you have burst memory usage in your driver, but no leaks
is certainly not unusual or surprising.
Since the “problem” is alleviated when you do non-cached reads, it would
suggest that the file system data cache is doing its job - likely via
read ahead as well as keeping track of the data content that you’ve
already read. This seems to be reasonable, since keeping physical
memory “available” isn’t really that important to performance.
So, my question back to you would be: why do you think this isn’t
working as it should be? What do you think you should be seeing? To me
it sounds like reasonable behavior given what you describe doing, so I’m
trying to figure out what it is you think is broken here.
Actually I was thinking whether that would be normal or not, so I was checking around with the experts here
As you have mentioned, I have also noticed that the system data cache increased approximately proportionally to the decrease in available physical memory. After the available physical memory decreased to a minimum low, I observed it being restored progressively at about the same speed.
Actually, using non-cached and non-paging reads helped me keeping the amount of available physical memory more stable. Not that, as you said, means something would be broken, but when I picked this problem the first time, I started by analyzing a crash report about ntkrnlpa.exe not finding available pages.
