Application sending messages to minifilter, how to get the PFLT_INSTANCE

Hello,

I have an application that sends message to my minifilter using ioctl. (It’s originally a legacy filter being ported to minifilter. May be later I will use the technology provided by the filter manager instead of ioctls (FltSendMessage() …) .)

My application, using ioctl, send a file handle to my filter driver. The filter finds the FILE_OBJECT corresponding to that handle. Then I want to find some registered context I setted when I received IRP_MJ_CREATE for that FILE_OBJECT. But when I received this inside my filter driver, I don’t have any PFLT_INSTANCE to use to call for instance FltGetStreamHandleContext() or FltGetFileContext().

I know that the FILE_OBJECT has a “PDEVICE_OBJECT DeviceObject;”, can I use it in some ways to find the PFLT_INSTANCE ? Am I missing something ? And even using the FilterManager apis (FltSendMessage() …) won’t help me in this case, I think.

Any help appreciated !

I know its a change of architecture, but why not send the ioctl to the file object?

Its a bit around the houses but you I guess could get the FLT_VOLUME from the file object(FltGetVolumeFromFileObject) and thence a Volume context in which you could store you instance context(s). I’ve never done this but spelunking the Fine Manual seems to look like it would work.
(NB Volume Contexts have to be non-paged)

Thanks for your response.
Good idea, I didn’t know the function FltGetVolumeFromFileObject()! But If there are many instances of the filter on various altitudes may be there is more than one instance on a single Volume so I’ll have to find out which one is the good one … I’ll check that tomorrow, I’m not sure about what I’m saying.
What do you mean by sending the ioctl to the FILE_OBJECT?

I think Rod is suggesting that you call DeviceIoControl on the HANDLE to the file you have opened. This will send either an FSCTL or IOCTL (depending on the DeviceType in the control code) to the file system stack. You will then see this along with every other FSCTL/IOCTL request in your PreFsctl/PreIoctl handler.

We usually call this sending the request “in-band”. The benefit is that you get all of your various contexts (stream, instance, etc.) along with the request. The downside is that if multiple people do it there is a chance of colliding with someone else’s IOCTL values.

IMO the upside outweighs the downside. I’ve never actually seen the collision happen and, if it did, you’d know about it pretty quickly.

Ok thanks for the clarifications! I did not know that. I will check on that when I have some time.

Actually my driver has only one instance per volume so I can do what rod suggested, register the instance context in the volume context. This will not break the design of my driver for now. Later I’ll do something cleaner/better.

Thank you both!