Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 9 April 2018

Writing WDF Drivers I: Core Concepts, Manchester, NH, 7 May 2018

Kernel Debugging & Crash Analysis for Windows, Manchester, NH, 21 May 2018


Go Back   OSR Online Lists > ntfsd
Welcome, Guest
You must login to post to this list
  Message 1 of 4  
05 Jan 18 02:30
vidhya
xxxxxx@yahoo.co.in
Join Date: 05 Jan 2018
Posts To This List: 7
File system Mini Filter

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. Removing just the part of the code related to file system filter driver and converting it into mini filter would make my design more complex. I need to manage data between the drivers. So I am planning to have the same driver binary which can be used as a volume upper filter driver and also mini filter driver. something like below I am planning to achieve. 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. To start with this approach I have few doubts. since now one binary acts as a volume filter driver and also file system mini filter driver what would be the entry of load order group in inf. Should I have multiple inf file for the same binary? one for volume filter driver(load order group : pnp filter) and one for file system mini filter driver(load order group : FSFilter Activity Monitor") Is this the correct approach? I can call FltRegisterFilter in my current driver routine to get registered with file system driver. so my current driver will become both volume filter driver and file system (null filter)mini filter driver Is my understanding correct? Vidhya
  Message 2 of 4  
05 Jan 18 11:12
Peter Scott
xxxxxx@kerneldrivers.com
Join Date: 17 Feb 2012
Posts To This List: 683
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. Pete -- Kernel Drivers Windows File System and Device Driver Consulting www.KernelDrivers.com <http://www.kerneldrivers.com/> 866.263.9295 ------ Original Message ------ From: "xxxxx@yahoo.co.in" <xxxxx@lists.osr.com> To: "Windows File Systems Devs Interest List" <xxxxx@lists.osr.com> 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 >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. > >Removing just the part of the code related to file system filter driver <...excess quoted lines suppressed...>
  Message 3 of 4  
05 Jan 18 11:19
Don Burn
xxxxxx@windrvr.com
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. Don Burn Windows Driver Consulting Website: http://www.windrvr.com -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of PScott <xxxxx@kerneldrivers.com> Sent: Friday, January 05, 2018 11:11 AM To: Windows File Systems Devs Interest List <xxxxx@lists.osr.com> 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. Pete -- Kernel Drivers Windows File System and Device Driver Consulting www.KernelDrivers.com <http://www.kerneldrivers.com/> 866.263.9295 ------ Original Message ------ From: "xxxxx@yahoo.co.in" <xxxxx@lists.osr.com> To: "Windows File Systems Devs Interest List" <xxxxx@lists.osr.com> 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 >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. > >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 drivers! Details at <http://www.osr.com/seminars> To unsubscribe, visit the List Server section of OSR Online at <http://www.osronline.com/page.cfm?name=ListServer>
  Message 4 of 4  
08 Jan 18 05:36
vidhya
xxxxxx@yahoo.co.in
Join Date: 05 Jan 2018
Posts To This List: 7
File system Mini Filter

Thanks for the input. I will look into it. I thought maintaining a single driver both as Mini and volume filter driver must be easy as I need not take care of communication between those two drivers. change tracking details will be in tact as it is now. My functionality is tightly coupled between volume filter and filter system filter. I start tracking the changes to the volume the moment we get IRP_MN_MOUNT_VOLUME. Let me look into my code base and come back. Thanks, Vidhya
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntfsd list to be able to post.

All times are GMT -5. The time now is 06:32.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license