Legacy filters being loaded out of order

NTFSD
1

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 the affected systems is:

(New) Case 30831 (Customer A - Windows 7)

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

(New) Case 31611 (Customer B - Windows 7)

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

(Old) Case 27918 (Customer C - Windows 7 SP1)

Filter Name Num Instances Altitude Frame
------------------------------ ------------- ------------ -----
symsnap 429998.99
CmgShieldCEF 149998.99
tmevtmgr 4 328510 0
luafv 1 135000 0
FileInfo 4 45000 0

Note that in these cases, all legacy filters (including our CmgShieldCEF) are being loaded above all minifilters regardless of altitude.

What we should be seeing is (Windows 7 SP1):

Filter Name Num Instances Altitude Frame
------------------------------ ------------- ------------ -----
MpFilter 4 328000 1
CmgShieldCEF 149998.99
luafv 1 135000 0
FileInfo 4 45000 0

An old thread post (http://www.osronline.com/showThread.cfm?link=82872) by Neal Christiansen implies that this could be caused by improper service GROUP, TYPE, and START values. I have checked & I do not think that this problem is that simple.

Load Order Values:

CmgShieldCEF:
GROUP: FSFilter Encryption
TYPE: SERVICE_FILE_SYSTEM_DRIVER
START: SERVICE_BOOT_START

mfihidk: Altitude: 321300
GROUP: FSFilter Encryption
TYPE: SERVICE_KERNEL_DRIVER
START: SERVICE_BOOT_START

tmevtmgr: Altitude: 328510
GROUP: Extended Base
TYPE: SERVICE_KERNEL_DRIVER
START: SERVICE_AUTO_START

What I need to know is: If the system can be mis-configured into behaving this way, or if anyone has any suggestions on what needs to be changed in order to force the correct load ordering (with the limitation that I don’t want to modify the installation of 3rd party drivers.)

Any assistance here would be greatly appreciated!

– David Consolver

2

I’m sorry but are you sure that you’re getting the right GROUP in the list above ? The reason i’m asking is that based on the name and the altitude of the drivers i believe that mfihidk (McAfee?) and tmevtmgr (Trend Micro?) are anti-virus filters and yet their groups appear to be FSFilter Encryption and Extended Base, which doesn’t make much sense to me… Could you please copy&paste the service reg key for the drivers (both the AVs and yours)?

Thanks,
Alex.

3

I was fairly careful, but I may have made a mistake.

Here are the registry values for CmgShieldCEF (the driver that I have control over) and tmevtmgr (a driver that I do NOT have control over):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\CmgShieldCEF]
@=“”
“EnableSDEReversionMsgs”=dword:00000000
“EnableW2kMode”=dword:00000001
“Type”=dword:00000002
“Start”=dword:00000000
“ErrorControl”=dword:00000001
“Tag”=dword:00000005
“ImagePath”=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\
52,00,49,00,56,00,45,00,52,00,53,00,5c,00,43,00,4d,00,47,00,53,00,68,00,43,\
00,45,00,46,00,2e,00,73,00,79,00,73,00,00,00
“DisplayName”=“CmgShieldCEF”
“Group”=“FSFilter Encryption”
“Description”=“CREDANT Encryption Filter Driver”
“UnlockHWM”=dword:00000001
“EncryptPF”=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\tmevtmgr]
“Type”=dword:00000001
“Start”=dword:00000002
“ErrorControl”=dword:00000001
“Tag”=dword:0000001a
“ImagePath”=hex(2):73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,44,00,\
52,00,49,00,56,00,45,00,52,00,53,00,5c,00,74,00,6d,00,65,00,76,00,74,00,6d,\
00,67,00,72,00,2e,00,73,00,79,00,73,00,00,00
“DisplayName”=“tmevtmgr”
“Group”=“Extended Base”
“DependOnService”=hex(7):74,00,6d,00,63,00,6f,00,6d,00,6d,00,00,00,00,00
“Description”=“Trend Micro Event Manager Driver”
“Version”=“2.86.0.1002”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\tmevtmgr\Instances]
“DefaultInstance”=“TmEvtMgr Instance”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\tmevtmgr\Instances\TmEvtMgr Instance]
“Altitude”=“328510”
“Flags”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\tmevtmgr\Parameters]
“DisablePrefetchIdentify”=dword:00000000

– David Consolver

4

Ok, I can’t see nothing to explain that in the service keys.

How do you attach your filter ? Do you auto attach (from DriverEntry attach to all the file systems and so on…) or do you wait for some user mode process to tell you which volume to attach to ?

Thanks,
Alex.

5

Wow - the attach code is so old it has been years since I even thought about it…

All *interesting* file systems are attached to automatically. There is no user mode directed attaching going on.

DriverEntry calls IoRegisterFsRegistrationChange to establish a file system notification handler.

Our file system notification handler attaches to all FILE_DEVICE_DISK_FILE_SYSTEM and FILE_DEVICE_CD_ROM_FILE_SYSTEM file systems. We then construct our device object and attach it to the device object that was supplied by the callback using IoAttachDeviceToDeviceStack. This attaches us to the file systems (“\Ntfs”, “\FileSystem\CdfsRecognizer”, and such.)

Attaching to the file systems allows us to see the volume mounts through IRP_MN_MOUNT_VOLUME. On successful volume mounts, we create our device object and use IoAttachDeviceToDeviceStack to attach it to the volume.

– David Consolver

6

Hi David,

I have an idea about what the problem is. IN all the examples you posted there is a legacy filter right above your filter. What i think is going on is that FltMgr creates Frame0, then your filter attaches and then the legacy AV filter attaches. I’m guessing there is no minifilter attaching between your filter attaching and the legacy AV attaching and so when the next minifilter comes into picture and it tries to load at an altitude that would be above your filter FltMgr will look at the topmost legacy filter (which is the AV filter) and will adjust the upper altitude of frame0 to be the same as that of the legacy filter. Then later when a minifilter attaches (in your case tmevtmgr) it will still attach in frame0 because that’s the altitude range frame0 has.

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.

I’ve also written a blog post about how FltMgr’s frame altitude adjustment mechanism works (http://fsfilters.blogspot.com/2011/11/controlling-load-order-of-file-system.html). Please let me know if this makes sense.

Thanks,
Alex.

7

Alex,

Thank you for the suggestion & the blog post. I will give your suggestion a try in the next couple of days & report back.

Of course, I am still open to any other thoughts that anyone has on this issue.

– David Consolver