Better/normal filter manager (fltmgr.sys) for XP_SP3

[modnar]

I started with this research rather late - in 2023, original problem has been introduced with XP_SP3 release, so in 2008 - quite nasty really:

I have experimented with Diskeeper (2010, 2011, 12) and Avast filters in XP_SP3, because the way at least Avast (its filter drivers) is set up does slow down the system (its aswSP is at altitude 388401 but group is set as FSFilter Security enhancer, which is at much lower altitude range). With any program that "lies" thusly to XP_SP3 the computer gets bogged down for a nit-picking reason (IMO).
I have found out that just for the XP_SP3 M$ really messed up fltMgr driver to require a mini-filter
to really obey it's "Group"'s altitude range, which is quite a bit different than in XP_SP2 or Vista and newer Windows.
Therefore I would like to know if there is a newer fltMgr.sys driver (or a modification) that allows "normal" (not so restrictive) mini-filter behaviour (basically altitude freedom) for XP_SP3?
Example: DKRtWrt mini-filter is usually at 137100 (its native altitude as per M$'s own list) in XP_SP2 even though it's "Group" is "Activity Monitor", but can't be in XP_SP3 and its restrictive fltmgr - it's unstoppable (manually) then.
Current version is 5.1.2600.5512. I tried transplanting it with Vista's (doesn't work) and XP_SP2 (works but lacks certain functionality for Avast to work properly).

A working, perhaps temporary, solution by me was to re-classify aswSP as FSFilter Activity monitor (as was in old Avast 11 AV), add missing filter groups of virtualization and imaging to xp's GroupOrderList and ServiceOrderGroup/List (registry CurrCtrlSet) now all works well, however the nagging question remains - why should XP_SP3 be an exception - is it to further disable it in light of higher versions of the OS? I sure think so.

[modnar]

Update: Yesterday I reinstalled Avast and today I have removed both FSFilter Virtualization and Imaging from the above mentioned places in Current Control Set.

Filter manager in XP is so old it simply doesn't recognize these two groups and filter communication suffers (as seen in DK12's time to prevent fragmentation using Intelliwrite and Instant defrag and general web browsing).

AswSP service is left as factory FSFilter Security Enhancer and I set aswSnx (virtualization service) to FSFilter Security Enhancer (XP's native group). First impressions are good, web browsing is smoother than before, we'll see.

DKService can be stopped normally (and restarted) but DK12 uninstall requires aswSP (self-defense) to be disabled due to group-altitude "stretching" of the above services, so DKTLFSMF filter can be stopped normally.

Update: It's better to just set aswSP and aswSnx as FSFilter Activity Monitor, with also changing aswSnx altitude to 366996 for smoother system operation and no lying to the touchy-feely fltmgr.

Edited March 9 by modnar

[ED_Sln]

Have you tried the version from Server 2003? It will probably work with XP. Maybe the filter works differently in it, it's a Server after all.

 

[modnar]

I tried it a while ago, but it was from vista, not 2k3 - I actually tested it today and it works on XP without a problem. As with 2k3 I also enabled AttachWhenLoaded for fltmgr service (in registry) as it is on Win2k3 and now I have to do extensive testing to see if it's safe for data and stable in all circumstances. Should be...

It looks mighty promising. E.g.: DKService ("12") can easily be stopped with its DKRtWrt filter at its native altitude of 137100. Wow wow wow, just wow. That means no more artificial hitching on XP just because a program uses low altitude filters like antiviruses with virtualization like to do. I'm just 10+ years too late... Oh well better now than never. Long live XP, yet!

Edited March 11 by modnar
correction

[modnar]

Quite an update: XP fltmgr (5.1.2600.5512) replaced (on real computer) with 2003 version from SP2 (R2) (5.2.3790.3959), no updates (simple is good). AttachWhenLoaded has to be 0 (XP default).

DK12's DKTLFSMF I set at 137100, so it has a broader view and can then better guide DKRtWrt at 137102 to rightly write things down.

While the above works, it is not really balanced; sometimes Serpent crashes due to write request conflicts. I guess we'll have to wait for ReactOS's fltMgr or the whole OS to really be able to have a decent solution for our elderly and neglected system while at Microsoft their collective heads are further up their arse-s.

Edited April 16 by modnar
Update