I have a driver which attaches to both volume stack (as Upper volume filter
driver) and File system stack( as File system filter driver). I want to port the
code that attaches itself to File system stack to Mini filter model.
I don't do much operation attaching the driver to file system stack. I check for
IRP_MN_MOUNT_VOLUME and do some house keeping operation.
Removing just the part of the code related to file system filter driver and converting it into mini filter would make my design more complex. I need to manage data between the drivers.
So I am planning to have the same driver binary which can be used as a volume upper filter driver and also mini filter driver.
something like below I am planning to achieve.
you can actually combine multiple file system mini-filters in the same executable image. You can even combine a volume filter (which uses the device attachment mechanism) with a file system mini-filter (which uses Filter Manager callback registrations). Logically distinct functionality, with a single driver binary - somewhat like how you can have multiple services running within the same user mode process. They aren't really related, except they live in the same space.
To start with this approach I have few doubts. since now one binary acts as a volume filter driver and also file system mini filter driver what would be the entry of load order group in inf. Should I have multiple inf file for the same binary? one for volume filter driver(load order group : pnp filter) and one for file system mini filter driver(load order group : FSFilter Activity Monitor")
Is this the correct approach?
I can call FltRegisterFilter in my current driver routine to get registered with file system driver.
so my current driver will become both volume filter driver and file system (null filter)mini filter driver
Is my understanding correct?