Message 6 of 7
08 Feb 07 15:35
Posts To This List: 2356
RE: Vista / Crash while calling FltIsDirectory
An interesting issue that this raises is that if I don't know who "owns"
the file object, I have no safe way of doing what you suggested as a
work-around. You stated:
"Until a fix for this issue is available, you should avoid calling
FltIsDirectory on file objects exposed by wimfltr. These files have
NodeTypeCode == 0x1029 in their FSRTL_ADVANCED_FCB_HEADER."
But this assumes that the owner of that file object used an
FSRTL_ADVANCED_FCB_HEADER, which isn't a requirement (and may not be
The approach *I* have taken in my own work is before doing this
validation I will carefully probe the address:
- If the region with my magic number straddles a page boundary, I know
it isn't mine since my structures never do so (but I can't say the same
about some other file system drivers structures.)
- If the address is not valid I don't want to use it. But the official
Microsoft position is that I should not use
MmIsNonPagedSystemAddressValid (see Peter Weiland's comment January 25,
2007 in NTDEV saying "Any solution which requires probing around in
memory you don't own looking for magic numbers is just plain bad,
regardless of whether it's the 'only way' you can do it.") If there's
no way to validate it, there's no way for me to safely access it (since
it might be a variant of my "index into a table" example above.) I
ignore this restriction (which requires some work on the WDK because the
function is marked as deprecated) and use it anyway.
- THEN I look at the magic number.
I do know that if *I* don't validate the file objects sent into my file
systems, my driver will die and unlike NTFS *I* will get the irate
customer call and the bug report saying "your driver crashed the system,
and see, '!analyze -v' clearly confirms that fact." If I use the
validation technique you described it will break (been there, done
that.) If I use a deprecated function I'm being ill-behaved. So, given
the current tools available and allowed it is not possible to validate a
file object. Thus, while you have offered up a pragmatic solution, it
makes assumptions that aren't necessarily true.
So the approach I've taken is similarly pragmatic, but violates the
precepts of the OS as it is currently constructed. I don't like doing
that, but there is no other way to achieve that other than assuming
"magic thinking" will keep the system from crashing.
Don't get me wrong, I appreciate the suggested work-around, but I would
suggest that those using it need to be very cautious about probing
something (a file object's FsContext pointer) that they do not own and
about which they know nothing. While the probing I propose above might
be a "bad idea" it's still better than crashing the OS in my driver,
since no amount of argument ever convinces a user that the crash wasn't
my fault when Microsoft says it is.
OSR Open Systems Resources, Inc.