FltMgr assertion #2

Can someone from MS confirm what this assertion is?

It appears that my name provider is not setting the “do not cache”
properly (it does it exactly like NameChanger sample, which (the
original sample) I did not test as of now).

*** Assertion failed: RtlEqualUnicodeString(
&foundNode->NameInfo.Name, &nameCacheNode->NameInfo.Name,
caseInsensitive )
*** Source File:
d:\w7rtm\minkernel\fs\filtermgr\filter\namecachesup.c, line 2705

Anyone seen this assert ever? (this would only happen on W7 Checked)

I’m not worried that this is a big bug, as it occurs for a specific set of files (one of them is the Windows folder)
But there are so many of them, I cannot even boot.

Does it happen without your filter? I routinely run Win7 checked in a VM and have never seen this.

No, just with it. The altitudes do nit matter at all.

Alternately, is there a way to ignore such asserts? I have not found
anything in WinDBG that would (without crashing the system).

When I check the names passed to FltCacheNames (or some such API
name…) they are of course different, but I cannot tell:

  • why it does not happen for all the files on the system (since we do
    change all the file names, including \Windows folder)
  • which name is the cached, which one is the newly retrieved one.
  • where it got which name, since it is not our GenerateFileName
    callback that generated the file names. Since this is W7, it is not
    from a file name query via
    QueryFileInformation/File(Normalized)NameInformation.

I think this is something to do with another component, most probably
vmrawdisk, when there is a name virtualization minifilter running.
I’d put the NameChanger sample for a test, but unless Program Files or
Windows folder are the ones redirected, this does not happen.
I am sure this is not a Windows system thing, because it also happens
on C:\Program FIles\VMWare\Compatibility\native path, which is not
something vanilla system driver even knows of by default.

Does it happen without your filter? I routinely run Win7 checked in a VM and
have never seen this.

There’s no way to disable the old int 3 style ASSERTs. Newer versions of Windows use NT_ASSERT so you can individually disable them with the ah command, but no such luck on Windows 7.

What are the names?

I cannot get any newer Checked build of Windows to even finish
installing. Windows 8 kinda does - but is unusable. Windows Server
2012/2016 and Windows 10 Checked builds will not finish installing at
all. And I can see I am not the only one; what’s more, I have not yet
heard of someone successfully installing those?

The few names I caught causing the problem are:
C:\Windows (which gets reparsed to C:<mydriver>\Windows)
C:\Program Files\VMWare\Compatibility\native (same as above, we need )
I cannot be sure, but this seems to be folders only!

On 5/14/19, Scott_Noone_(OSR)
wrote:
> OSR https://community.osr.com/
> Scott_Noone_(OSR) commented on FltMgr assertion #2
>
> There’s no way to disable the old int 3 style ASSERTs. Newer versions of
> Windows use NT_ASSERT so you can individually disable them with the ah
> command, but no such luck on Windows 7.
>
> What are the names?
>
> –
> Reply to this email directly or follow the link below to check it out:
> https://community.osr.com/discussion/comment/293975#Comment_293975
>
> Check it out:
> https://community.osr.com/discussion/comment/293975#Comment_293975
>

A full Windows 7 checked install runs nicely in VMware. Other releases I usually do a normal install and then just replace individual files with checked components. It’s a shame that Windows 10 makes it so difficult to get checked builds now.

What are the two names from the ASSERT though (nameCacheNode->NameInfo.Name and foundNode->NameInfo.Name)?

> A full Windows 7 checked install runs nicely in VMware.
Exactly :frowning:

What are the two names from the ASSERT though (nameCacheNode->NameInfo.Name
and foundNode->NameInfo.Name)?
As an example:
C:\MyDriver\Program Files\VMWare\Compatibility
and
C:\Program Files\VMWare\Compatibility
MyDriver is the actual name of the folder.

Weren’t you seeing name queries from filters beneath you go to your name provider? Seems like it could be related.

Not the same issue, and not the same OS (that was on x86, this is on x64).

Weren’t you seeing name queries from filters beneath you go to your name
provider? Seems like it could be related.

Surely the platform architecture (x86/x64) doesn’t matter…Did you ever bottom out the other behavior? The fact that FltMgr is trying to compare the logical and physical paths seems suspicious.

> The fact that FltMgr is trying to compare the

logical and physical paths seems suspicious.
Yep. I could not trace where it gets which path for comparison, that
is way trickier than getting the compared paths.

Surely the platform architecture (x86/x64) doesn’t matter…
I rechecked… that was an older build, so the issue of our
GenerateFileName callback being called by minifilters below us is no
longe relevant. It (that build) reparsed the paths, this build changes
them NameChanger style.
(the below comments are not important to this thread)
The reason I changed the style was primarily that I hoped it would
make a difference for the memory corruption issues I saw in the other
thread, but literally the same issue happens. I thought some component
presumes something about file names, or at last for some file names,
e.g. remembers the file name pointer, and thus it corrupts the pool.
Also NameChanger style would have allowed us to allocate a file name
in pre-create, change it, check it in post-create, free the string and
replace with the original ones, to avoid memory fragmentation.
Strangely doing the last part blew the system sooooo fast. Which leads
me to believe some component does indeed remember the file name or the
actual buffer, and presumes it to be the same either in post-create or
during the lifetime of the FO (at least for some files).

So, after some further attempts (mostly getting the driver to ignore most of I/O, so I could focus on a single folder that shows the error):

  • My Generate Name Callback is not called at all for this file, nor is the Normalizeation callback
  • The issue happens after CreatePreOp, after FltMgr calls the file system (IoCallDriver was sent to it)

For some reason, even though I specify FLT_DO_NOT_CACHE flag, FltMgr seems to cache the original file name during CreatePreOp/FltGetFileNameInformation.
My filter changes that name, by adding my prefix path, and FltMgr compares the original (without the prefix) and my file name (with the prefix) before Asserting.

This only happens when VMWare’s VMRawDisk is on the stack.

Dejan.

@Dejan_Maksimovic said:
Can someone from MS confirm what this assertion is?

It appears that my name provider is not setting the “do not cache”
properly (it does it exactly like NameChanger sample, which (the
original sample) I did not test as of now).

*** Assertion failed: RtlEqualUnicodeString(
&foundNode->NameInfo.Name, &nameCacheNode->NameInfo.Name,
caseInsensitive )
*** Source File:
d:\w7rtm\minkernel\fs\filtermgr\filter\namecachesup.c, line 2705