Registry Filter: Corrupt PostInformation->PreInformation->ObjectContext when *other* registry filter

NTFSD
1

This is not a filesystem issue per se, but more registry filter types hang
out here than anywhere else.

I have just got through chasing an interop bug with a client’s registry
filter.

The symptom I see (once I’ve got around the other filter’s anti-debugging
trap) is that in post call (SetValue and QueryKey) the value of
PostInformation->PreInformation->ObjectContext is no longer valid (it’s
null). This causes my driver a few issues because I get a mismatch between
precalls and postcalls.

Tracing this through, it happens because CmpCallCallBacks is calling in to
CmpCallbackFillObjectContext with the wrong cookie value.
CmpCallbackFillObjectContext is getting the PreInformation block for my
filter, but the cookie for the other filter. The other filter doesn’t have
an object context, so CmpCallbackFillObjectContext just returns NULL which
goes into the field which ends up as
PostInformation->PreInformation->ObjectContext.

AFAICS, all the other structures make sense - the CMcb list of filters and
the CMcc list of object contexts looks OK.

Now here’s the key point:

The other registry filter has registered itself with an altitude of “\0”
(that is to say the altitude which should be numeric is a string with one
null character in it). If I build a null registry filter at that altitude I
get exactly the same behavior.

I’m hoping that my fix is simple - never rely on
PostInformation->PreInformation->ObjectContext.

I couldn’t any mention of this behavior when I Googled for it, so I’m
putting in this note so that perhaps other will find it.

Also a plea: if anyone is in a position to fix this within Windows I’d
appreciate it. Can we either reject bogus altitudes, or at least keep the
handling consistent.

Thanks

–
Rod Widdowson
Consulting Partner
Steading System Software LLP
+44 1368 850217 +1 508 915 4790

2

> The other registry filter has registered itself with an altitude of

“\0”
What was the attempt of this driver writer anyways? To attach closest to the
Configuration Manager?

Regards,
Ayush Gupta
AI Consulting

3

Who knows? But that was my guess. I have reached out to the devs in
question and more may turn up.

I was surprised that this particular drive should even need to have a
registry filter, but I’m often surprised…

“Ayush Gupta” wrote in message news:xxxxx@ntfsd…
>> The other registry filter has registered itself with an altitude of
>> “\0”
> What was the attempt of this driver writer anyways? To attach closest to
> the
> Configuration Manager?
>
> Regards,
> Ayush Gupta
> AI Consulting
>
>