Message 8 of 8
05 Nov 05 14:45
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
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
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
- 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,
Microsoft File System Filter Group Lead
This posting is provided "AS IS" with no warranties, and confers no
[mailto:email@example.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
Filter Manager is in the "Filter Infrastructure" load order group which
ifs kit documents as follows ... "Reserved for use by Microsoft. This
loads first and thus attaches closest to the file system." ... so what
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
more than a complete order of mini filters but that is just the
of one individual. From a different perspective, perhaps a more
centric perspective, I suppose one can say that "so called legacy"
drivers have "infinite" altitude :)
"MM" wrote in message news:65067@ntfsd...
> 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
> 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,
> 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
> 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).
> Lyndon J Clarke wrote:
<...excess quoted lines suppressed...>
>>with respect to one another. You're minifilter (with whatever altitude
>>might have since it is irrelvant to the question) is in the same place
>>filter manager since it is in practical terms a collection of
>>called from filter manager.
>>"Ken Cross" wrote in message news:65062@ntfsd...
>>>The relationship of mini-filter drivers (i.e., which driver is
>>>instance, how do I determine if a legacy anti-virus filter is above
>>>my mini-filter, which is at altitude 288500?
Questions? First check the IFS FAQ at
You are currently subscribed to ntfsd as: firstname.lastname@example.org
To unsubscribe send a blank email to email@example.com