"A file system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request. "
Well, golly, seems sort of scary to me; as if it weren't bad enough having keyboard hooks for any aspiring malware writer to whet their skills with, now Microsoft makes it easy for any skript kiddie to get themselves inserted between me and my data.
I realize this functionality existed before, but, gosh, it's just so EASY now. What's eye opening to me, though, is I had no idea about it; it's been around since XP!
Obviously, the first thing I did after reading about it was to see what was hanging about on my system:
Filter Name Num Instances Altitude Frame
------------------------------ ------------- ------------ -----
aswFsBlk 7 388400 0
PROCMON20 1 385200 0
aswMonFlt 9 320700 0
luafv 1 135000 0
SbieDrv 8 86900 0
FileInfo 9 45000 0
Huh. Happily, Microsoft provides a handy reference in the form of an excel spreadsheet for any 'registered' filters: http://www.microsoft.com/whdc/driver/filterdrv/alloc-alt.mspx (File System Minifilter Allocated Altitudes); aswsFsBlk belongs to... Avast. As does aswMonFlt. The amusing part is that I only use Avast to scan some large data drops... never for residential shield. (For that matter, I don't use any AV... but I also don't use IE, so... it works.). It looks like Avast needs its wedge to exist constantly. This, I think, is the final straw regarding antivirus for me; I'm tossing the lot of them (AVG, Avast, Avira... ) into a vm and scanning from there.
I mean, seriously, why does a program need a filter in place to open and read a file? When that's ALL I want it to do?
ProcMON20, of course, is Process Monitor's wedge. This one makes sense; it needs to monitor all file I/O to show me pretty screens of ACCESS DENIED. I like that.
luafv, on the other hand, belongs to Microsoft. This blog post: http://fsfilters.blogspot.com/2010/02/deal-with-luafvsys.html does an excellent job of explaining what it is, and its functionality.
However, I don't need that; I'm running as Admin, and I want my misbehaving programs to do so with wild abandon! This one was easy to get rid of; I just had to turn off UAC's virtualization.
SbieDrv is Sandboxie's wedge. This one's existence makes sense, as well --- except, again, I get annoyed at programs that keep running after I've closed them. For fun, I wanted to see if I could unload it (since it wasn't running):
C:\bin\si>fltmc unload SbieDrv
Unload failed with error: 0x801f0010
Do not detach the filter from the volume at this time.
Huh; doesn't seem I can. Certainly there must be some performance penalty, to have every filesystem api call traverse a filter chain, no? Granted, altitudes decide just what they 'see', but, still... mightn't this be just one more drop in the bucket of what made Vista such a dog?
Moving on, to the last one, we've got FileInfo. This is simply bloat. It serves both ReadyBoost and Superfetch: both of which I've disabled. (This is a decent explanation of it: http://winprogger.com/?p=971)
Despite having them disabled, this filter is still loading, and, presumably, being referenced every time filesystem I/O occurs.
Naturally, I wanted to get rid of it, so, expecting it to behave, I bopped into regedit, and set the service start type to 4... and it still started... which admittedly had me scratching my head.
(DISCLAIMER: Following random advice on the Internet is BAD. Don't do this on your own system.)
So, I took the sledgehammer approach, and simply deleted the service key altogether... and it worked!
As I type this, I get the following Kirsten Dunst Turning Japanese (NSFW) warm and tingly feeling giving result:
No filters loaded
Vunderbar! I can't say it feels faster, but I know my bits appreciate not being fondled quite as much; at least, that's what the voices in my head told me, when I was changing my tinfoil headgear.