Process Monitor : Help on IRP_MJ_READ Process Name!

pinscomputer wrote:   I am also guessing you were able to see a growing "hard" fault count for the process during this period since it had to go to disk to re-acquire the data?

 

 

that point was meant more as a check for your assessment that the file is no longer in cache.

 

unless I misunderstood how the memory manager is supposed to work.... "soft" page faults will likely be occurring often as they are generated when data is read from the standby or modified page lists.... cache...

 

however, the "hard" faults should happen if the memory manager recognizes that the data that was in standby page list now needs to be read from the disk (pagefile).

 

russinovich references using procmon to see pagefile access.  referring to the same video, timestamp 1 hour 4 minutes 30 seconds.

 

maybe you can set procmon to filter on reads of the MKTLST when it occurs from the pagefile....just as a final confirmation that the file is no longer in cache.

 

 

 

I looked at the screen-shot of the trace....

given the filters you have set on procmon... it makes the results of the trace appear like someone flipped a switch on the server.....and the fastio reads stopped....

 

have you considered removing all of the filters that are currently set on that procmon trace

.... and I know this won't be the most pleasant exercise

... but look at more of the detailed activity that occurs between the last Fastio and the first IRP read?  

... then gradually apply filters to remove some of the noise in that section of the capture?  Maybe this will reveal the culprit causing the presumed transition of the file from cache to disk.

 

 

one additional question to make sure I haven't misunderstood ... this is ONE SINGLE FILE 8MB in size that gets read over and over again... just different pieces of data are pulled from the file during each read operation...

 

is there any process that tries to make changes to MKTLIST.BIN file?