Separation of Concerns in a filesystem minifilter

Hi,

I have a filesystem minifilter driver which implements a set of distinct functionalities which I would like to be able to logically separate for development and support purposes. It would be desirable to provide our Support team with a mechanism to disable certain features but leave others enabled. The different features require the use of a different set of call-backs and the call-backs required for the features will partially overlap. As a simple example

Feature A needs IRP_MJ_CREATE, IRP_MJ_WRITE and IRP_MJ_CLOSE
Feature B needs IRP_MJ_CREATE, IRP_MJ_WRITE, IRP_MJ_READ and IRP_MJ_CLOSE

So my question is how to best achieve this separation of concerns?

  • To split this functionality out into separate drivers would result in a possibly large number of drivers.
  • Adding ad hoc code to the driver to control individual features would probably get messy.
  • Assigning a set of dedicated call-backs to each particular feature would involve writing a framework to pass IRPs between the different callbacks (e.g. present an IRP_MJ_WRITE to Feature A’s write callback then Feature B’s write callback) in a similar way to the filter manager, which is reinventing the wheel.

Any advice on how best to go about this would be appreciated. Thanks,

Ian.

Interesting problem with no right answer of course…

Just to give you another option to look at, note that you can register one minifilter driver at multiple different altitudes (see the Minispy sample). You can also break your single “official” altitude into multiple sub-altitudes (e.g. 370000.0, 370000.1, 370000.2, etc).

So, you could have your different features at different altitudes and attach/detach them as necessary. This effectively gets your option 3 “for free” because FltMgr will dispatch each operation to your multiple instances.

I’m not saying this is a perfect option, but something else to think about.

-scott
OSR
@OSRDrivers

That’s perfect Scott. Thanks very much!

Ian.

OK, I have played with minispy but I don’t understand how it shows me how to create multiple instances. I can see the registry entries for the additional instances but when I run it I only see one. What do I need to do to load the middle and bottom instances? Here’s my output:

/a c:
Attaching to c:… Instance name: Minispy - Top Instance
/l

Dos Name Volume Name Status


\Device\Mup
C: \Device\HarddiskVolume2 Attached
\Device\NamedPipe
\Device\Mailslot
\Device\HarddiskVolume1

C:\Windows\system32>fltmc instances
Filter Volume Name Altitude Instance Name Frame SprtFtrs VlStatus


FileInfo 40500 FileInfo 0 00000003
FileInfo C: 40500 FileInfo 0 00000003
FileInfo \Device\Mup 40500 FileInfo 0 00000003
Minispy C: 385100 Minispy - Top Instance 0 00000007
WdFilter 328010 WdFilter Instance 0 00000007
WdFilter C: 328010 WdFilter Instance 0 00000007
WdFilter \Device\Mup 328010 WdFilter Instance 0 00000007
:
:

Thanks,

Ian.

To (partly) answer my own question, I had to change the InstanceX.Flags entries in the inf file to allow automatic attachments. I now get one call to DriverEntry plus one per instance to an InstanceSetup callback I added and of course I see the different PFLT_INSTANCE pointers passed in the PCFLT_RELATED_OBJECTS parameter of my callbacks.

This is all good but how do I achieve the different features at different altitudes? Would this be a case of checking the PFLT_INSTANCE pointer in each callback or can I change the list of IRP callbacks on a per-instance basis?

Thanks,

Ian.

(Sorry, been away)

This. The callbacks are global to the filter, so you do different processing at the different instances.

-scott
OSR
@OSRDrivers

No problem. Thanks again Scott.