We are experiencing a rare problem in the field with our legacy filter being
loaded incorrectly against 3rd party minifilters. In particular, AV filters are
being loaded BELOW our legacy encryption filter.
This is an extremely unusual situation - the vast majority of systems order the
drivers correctly.
The “fltmc” output from an affected system is:
Filter Name Num Instances Altitude Frame
mfehidk 329998.99
CmgShieldCEF 149998.99
mfehidk 2 321300.00 0
luafv 1 135000 0
FileInfo 3 45000 0
I posted a question to this list about this a couple of months ago, and Alex Carp responded with a suggestion:
Just to validate my theory you could try to load a simple minifilter (even the
NULL minifilter sample from the WDK should do I think) at an altitude above the
encryption range (FSFilter Compression) which should force FltMgr to expand
Frame0 to the Encryption filter range and then it will create Frame1 and put the
NULL minifilter in frame 1 and then when the AV legacy filter comes along it
will be Frame1 that will be adjusted to cover the space between the encryption
range and the AV range and then later when tmevtmgr comes along it should be
loaded in the right frame.
Alex is exactly correct! I used the “passThrough” mini-filter sample from the Vista WDK & changed it only to install it as a boot time Compression filter. On reboot, the “fltmc” output became:
Filter Name Num Instances Altitude Frame
------------------------------ ------------- ------------ -----
mfehidk 329998.99
mfehidk 2 321300.00 1
PassThrough 4 169000 1
CmgShieldCEF 149998.99
luafv 1 135000 0
FileInfo 4 45000 0
Note that this only works if the “passThrough” driver is installed with a higher altitude than CmgShieldCEF. I tried at both the Compression and Anti-Virus altitudes & it worked correctly. When I installed the sample at the Encryption altitudes (below CmgShieldCEF) the drivers were NOT loaded correctly.
This surprised me, since I could reproduce the ordering issue on a test system that had Microsoft Security Essentials installed - which is also a mini-filter loaded at the AV altitude level.
Note that I can also reproduce the ordering issue on a system that uses the “sfilter” legacy filter sample in place of CmgShieldCEF - none of my code is required to reproduce this! First, the “fltmc” output with the dummy “passThrough” driver at an Encryption altitude:
Filter Name Num Instances Altitude Frame
------------------------------ ------------- ------------ -----
mfehidk 329998.99
Sfilter 149998.99
MpFilter 4 328000 0
mfehidk 3 321300.00 0
PassThrough 4 149000 0
luafv 1 135000 0
FileInfo 4 45000 0
Moving "passThrough " to a Compression altitude causes the frames to be built correctly and the drivers to be loaded correctly:
Filter Name Num Instances Altitude Frame
------------------------------ ------------- ------------ -----
mfehidk 329998.99
MpFilter 7 328000 1
mfehidk 6 321300.00 1
Sfilter 149998.99
PassThrough 7 149000 0
luafv 1 135000 0
FileInfo 7 45000 0
It looks like we will be asking for a Compression altitude so that we can create a dummy placeholder driver in order to work around these misconfigurations.
Thanks to Alex for his suggestion - it took me a while to get around to trying it but he was spot on.
– David Consolver