Message 3 of 4
05 Jan 18 11:19
Join Date: 23 Feb 2011
Posts To This List: 174
File system Mini Filter
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.
Windows Driver Consulting
From: firstname.lastname@example.org [mailto:email@example.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.
Windows File System and Device Driver Consulting
------ Original Message ------
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
>driver) and File system stack( as File system filter driver). I want to
>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
>IRP_MN_MOUNT_VOLUME and do some house keeping operation.
>Removing just the part of the code related to file system filter driver
<...excess quoted lines suppressed...>
NTFSD is sponsored by OSR
MONTHLY seminars on crash dump analysis, WDF, Windows internals and software
To unsubscribe, visit the List Server section of OSR Online at