File system Mini Filter

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?

Vidhya

I would highly suggest separating out the functionality and implementing
a driver-to-driver communication mechanism. For example, in the
mini-filter, you can open the volume filter since it would have a named
control device (or you can add a named control device) and then have
callbacks in the device extension of the control device object you get
to make calls back and forth. But trying to combine the functionality
into a single binary is just going to cause you unneeded head aches. If
your current FS filter has minimal functionality then porting it to a
mini-filter will be trivial.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: “xxxxx@yahoo.co.in”
To: “Windows File Systems Devs Interest List”
Sent: 1/5/2018 12:30:05 AM
Subject: [ntfsd] File system Mini Filter

>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?
>
>Vidhya
>
>
>
>
>
>
>
>
>
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:>

I would agree with Pete. I have done this on a couple of projects, and it is much cleaner and maintainable than trying to put everything in one driver.

Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of PScott
Sent: Friday, January 05, 2018 11:11 AM
To: Windows File Systems Devs Interest List
Subject: Re: [ntfsd] File system Mini Filter

I would highly suggest separating out the functionality and implementing
a driver-to-driver communication mechanism. For example, in the
mini-filter, you can open the volume filter since it would have a named
control device (or you can add a named control device) and then have
callbacks in the device extension of the control device object you get
to make calls back and forth. But trying to combine the functionality
into a single binary is just going to cause you unneeded head aches. If
your current FS filter has minimal functionality then porting it to a
mini-filter will be trivial.

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: “xxxxx@yahoo.co.in”
To: “Windows File Systems Devs Interest List”
Sent: 1/5/2018 12:30:05 AM
Subject: [ntfsd] File system Mini Filter

>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?
>
>Vidhya
>
>
>
>
>
>
>
>
>
>
>—
>NTFSD is sponsored by OSR
>
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:


NTFSD is sponsored by OSR

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at http:

To unsubscribe, visit the List Server section of OSR Online at http:</http:></http:></http:></http:>

Thanks for the input. I will look into it. I thought maintaining a single driver both as Mini and volume filter driver must be easy as I need not take care of communication between those two drivers. change tracking details will be in tact as it is now. My functionality is tightly coupled between volume filter and filter system filter. I start tracking the changes to the volume the moment we get IRP_MN_MOUNT_VOLUME. Let me look into my code base and come back.

Thanks,
Vidhya