I’ve been missing IRPs for my file because FltGetXyzContext() is saying one doesn’t exist (file, stream, and stream handle) for IRPs that are clearly associated with my file. Specifically, the initial FS/CACHE information grab triggered by the first IRP_MJ_CREATE, and late cache writes show the file and stream contexts, but no stream handle contexts. (I’ve attached an image of the initial create. The darker rows are the ones that have no contexts. At the end they say Supported, which tells me that FltSupportsXyzContext() says yes, but the get context functions didn’t return anything.)
I’m sure this is normal behavior, but I want to confirm that, and to understand what is happening and figure out a way to deal with it. I am after the red row, the cache reads and writes. I would hate to have to process every one of those to try to associate an existing file context with it.
I assume the file system and/or cache are creating their own file object/handle for the cache manager, and it has not yet been associated with my file and stream contexts, and since I never see a IRP_MJ_CREATE for it, I will never attach a stream handle context to it.
Back in the day (XP and indeed earlier) this was certainly something that happened quite a lot, I haven’t seen that occur recently, but that could be because I have stopped looking for it.
I assume that you are boot time started and attached. If the MJ_CREATE happened before you got there all bets would be off of course.
Can’t see your attachment but if I were to guess, you are trying to get a stream handle context against a file object, as you pointed out, that the underlying file system created to initialize caching on the file. Hence you would not see the create for these file objects, etc. You can confirm this by checking the fileobject->Flags and look for the FO_STREAM_FILE flag.
That said, you mention cached IO where you are not able to get a stream handle context. As Rod pointed out, maybe you are somehow missing the creates for these requests? You should always be able to get a stream handle context, assuming you set one in the create, for cached IO requests.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
I rebooted the machine, started my IRP logger, opened my editor, and edited my sample file. I’m sure it wasn’t something I had missed. Besides, the normal IRPs show my file, stream, and stream handle contexts. The exact same pattern happens with whatever file I open, even network files, so I’m sure it is normal. And the cache writes never have a stream handle context, so it has undoubtedly created a new file object without an IRP_MJ_CREATE. which the MS docs say is normal. So I guess my only question is why it doesn’t show my file or stream contexts. I’m guessing that the new file object has not been attached to the contexts yet.
Btw, this is the latest of everything: Windows, VS, WDK, etc.
For cached IO you will see an IRP_MJ_CREATE for any file object which comes through the cached IO pathway … unless a filter is doing something strange above you. Just to confirm, I would set your start value in the registry service entry to 0, boot start, and see if you still do not see them.
The MS Docs say that you may not see the fileobject for a paging IO in your create handler since the underlying file system may create a stream fileobject to initialize caching, but not for cached IO, as noted above. Therefore it is not completely obvious what you are hitting though it could be that you are just missing the create requests.
Pete
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
What is your altitude?
PID 3464 is probably the Windows Defender scanning engine service and the IRP_MJ_READ is probably a paging read. Classic A/V scan thing to do is hold up the PostCreate and create a section for the file object in the scanning engine process. The scanning process then memory maps the file and pages in the data. If you’re above A/V you’ll see the IRP_MJ_READ before the PostCreate.
Thanks for the help, guys. Everything makes sense to me now. I was seeing two different things:
- Internal FileObject that was created without an IRP_MJ_CREATE, so no stream handle context for that, and it was a long lived handle, as is to be expected by the cache manager I imagine.
- IRPs generated during, not after, the IRP_MJ_CREATE I was processing, so I had not attached the file and stream contexts yet.
Later, the IRPs on that same stream handle used for cache writes had a file and stream context, but no stream handle context since there was no IRP_MJ_CREATE
Btw, there was no FO_STREAM_FILE on the file object for the mystery IRPs. I couldn’t find anything that marked them as different from the regular File Objects.
