I have a minifilter with two instances. The first one is manually attached via a call to FilterAttach, and the second one auto-attaches to all volumes (instance Flags registry value is set to 0).
I have come across a Server 2016 computer where the auto-attaching is failing - the second instance doesn’t show it is attached to any volumes if I check in fltmc.exe. Fine, I’ll just manually call FilterAttach on this instance like I do for the first instance. Except in this case FilterAttach is failing with 0x80070032 which is apparently “The request is not supported”.
These two instances have been working fine everywhere else I’ve tried them. Manually calling FilterAttach on the failing instance (after first changing the registry so it doesn’t auto-attach) works fine on other Windows servers. On the Server 2016 computer the parameters to the FilterAttach are the same (i.e. just attaching to the basic \Device\HarddiskVolume1) in working and non-working cases, other than the instance name.
It seems like perhaps there is some sort of configuration setting on this Server 2016 that is preventing the second instance from attaching, but nothing is coming up in any searches I can think of. Other filters like WdFilter are able to have multiple attachments.
Is there any way to get more information about why the attachment is failing other than that error code?
No, InstanceSetup is not called for the failing instance. I tried attaching directly with fltmc.exe attach [driver] [volume] [-i instance] and get the same 0x80070032 error code. Works great with the other instance, and both are completely implemented within the same driver .sys file.
Can’t imagine what is different with this one server.
Rod, I was wondering the same thing as I drifted off to sleep last night, but forgot to check until I read your guess above, so thanks for the reminder. Unfortunately, I can’t see anything wrong in the registry
Just to be sure I understand about the altitudes, my main/working instance has altitude 12345 (don’t remember the actual value), and the second instance that doesn’t work is using 12345.100. That’s OK, right?
The procmon idea lead to something even stranger - as soon as procmon starts, the failing instance is able to load. I thought that seemed unlikely so rebooted and sure enough, the instance won’t load until I start procmon, then it attaches to the volume like normal.
I’m just trying to attach it to \Device\HarddiskVolume1 (C: drive)
Just found out something really interesting - maybe a bug?
On the server where I’m seeing this my filter ends up being the highest filter (it’s pretty high because it’s an activity monitor). All the computers where everything works fine have a higher filter (backup filter like veeam or something else even higher). Importantly, ProcMon’s filter also loads higher when it is there.
Recall that the altitude of WorkingFilter is X, and FailingFilter is X.1. If I change FailingFilter’s altitude to X-1, then it loads fine. If I change it to X+1, it fails.
But if there is some other filter loaded above it, X.1, X+1 and X-1 all work fine. So my hypothesis is that a filter instance can’t load if the filter is the highest, and the instance’s altitude is higher than the default instance’s altitude.
