This is not a problem I need solved, my code handles the situation just fine, but it looks like a cache load glitch and I wanted to describe what I am seeing and get your opinion.
I am filtering cache reads (actually, all IRP_NOCACHE reads), and I've seen a fairly consistent pattern:
- If you read a small data file, say 200 bytes, you get a 4K read at offset 0, which returns the entire contents of the file, and is done
- If you read a file that is 13000 bytes, you get a 16K read at offset 0, and you're done
- For larger data files, in all tests I have run, you get a 32K read @ 0, then a 32K read of the last 8 pages of the file, and then a series of 32K reads to load the rest of the file, except where chunks remain that are less than 32K, which are read in 16K, 8K, or 4K chunks. Often, but not exclusively, from the start of the file to the end. Always page aligned as you would expect.
- Large executables are slightly different, possibly due to the execution of the app forcing reads at different places, so the read is not sequential. But it still begins with reading the first and last 32K, and then performing a series of 32K reads here and there except where a remaining section is less than 32K, etc.
The irregularity I am seeing is that near the end of the load of some executables, the reads are not page aligned. One test app I have consistently loads in the same pattern that includes 9 misaligned reads at the end. The exe is 808K. It loads first and last 32K as always, and then performs 25 other reads here and there to slowly bring the entire exe into cache, mostly 32K reads, other than 3 16K, one 8K, and one 28K read.
That left 2 4K chunks at offsets 220K and 628K, and a 16K chunk at offset 664K, which it could have read with 3 page aligned reads, but instead read as 9 misaligned 4K reads as follows:
217K & 221K - to load the 4K at 220K
625K & 629K - to load the 4K at 628K
661K, 665K, 669K, 673K, and 677K - to load the 16K at 664K
What do you think of this?