FltCreateSectionForDataScan causes pagefault across IRPs

Hi,

I am trying to use FltCreateSectionForDataScan to open a read only view of the section and send it to user mode for scan. This is done in post create and seems to work fine. Once I am done with the scan I close section handle, section object, and call FltCloseSectionForDataScan.

In the next post create on the same file when FltCreateSectionForDataScan is called a page fault occurs in CcZeroEndOfLastPage. Form what I can tell the FILE_OBJECT seems to be valid but still is causing the page fault. I am also blocking any other access when I have the section open in IRP_MJ_ACQUIRE_FOR_SECTION_SYNCHRONIZATION and IRP_MJ_RELEASE_FOR_SECTION_SYNCHRONIZATION. I am assuming something with the existing FILE_OBJECT has invalid state but I am unsure how to debug this further.

For testing I tried to reopen the same FILE_OBJECT in the same IRP after I close it and this works fine but when I try to open it again in another IRP this is when the page fault occurs. I usually reopen the section when there was an error processing it and I fail the post create. The only differences I see is that FsContext2 and Private Cache Map seem to be different but since I am not setting these I am confused how this would be causing problems. I also have trying to look at the IRPS in process monitor or !fileObj. In both cases the FILE_OBJECT looks valid to me.

This is the file object when opening the section succeeds

kd> !fileObj 0xffffb98cac224620

\myFile.txt

Device Object: 0xffffb98cac0e58f0   \Driver\volmgr
Vpb: 0xffffb98cac07fbd0
Access: Read SharedRead SharedWrite 

Flags:  0x80042
	Synchronous IO
	Cache Supported
	Fast IO Read

FsContext: 0xffff9286668837d0	FsContext2: 0xffff928666883a50
Private Cache Map: 0xffffb98cad9eba70
CurrentByteOffset: 0
Cache Data:
  Section Object Pointers: ffffb98cae664a78
  Shared Cache Map: ffffb98cad9eb8f0         File Offset: 0 in VACB number 0
  Vacb: ffffb98ca5807740
  Your data is at: ffffa48853e00000

This is opening the section when it page faults

kd> !fileObj 0xffffb50f8aa45d90

\myFile.txt

Device Object: 0xffffb50f851220a0   \Driver\volmgr
Vpb: 0xffffb50f850a75e0
Access: Read SharedRead SharedWrite 

Flags:  0x80042
	Synchronous IO
	Cache Supported
	Fast IO Read

FsContext: 0xffffa387fa630980	FsContext2: 0xffffa387facaf6c0
Private Cache Map: 0xffffb50f8553c760
CurrentByteOffset: 0
Cache Data:
  Section Object Pointers: ffffb50f8a935818
  Shared Cache Map: ffffb50f88a1dd20         File Offset: 0 in VACB number 0
  Vacb: ffffb50f7e8161a0
  Your data is at: ffffda8cfee00000
00 ffffac8b`0b0dcc98 fffff802`7472eeb2     nt!DbgBreakPointWithStatus
01 ffffac8b`0b0dcca0 fffff802`7472e3dc     nt!KiBugCheckDebugBreak+0x12
02 ffffac8b`0b0dcd00 fffff802`746788e7     nt!KeBugCheck2+0xb2c
03 ffffac8b`0b0dd490 fffff802`7484abe9     nt!KeBugCheckEx+0x107
04 ffffac8b`0b0dd4d0 fffff802`74849c3c     nt!KiBugCheckDispatch+0x69
05 ffffac8b`0b0dd610 fffff802`74840202     nt!KiSystemServiceHandler+0x7c
06 ffffac8b`0b0dd650 fffff802`745527e2     nt!RtlpExecuteHandlerForException+0x12
07 ffffac8b`0b0dd680 fffff802`74553949     nt!RtlDispatchException+0x2d2
08 ffffac8b`0b0ddde0 fffff802`7484ad45     nt!KiDispatchException+0xac9
09 ffffac8b`0b0de4f0 fffff802`74845e82     nt!KiExceptionDispatch+0x145
0a ffffac8b`0b0de6d0 fffff802`744abd1d     nt!KiPageFault+0x442
0b ffffac8b`0b0de860 fffff802`745314c6     nt!CcZeroEndOfLastPage+0x49
0c ffffac8b`0b0de8c0 fffff802`05b3f3f4     nt!FsRtlCreateSectionForDataScan+0x146
0d ffffac8b`0b0de970 fffff802`05b57142     FLTMGR!FltCreateSectionForDataScan+0x194
0e ffffac8b`0b0de9e0 fffff808`24aa8d73     FLTMGR!FltvCreateSectionForDataScan+0xd2

I was able to figure this out. It seems that this only occurs after another read. In my case I was trying to read the first 12 bytes of the file to see if it matched our header before mapping the file for scan. In this case the file was read and the cache manager was not in a consistent state on the second read. I was able to fix this by flushing buffers and the cache to make sure we did impact the cache when performing the header read.

I am now calling FltFlushBuffers and CcPurgeCacheSection before I close the view.