Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category.

File system Mini Filter

vidhyavidhya Posts: 102
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

Comments

  • Peter_ScottPeter_Scott Posts: 741
    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://www.kerneldrivers.com/>;
    866.263.9295

    ------ Original Message ------
    From: "xxxxx@yahoo.co.in" <xxxxx@lists.osr.com>
    To: "Windows File Systems Devs Interest List" <xxxxx@lists.osr.com>
    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://www.osr.com/seminars>;
    >
    >To unsubscribe, visit the List Server section of OSR Online at
    ><http://www.osronline.com/page.cfm?name=ListServer>;

    Kernel Drivers
    Windows File System and Device Driver Consulting
    www.KernelDrivers.com
    866.263.9295

  • Don_BurnDon_Burn Posts: 1,623
    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 <xxxxx@kerneldrivers.com>
    Sent: Friday, January 05, 2018 11:11 AM
    To: Windows File Systems Devs Interest List <xxxxx@lists.osr.com>
    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://www.kerneldrivers.com/>;
    866.263.9295

    ------ Original Message ------
    From: "xxxxx@yahoo.co.in" <xxxxx@lists.osr.com>
    To: "Windows File Systems Devs Interest List" <xxxxx@lists.osr.com>
    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://www.osr.com/seminars>;
    >
    >To unsubscribe, visit the List Server section of OSR Online at
    ><http://www.osronline.com/page.cfm?name=ListServer>;


    ---
    NTFSD is sponsored by OSR


    MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
    Details at <http://www.osr.com/seminars>;

    To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>;
  • vidhyavidhya Posts: 102
    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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!