File system Mini filter Driver

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

I thought my driver should be under FSFilter System Recovery is the group.
Let me know ur thoughts.

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

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

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

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

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

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