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.

On-Access, Transparent, Per-File Data Encryption:

OSR's File Encryption Solution Framework (FESF) provides all the infrastructure you need to build a transparent file encryption product REALLY FAST.

Super flexible policy determination and customization, all done in user-mode. Extensive starter/sample code provided.

Proven, robust, flexible. In use in multiple commercial products.

Currently available on Windows. FESF for Linux will ship in 2018.

For more info: https://www.osr.com/fesf

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: 2
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: 682
File system Mini Filter

I would highly suggest separating out the functionality and implementing=20 a driver-to-driver communication mechanism. For example, in the=20 mini-filter, you can open the volume filter since it would have a named=20 control device (or you can add a named control device) and then have=20 callbacks in the device extension of the control device object you get=20 to make calls back and forth. But trying to combine the functionality=20 into a single binary is just going to cause you unneeded head aches. If=20 your current FS filter has minimal functionality then porting it to a=20 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=20 >filter >driver) and File system stack( as File system filter driver). I want to=20 >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=20 >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=20 <...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: 173
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=20 -----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=20 mini-filter, you can open the volume filter since it would have a named=20 control device (or you can add a named control device) and then have=20 callbacks in the device extension of the control device object you get=20 to make calls back and forth. But trying to combine the functionality=20 into a single binary is just going to cause you unneeded head aches. If=20 your current FS filter has minimal functionality then porting it to a=20 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=20 >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=20 >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=3DListServer>
  Message 4 of 4  
08 Jan 18 05:36
vidhya
xxxxxx@yahoo.co.in
Join Date: 05 Jan 2018
Posts To This List: 2
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 04:26.


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