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