Mini-filters and legacy filters

NTFSD
1

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

2

Ken

“Where is it defined ?” Defined? Come on now, you seem to have been around
this space long enough, you should know better :slight_smile:

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” wrote in message news:xxxxx@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?
>
> Ken
>
>

3

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 :slight_smile: ) 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 :slight_smile:

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” wrote in message news:xxxxx@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?
>>
>>Ken
>>
>>
>>
>>
>
>
>
>—
>Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>

4

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” wrote in message news:xxxxx@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
> vendors if some other legacy crap (like what I would write :slight_smile: ) 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 :slight_smile:
>>
>>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” wrote in message news:xxxxx@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?
>>>
>>>Ken
>>>
>>>
>>>
>>>
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>>
>

5

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 :slight_smile:

Cheers
Lyndon

“MM” wrote in message news:xxxxx@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
> vendors if some other legacy crap (like what I would write :slight_smile: ) 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 :slight_smile:
>>
>>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” wrote in message news:xxxxx@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?
>>>
>>>Ken
>>>
>>>
>>>
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>

6

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 :slight_smile:

Cheers
Lyndon

“MM” wrote in message news:xxxxx@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
> vendors if some other legacy crap (like what I would write :slight_smile: ) 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 :slight_smile:
>>
>>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” wrote in message news:xxxxx@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?
>>>
>>>Ken
>>>
>>>
>>>
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>

—
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

7

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 :slight_smile:

“Ramon Royo” wrote in message news:xxxxx@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 :slight_smile:

Cheers
Lyndon

“MM” wrote in message news:xxxxx@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
> vendors if some other legacy crap (like what I would write :slight_smile: ) 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 :slight_smile:
>>
>>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” wrote in message news:xxxxx@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?
>>>
>>>Ken
>>>
>>>
>>>
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>

—
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

8

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.

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

  1. 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.

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
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 :slight_smile:

Cheers
Lyndon

“MM” wrote in message news:xxxxx@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
> vendors if some other legacy crap (like what I would write :slight_smile: ) 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 :slight_smile:
>>
>>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” wrote in message news:xxxxx@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?
>>>
>>>Ken
>>>
>>>
>>>
>>
>>
>>
>>—
>>Questions? First check the IFS FAQ at
>>https://www.osronline.com/article.cfm?id=17
>>
>>You are currently subscribed to ntfsd as: xxxxx@comcast.net
>>To unsubscribe send a blank email to xxxxx@lists.osr.com
>>
>>
>

—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17

You are currently subscribed to ntfsd as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com