File system Mini filter driver

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.
If I plan to move the part of the code(which attaches to file system stack) to file system Mini filter model what changes should be done.
what changes should be made in inf file. For complete porting of file system legacy filter driver to Mini port driver I am seeing guidelines in Net.
Can this be done at the first place.

Yes, the guidelines are a good place to start. Implement the framework
which registers with FM, establishes callbacks, etc. Then start moving
code from your legacy driver to the mini-filter callbacks. Ideally you
want to migrate as many Zw APIs to the Flt APIs as possible, taking into
consideration how you want to send those requests; to the top of the
stack or below you. Of course, depending on the complexity of the legacy
code, this migration can be anywhere from trivial to a multi-month
project.

The file system inquiry may be more appropriate on the NTFsd forum.

Thanks,

Pete


Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com http:</http:>
866.263.9295

------ Original Message ------
From: xxxxx@yahoo.co.in
To: “Windows System Software Devs Interest List”
Sent: 5/3/2016 6:04:43 AM
Subject: [ntdev] File system Mini filter driver

>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.
>If I plan to move the part of the code(which attaches to file system
>stack) to file system Mini filter model what changes should be done.
>what changes should be made in inf file. For complete porting of file
>system legacy filter driver to Mini port driver I am seeing guidelines
>in Net.
>Can this be done at the first place.
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list online at:
>http:
>
>MONTHLY seminars on crash dump analysis, WDF, Windows internals and
>software drivers!
>Details at http:
>
>To unsubscribe, visit the List Server section of OSR Online at
>http:</http:></http:></http:>

On 2016-05-03 06:04, xxxxx@yahoo.co.in wrote:

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.
If I plan to move the part of the code(which attaches to file system
stack) to file system Mini filter model what changes should be done.
what changes should be made in inf file. For complete porting of file
system legacy filter driver to Mini port driver I am seeing guidelines
in Net.
Can this be done at the first place.


NTDEV is sponsored by OSR

Visit the list online at:
http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:

I am not sure if you went through the guidelines so far, you can find
them here:
https://msdn.microsoft.com/en-us/library/windows/hardware/ff547378(v=vs.85).aspx
But for what you are describing, the changes should be minimal.
Worry about the inf file last, I doubt you will be needing too much
change there either.

It is possible for sure, and soon enough mandatory.

Regards,
Gabriel.
Windows Kernel Driver Consultant
www.kasardia.com</http:></http:></http:>

I did go through the link which you have mentioned. That says how to port a legacy filter driver to Mini filter model. My doubt is different. If I port my legacy driver to filter model completely and attach it to Fltmgr and modify the inf it will be attached to file system stack. But I also wanted my driver to get attached to volume stack. It should sit above Volsnap.sys driver as well. I don’t want to port those code to filter Model. Can both be achieved with a single driver and single inf file.

Regardless of WHETHER it can be done, it is a very bad idea to have the same driver be a VOLUME filter and a FILE SYSTEM filter. Very poor decomposition of functionality. Difficult to understand and maintain. All in all, not a good design choice.

Oh, BTW: You probably will have better luck asking File System Driver related questions on the NTFSD list than here on NTDEV. NTFSD is where all the cool file system people hang out.

https:

Peter
OSR
@OSRDrivers</https:>

I have to totally agree with Peter here regarding the choice for the design. The code must be pretty hellish to maintain and work around it.

That being said though, you could use the same driver for both the minifilter functionality and add yourself as a upper filter. As long as your AddDevice does what it should and you have your dispatch functions aware of the multiple possibilities that can occur, which I assume you already do then it should work.

You can already test it very easily with a pass through minifilter or a null minifilter and add yourself with the same driver to the upper filter of the stack you need. What I mean is add the minimal code for a passthrough/null minifilter in your existing driver.

Should anything be out of place then you know what adjustments you need to make.


Gabriel Bercea

Windows Kernel Driver Consulting

www.kasardia.com

On Wed, May 4, 2016 at 5:15 AM -0700, wrote:

Can both be achieved with a single driver and single inf file.

Regardless of WHETHER it can be done, it is a very bad idea to have the same driver be a VOLUME filter and a FILE SYSTEM filter. Very poor decomposition of functionality. Difficult to understand and maintain. All in all, not a good design choice.

Oh, BTW: You probably will have better luck asking File System Driver related questions on the NTFSD list than here on NTDEV. NTFSD is where all the cool file system people hang out.

Peter
OSR
@OSRDrivers


NTDEV is sponsored by OSR

Visit the list online at:

MONTHLY seminars on crash dump analysis, WDF, Windows internals and software drivers!
Details at

To unsubscribe, visit the List Server section of OSR Online at

yeah I do IoRegisterFsRegistrationChange() in my driver entry routine. The notification routine is called file system registers or unregisters it self as active file system.
In this notification routine I attach my driver to file system stack.
Again I have defined dispatch handler for IRP_MJ_FILE_SYSTEM_CONTROL. In this I monitor IRP_MN_MOUNT_VOLUME.
In inf file I define my driver as volume class filter and my load order group is “pnp filter”.
Now if I want my driver to be volume class filter at volume stack and mini filter driver at the file system stack how is that possible. I am sure I am missing something. I am not getting the visualization.
The moment I change the load order group to “FSFilter Activity Monitor” wont everything be changed. It will attach to fltmgr in file system stack. But how will it attach itself to storage volume stack.

Is it just in the existing driver routine I call FltRegisterFilter() and start filtering FltStartFiltering().
will this attach to fltmgr.

Filter Manager is a legacy file system filter driver. The call to register with it provides a table of callbacks that you have registered so that I/O operations will be redirected to your mini-filter. You don’t “attach” to Filter Manager, you “register” with Filter Manager. It is a cooperative model. You get called based upon your altitude (which you get from Microsoft). That defines the order in which things are presented (from highest altitude to lowest altitude).

Nobody outside Filter Manager should be attaching to the file system stack these days. Microsoft has made it clear that they will disable legacy file system filters in a future release. They’re already not loadable on Server 2016 (because they must be signed by Microsoft and Microsoft only has a certification model for mini-filters, not legacy filters in Windows Server 2016).

Because this is a registration model, 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.

Tony
OSR