How can minifilter driver intercept IOCTL_MOUNTMGR_DELETE_POINTS ?

How can minifilter driver intercept IOCTL_MOUNTMGR_DELETE_POINTS ?

I had fill IRP_MJ_DEVICE_CONTROL and IRP_MJ_INTERNAL_DEVICE_CONTROL in the FLT_OPERATION_REGISTRATION ,

but it’s not work, it seems that IOCTL_MOUNTMGR_DELETE_POINTS still not go through minifilter driver.

Did I miss something?

As far as I know, this IOCTL is sent to the Mount Point Manager. In order to intercept it, you may attach over its \Device\MountPointManager device.

@“Martin_Dráb” said:
As far as I know, this IOCTL is sent to the Mount Point Manager. In order to intercept it, you may attach over its \Device\MountPointManager device.
Thanks Martin.

If a driver attach some device and hook some IRP_MJ_* , the driver object’s MajorFunction member should be set. So, the new question is: Is it safe to do so in a minifilter driver ? For example if a minifilter driver’s code like below:

for (unsigned i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
{
pDriverObject->MajorFunction[i] = hook_function;
}

I think minifilters do not rely on the IRP dispatch functions (MajorFunction). Rather, they register their callbacks by passing quite a structure into FltRegisterFilter. IRPs and other requests/calls are intercepted by the Filter Manager and passed to the registered drivers by its own mechanism.

Hence, I think it is safe to set MajorFunction of your driver as you see fit. You can verify this by looking and the DRIVER_OBJECT structure in WinDbg.

I think it’s work. :slight_smile:

Thank you again.

@“Martin_Dráb” said:
I think minifilters do not rely on the IRP dispatch functions (MajorFunction). Rather, they register their callbacks by passing quite a structure into FltRegisterFilter. IRPs and other requests/calls are intercepted by the Filter Manager and passed to the registered drivers by its own mechanism.

Hence, I think it is safe to set MajorFunction of your driver as you see fit. You can verify this by looking and the DRIVER_OBJECT structure in WinDbg.