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 8  
28 Oct 05 16:19
ntfsd member 14869
xxxxxx@comcast.net
Join Date:
Posts To This List: 483
Mini-filters and legacy filters

NTFSD Folk: The relationship of mini-filter drivers (i.e., which driver is above/below another driver) is determined by the Altitude setting of that driver. But where is it defined where they are with respect to legacy drivers? For instance, how do I determine if a legacy anti-virus filter is above or below my mini-filter, which is at altitude 288500? Ken
  Message 2 of 8  
28 Oct 05 17:20
Lyndon J. Clarke
xxxxxx@neverfailgroup.com
Join Date: 07 May 2003
Posts To This List: 766
Mini-filters and legacy filters

Ken "Where is it defined ?" Defined? Come on now, you seem to have been around this space long enough, you should know better :-) Filter manager is itself a "so called legacy" filter driver. Use devicetree to find out where filter manager and other filter driver are with respect to one another. You're minifilter (with whatever altitude it might have since it is irrelvant to the question) is in the same place as filter manager since it is in practical terms a collection of functions called from filter manager. Cheers Lyndon "Ken Cross" <xxxxx@comcast.net> wrote in message news:65062@ntfsd... > NTFSD Folk: > > The relationship of mini-filter drivers (i.e., which driver is above/below > another driver) is determined by the Altitude setting of that driver. > > But where is it defined where they are with respect to legacy drivers? > For > instance, how do I determine if a legacy anti-virus filter is above or > below > my mini-filter, which is at altitude 288500? <...excess quoted lines suppressed...>
  Message 3 of 8  
29 Oct 05 09:03
ntfsd member 26153
xxxxxx@comcast.net
Join Date:
Posts To This List: 254
Mini-filters and legacy filters

Lyndon, Wouldn't the FltMgr always be below other legacy filters? I assume Microsoft would of designed the FltMgr to load before any other legacy filter (so it would *always* be at the bottom), or else it would defeat the purpose of altitudes. Since FltMgr is a part of the OS, M$ could definitely engineer it so it would load before other legacy filters, even though it is of a legacy design itself. If not, what would the purpose be in assigning altitudes to specific vendors if some other legacy crap (like what I would write :-) ) could be installed below Ken's mini driver? It seems logical that other legacy drivers could only load above the FltMgr - regardless of fltmgr's design (legacy design). M. Lyndon J Clarke wrote: >Ken > >"Where is it defined ?" Defined? Come on now, you seem to have been around >this space long enough, you should know better :-) > >Filter manager is itself a "so called legacy" filter driver. Use devicetree >to find out where filter manager and other filter driver are with respect to >one another. You're minifilter (with whatever altitude it might have since >it is irrelvant to the question) is in the same place as filter manager >since it is in practical terms a collection of functions called from filter <...excess quoted lines suppressed...>
  Message 4 of 8  
29 Oct 05 10:16
ntfsd member 14696
xxxxxx@asw.cz
Join Date:
Posts To This List: 95
Mini-filters and legacy filters

fltmgr is in FSFilter Infrastructure group (boot time) i'd say, two drivers e.g. in FSFilter Encryption group (legacy + minifilter) will be loaded at the moment when this group is processed; and according to fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted function, it indicates, minifilter's callbacks should be called firstly "MM" <xxxxx@comcast.net> wrote in message news:65067@ntfsd... > Lyndon, > > Wouldn't the FltMgr always be below other legacy filters? I assume > Microsoft would of designed the FltMgr to load before any other legacy > filter (so it would *always* be at the bottom), or else it would defeat > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could > definitely engineer it so it would load before other legacy filters, > even though it is of a legacy design itself. > > If not, what would the purpose be in assigning altitudes to specific <...excess quoted lines suppressed...> --
  Message 5 of 8  
29 Oct 05 12:19
Lyndon J. Clarke
xxxxxx@neverfailgroup.com
Join Date: 07 May 2003
Posts To This List: 766
Mini-filters and legacy filters

Hi Matt Filter Manager is in the "Filter Infrastructure" load order group which the ifs kit documents as follows ... "Reserved for use by Microsoft. This group loads first and thus attaches closest to the file system." ... so what you expect/assume turns out to be how it works on this occasion. I dont think this is pertient to the concept of altitudes since these are no more than a complete order of mini filters but that is just the perspective of one individual. From a different perspective, perhaps a more minifilter centric perspective, I suppose one can say that "so called legacy" filter drivers have "infinite" altitude :) Cheers Lyndon "MM" <xxxxx@comcast.net> wrote in message news:65067@ntfsd... > Lyndon, > > Wouldn't the FltMgr always be below other legacy filters? I assume > Microsoft would of designed the FltMgr to load before any other legacy > filter (so it would *always* be at the bottom), or else it would defeat > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could > definitely engineer it so it would load before other legacy filters, even > though it is of a legacy design itself. > > If not, what would the purpose be in assigning altitudes to specific <...excess quoted lines suppressed...>
  Message 6 of 8  
31 Oct 05 02:51
ntfsd member 4918
xxxxxx@pandasoftware.es
Join Date:
Posts To This List: 6
Mini-filters and legacy filters

Hi, Filter Manager "load order" group is not important to determine its = attach position. Traditional legacy FS filters attaches to a volume in = the order in which they load, but Filter Manager legacy filter is not = traditional :). Filter Manager allows coexistence between legacy filters and minifilters = in a mixed environment. A legacy filter has a load order group, and a = minifilter has an altitude that defines its load order group. I mean, = altitude is mapped to a load order group, so the minifilter position in = a stack is defined with regard to the position of one or more legacy = filters. The OS permits this coexistence by allowing the Filter Manager to attach = to a volume more than once. Each Filter Manager VDO instance filtering = the same volume is called a "frame". And I suppose that in the worst = scenario, it is possible to have the same number of Filter Manager = attachments by volume (frames) as load order groups, because it could be = necessary to interleave a frame between each legacy filter with = different load order group. Regards, Ramon -----Mensaje original----- De: xxxxx@lists.osr.com = [mailto:xxxxx@lists.osr.com] En nombre de Lyndon J Clarke Enviado el: s=E1bado, 29 de octubre de 2005 18:19 Para: Windows File Systems Devs Interest List Asunto: Re:[ntfsd] Mini-filters and legacy filters Hi Matt Filter Manager is in the "Filter Infrastructure" load order group which = the=20 ifs kit documents as follows ... "Reserved for use by Microsoft. This = group=20 loads first and thus attaches closest to the file system." ... so what = you=20 expect/assume turns out to be how it works on this occasion. I dont think this is pertient to the concept of altitudes since these = are no=20 more than a complete order of mini filters but that is just the = perspective=20 of one individual. From a different perspective, perhaps a more = minifilter=20 centric perspective, I suppose one can say that "so called legacy" = filter=20 drivers have "infinite" altitude :) Cheers Lyndon "MM" <xxxxx@comcast.net> wrote in message news:65067@ntfsd... > Lyndon, > > Wouldn't the FltMgr always be below other legacy filters? I assume=20 > Microsoft would of designed the FltMgr to load before any other legacy = > filter (so it would *always* be at the bottom), or else it would = defeat=20 > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could=20 > definitely engineer it so it would load before other legacy filters, = even=20 > though it is of a legacy design itself. > > If not, what would the purpose be in assigning altitudes to specific=20 > vendors if some other legacy crap (like what I would write :-) ) could = be=20 > installed below Ken's mini driver? > > It seems logical that other legacy drivers could only load above the=20 > FltMgr - regardless of fltmgr's design (legacy design). > > M. > > Lyndon J Clarke wrote: > >>Ken <...excess quoted lines suppressed...> are=20 >>with respect to one another. You're minifilter (with whatever altitude = it=20 >>might have since it is irrelvant to the question) is in the same place = as=20 >>filter manager since it is in practical terms a collection of = functions=20 >>called from filter manager. >> >>Cheers >>Lyndon >> >>"Ken Cross" <xxxxx@comcast.net> wrote in message news:65062@ntfsd... >> >>>NTFSD Folk: >>> >>>The relationship of mini-filter drivers (i.e., which driver is=20 drivers?=20 >>>For >>>instance, how do I determine if a legacy anti-virus filter is above = or=20 >>>below >>>my mini-filter, which is at altitude 288500? >>> >>>Ken >>> >>> >>> >> >> >> --- Questions? First check the IFS FAQ at = https://www.osronline.com/article.cfm?id=3D17 You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es To unsubscribe send a blank email to xxxxx@lists.osr.com
  Message 7 of 8  
31 Oct 05 03:05
Lyndon J. Clarke
xxxxxx@neverfailgroup.com
Join Date: 07 May 2003
Posts To This List: 766
Mini-filters and legacy filters

Hmm ... very interesting ... I read after post more about minifilters, noticed that these also have load order groups, and wondered whether filter manager was doing something like this - it is just as well really else quite a few very dissapionted miinifilter driver developers out there when someone loads an encryption filter :-) "Ramon Royo" <xxxxx@pandasoftware.es> wrote in message news:65104@ntfsd... Hi, Filter Manager "load order" group is not important to determine its attach position. Traditional legacy FS filters attaches to a volume in the order in which they load, but Filter Manager legacy filter is not traditional :). Filter Manager allows coexistence between legacy filters and minifilters in a mixed environment. A legacy filter has a load order group, and a minifilter has an altitude that defines its load order group. I mean, altitude is mapped to a load order group, so the minifilter position in a stack is defined with regard to the position of one or more legacy filters. The OS permits this coexistence by allowing the Filter Manager to attach to a volume more than once. Each Filter Manager VDO instance filtering the same volume is called a "frame". And I suppose that in the worst scenario, it is possible to have the same number of Filter Manager attachments by volume (frames) as load order groups, because it could be necessary to interleave a frame between each legacy filter with different load order group. Regards, Ramon -----Mensaje original----- De: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] En nombre de Lyndon J Clarke Enviado el: sábado, 29 de octubre de 2005 18:19 Para: Windows File Systems Devs Interest List Asunto: Re:[ntfsd] Mini-filters and legacy filters Hi Matt Filter Manager is in the "Filter Infrastructure" load order group which the ifs kit documents as follows ... "Reserved for use by Microsoft. This group loads first and thus attaches closest to the file system." ... so what you expect/assume turns out to be how it works on this occasion. I dont think this is pertient to the concept of altitudes since these are no more than a complete order of mini filters but that is just the perspective of one individual. From a different perspective, perhaps a more minifilter centric perspective, I suppose one can say that "so called legacy" filter drivers have "infinite" altitude :) Cheers Lyndon "MM" <xxxxx@comcast.net> wrote in message news:65067@ntfsd... > Lyndon, > > Wouldn't the FltMgr always be below other legacy filters? I assume > Microsoft would of designed the FltMgr to load before any other legacy > filter (so it would *always* be at the bottom), or else it would defeat > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could > definitely engineer it so it would load before other legacy filters, even > though it is of a legacy design itself. > > If not, what would the purpose be in assigning altitudes to specific <...excess quoted lines suppressed...> --- Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17 You are currently subscribed to ntfsd as: xxxxx@pandasoftware.es To unsubscribe send a blank email to xxxxx@lists.osr.com
  Message 8 of 8  
05 Nov 05 14:45
ntfsd member 1661
xxxxxx@windows.microsoft.com
Join Date:
Posts To This List: 608
Mini-filters and legacy filters

Roman & Lyndon are correct. Filter manager has a well defined algorithm (though not completely documented) for how it interoperates with legacy filters. Let me explain. In the legacy filter world load order is what controls attachment order. In the ideal minifilter world attachment order is controlled by altitudes and load order doesn't matter because filter manager can load a minifilter at its correct altitude regardless of when it loaded. The problem is that we needed to make these two worlds co-exist. We had thought about making all mini-filters exist below all legacy filters but that model does not work well. A simple example is if there was a antivirus minifilter and a legacy encryption filter. Obviously having the AV product scan encrypted data is not going to be useful. We had to figure out a model to make these two worlds co-exist in a reasonable way.=20 As was pointed out by Roman, filter manager has a concept known as Frames. A frame is a unique attachment by filter manager to the IO Stack. By default filter manager loads before any other filters and creates frame 0 automatically. One of the reasons that filter manager has to load first is to guarantee consistency of the name cache. If there was a legacy filter below filter manager's frame 0 that renamed files, the name cache would become corrupt. Note that we actually detect this situation and disable the name cache (naming APIs still work, names are simply not cached) if there is a legacy filter below frame 0. Let me layout what filter manager does at load time: - Initially frame 0 has an altitude range of 0-0. - Lets say a minifilter loads with an altitude of 100 - Filter manager first checks to see if this is within the range of an existing frame. The answer is no in this case. - Filter manager checks to see if a legacy filter has attached above frame 0. The answer is no. - Filter manager adjusts the altitude range of frame 0 to be 0-100 and loads the minifilter in frame 0 - Lets say another minifilter loads next with an altitude of 75 - Filter manager checks to see if this is within the range of an existing frame. The answer is yes so the minifilter is loaded in frame 0. We do this check first to support a minifilter unloading and reloading (an upgrade for example) and we guarantee they will go back to the same frame. - Lets say another minifilter now loads with an altitude of 200 - Filter manager checks to see if this is within the range of an existing filter. No - Filter manager checks to see if a legacy filter has loaded above frame 0. No - Filter manager adjust the altitude range of frame 0 to be 0-200 now and loads the minifilter in frame 0 - Lets say a legacy filter now loads. It is obviously going to attach above filter manager frame 0. - We now have another minifilter load with an altitude of 300. - We see if this fits in an existing frame. In this case the altitude range of frame zero is still 0-200 so the answer is no. - We check if a legacy filter has loaded above filter manager's highest frame. - This time the answer is yes. When this happens the altitude range of the frame immediately underneath is now capped and we create a frame 1 with an altitude range of 200-300. Note that altitude ranges are not inclusive of the lower value. - We load the minifilter in frame 1 We keep doing this for each additional minifilter/legacy filter that is loaded and dynamically create frames as needed. This is why minifilters still have load-order-groups and there are altitude ranges for each load-order-group. This is also why it is still important to load your minifilter at the correct boot phase (boot, system, automatic) as if it were a legacy filter to get proper ordering if legacy filters are still present. This means if you have a "low" load order group you need to load in an earlier boot phase then if you have a "high" load order group. =20 Once Windows no longer supports legacy filters (this will happen post vista/longhorn) things will be much simpler because your minifilter can have any altitude and load at any time and be order properly. As you might have noticed the frame concept is not really exposed to minifilters. If you run "fltmc" without any parameters it lists the existing filters in the system. Notice that it also identifies the frame the minifilter is loaded in. This is the only indication in the system of frames. If you use the "fltkd" debugger extension it will also provide frame information. I hope this description helps, Neal Christiansen Microsoft File System Filter Group Lead This posting is provided "AS IS" with no warranties, and confers no Rights -----Original Message----- From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Lyndon J Clarke Sent: Saturday, October 29, 2005 9:19 AM To: Windows File Systems Devs Interest List Subject: Re:[ntfsd] Mini-filters and legacy filters Hi Matt Filter Manager is in the "Filter Infrastructure" load order group which the=20 ifs kit documents as follows ... "Reserved for use by Microsoft. This group=20 loads first and thus attaches closest to the file system." ... so what you=20 expect/assume turns out to be how it works on this occasion. I dont think this is pertient to the concept of altitudes since these are no=20 more than a complete order of mini filters but that is just the perspective=20 of one individual. From a different perspective, perhaps a more minifilter=20 centric perspective, I suppose one can say that "so called legacy" filter=20 drivers have "infinite" altitude :) Cheers Lyndon "MM" <xxxxx@comcast.net> wrote in message news:65067@ntfsd... > Lyndon, > > Wouldn't the FltMgr always be below other legacy filters? I assume=20 > Microsoft would of designed the FltMgr to load before any other legacy > filter (so it would *always* be at the bottom), or else it would defeat=20 > the purpose of altitudes. Since FltMgr is a part of the OS, M$ could=20 > definitely engineer it so it would load before other legacy filters, even=20 > though it is of a legacy design itself. > > If not, what would the purpose be in assigning altitudes to specific=20 > vendors if some other legacy crap (like what I would write :-) ) could be=20 > installed below Ken's mini driver? > > It seems logical that other legacy drivers could only load above the=20 > FltMgr - regardless of fltmgr's design (legacy design). > > M. > > Lyndon J Clarke wrote: > >>Ken <...excess quoted lines suppressed...> are=20 >>with respect to one another. You're minifilter (with whatever altitude it=20 >>might have since it is irrelvant to the question) is in the same place as=20 >>filter manager since it is in practical terms a collection of functions=20 >>called from filter manager. >> >>Cheers >>Lyndon >> >>"Ken Cross" <xxxxx@comcast.net> wrote in message news:65062@ntfsd... >> >>>NTFSD Folk: >>> >>>The relationship of mini-filter drivers (i.e., which driver is=20 drivers?=20 >>>For >>>instance, how do I determine if a legacy anti-virus filter is above or=20 >>>below >>>my mini-filter, which is at altitude 288500? >>> >>>Ken >>> >>> >>> >> >> >> --- Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=3D17 You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com To unsubscribe send a blank email to xxxxx@lists.osr.com
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 07:51.


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