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 Driver

vidhyavidhya Member - All Emails Posts: 102
I am planning to port a legacy file system filter driver to mini filter driver.
In my mini filter driver I need to check on Mount Request(IRP_MN_MOUNT_VOLUME) and do house keeping operation. I need to get hold of the first write or read to the volume. so I sniff for IRP_MN_MOUNT_VOLUME.

I already have a minifilter driver for other purpose in FSFilter Activity Monitor group.
My question is can I add my current functionality to check on Mount Request(IRP_MN_MOUNT_VOLUME) to the same mini filter driver or should I write a new mini filter driver for my new functionality.

Doc says FSFilter Activity Monitor group observes and reports the file I/O, I don't think checking for IRP_MN_MOUNT_VOLUME is a file I/O operation.

FSFilter Activity Monitor : This group includes filter drivers that observe and report on file I/O

In which load order group my driver should be if I write a new mini filter driver

Thanks in advance
Vidhya

Comments

  • vidhyavidhya Member - All Emails Posts: 102
    I thought my driver should be under FSFilter System Recovery is the group.
    Let me know ur thoughts.
  • vidhyavidhya Member - All Emails Posts: 102
    I am planning to port a legacy file system filter driver to mini filter driver.
    In my mini filter driver I need to check on Mount Request(IRP_MN_MOUNT_VOLUME)
    and do house keeping operation. I need to get hold of the first write or read to
    the volume. so I sniff for IRP_MN_MOUNT_VOLUME.

    I already have a minifilter driver for other purpose in FSFilter Activity
    Monitor group.
    My question is can I add my current functionality to check on Mount
    Request(IRP_MN_MOUNT_VOLUME) to the same mini filter driver or should I write a
    new mini filter driver for my new functionality.

    Doc says FSFilter Activity Monitor group observes and reports the file I/O, I
    don't think checking for IRP_MN_MOUNT_VOLUME is a file I/O operation.

    FSFilter Activity Monitor : This group includes filter drivers that observe and
    report on file I/O

    In which load order group my driver should be if I write a new mini filter
    driver
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,016
    Just FYI minifilters get mount requests by registering for
    IRP_MJ_VOLUME_MOUNT requests. This is a Filter Manager abstraction of
    IRP_MN_MOUNT_VOLUME.

    With respect to the altitude, it really depends on what ELSE you're going to
    do. It's not so much which operations you're interested in but more about
    what your filter does and how it interacts with the system and other
    filters. If you just need to be passively notified of mount requests then
    I'm not sure how it could hurt adding it to your existing filter.

    If you're interfering in the mount process in some way then you might need a
    different altitude. You can always just send a request in describing what
    you're doing and see what altitude is returned to you.

    -scott
    OSR
    @OSRDrivers

    -scott
    OSR

  • vidhyavidhya Member - All Emails Posts: 102
    Thanks Scott.

    Just FYI minifilters get mount requests by registering for
    IRP_MJ_VOLUME_MOUNT requests. This is a Filter Manager abstraction of
    IRP_MN_MOUNT_VOLUME.

    >> I have registered for IRP_MJ_VOLUME_MOUNT in my code. when I wrote this thread I was not aware of this. Now I am doing the same what u have mentioned.

    I don't interfere in the mount operation, I need to initialize few internal data structures when I get the first mount request of the volume. Now currently I have added code in post callback function of IRP_MJ_VOLUME_MOUNT. My plan is to create an IRP locally in my mini filter and send it to my volume filter driver which sits above volsnap in the volume stack when I receive the first Mount operation in minifilter driver.
    For this I need to get the device object of my volume filter driver from Minifilter driver.
    To achieve this I saw other threads in OSR and I tried the following commands

    1) Get the current device by calling FltGetDeviceObject(pFltObjects->Volume)
    2) Get the top highest-level device by calling IoGetAttachedDevice().
    But when I see the device object returned by IoGetAttachedDevice(), it doesn't match my volume filter driver's object.

    Hope I am in right path. Let me know your thoughts please. Below is the link I tried to follow

    https://www.osronline.com/showthread.cfm?link=246896

    Regards,
    Vidhya
  • vidhyavidhya Member - All Emails Posts: 102
    There was a typo in the last message
    But when I see the device object returned by IoGetAttachedDevice(), it doesn't
    match my volume filter device object.

    Regards,
    Vidhya
  • vidhyavidhya Member - All Emails Posts: 102
    Another Query in the same line:
    Instead of following the below steps to get the device object of the volume filter driver above volsnap from mini filter driver
    1) FltGetDeviceObject(pFltObjects->Volume)
    2) IoGetAttachedDevice().

    I tried using FltObjects->FileObject->Vpb->RealDevice. But FltObjects->FileObject is always NULL for me.
    I tried checking FltObjects->FileObject in PreCallback function for IRP_MJ_VOLUME_MOUNT.
    shouldn't be FltObjects->FileObject != NULL.
    Both ways I am unable to get the required device object

    Regards,
    Vidhya
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,016
    There can be other filters in the stack, so you're not necessarily at the
    top. If you just send the I/O request to the top of the stack does it
    eventually reach your volume filter?

    -scott
    OSR
    @OSRDrivers

    -scott
    OSR

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!