Excuse me if this question has been previously addressed. It relates to the role of a File Object (FO)?s SectionObjectPointer and the use and management of the data to which it points.
First some background: I am writing a minifilter driver that implements copy-on-write. The goal (I?m simplifying this) is to maintain the C: drive unchanged. Any changed files are copied to the (say) D: drive and modified and subsequently served from there. This indirection is transparent to users. For example, if C:\JOE has been modified, an open of C:\JOE actually sees the data on D:\JOE and changes affect it, not C:\JOE.
This is implemented with proxy file objects. The minifilter poses as a file system, responding to file requests, and does so by making separate requests down the filter stack. It might handle requests to open and read C:\JOE by opening and reading file D:\JOE. Or C:\JOE. The point here is that the file object presented to the minifilter (the ?user FO?) is not passed down the stack. Instead a ?proxy file object?, created when the minifilter opens C:\JOE or D:\JOE, is passed down the stack to (ultimately) NTFS. [Sorry if you experts have some term other than ?proxy? for this concept.]
The minifilter has its own implementation for context, stream and file control blocks (CCBs, SCBs and FCBs). It does the right thing during file create/open, hooking a new CCB to the provided file object?s FsContext2, a SCB (created if necessary, one per stream common to all its CCBs) to the FO?s FsContext, and a SECTION_OBJECT_POINTERS struct within the SCB to the FO?s SectionObjectPointer.
Next the problem: When the minifilter handles Ping.exe, it does not execute correctly. (I?m sure many other executables are also problematic.) PING 10.1.2.16 runs just fine, showing reply time etc. PING fails with ?could not find host?.
Next some diagnostic information: I have compared the responses returned by the minifilter for Ping.exe with those return by NTFS when the minifilter is disabled. They are identical. The same Opens, Cleanups, Closes, Reads, Query Infos, and Query Security calls all return the same results. I have extensive tracing to show this and I have run ProcMonitor to confirm it. I have run Ping in user mode under WinDbg both with and without the minifilter and compared the disassembled text. It is identical.
Next the crux: Recall that I said the minifilter sets the FO?s SectionObjectPointer to a (initially null filled) SECTION_OBJECT_POINTER struct within a minifilter SCB. If instead of doing that the minifilter sets the User FO?s SectionObjectPointer to the proxy FO?s SectionObjectPointer (that is, a pointer returned by NTFS) then Ping works just fine. So: UserFO->SOP == proxyFO->SOP => happiness. UserFO->SOP == &SCB->SOP_struct => misery.
Finally the questions: What?s wrong with a minifilter stream having its own SOP struct? It is an abstract stream so why shouldn?t it have its own data section, control section and shared cache map? Shouldn?t Windows simply construct them as needed. Shouldn?t they just work? What ?secret sauce? does the NTFS SOP struct contain that the minifilter SOP doesn?t have?
) testing on it with driver verifier might find interesting problems. I’m bringing this up because it would detect this problem (not implementing name providers in a context where they are actually not optional).