Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Sept/Oct 2019 Issue of The NT Insider available


Download PDF here: http://insider.osr.com/2019/ntinsider_2019_01.pdf

It’s a particularly BIG issue, too: 40 pages of technical goodness, ranging from WDF to Minifilters. Check it out.
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

FltMgr assertion #2

Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
via Email in NTFSD
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

Comments

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244

    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.

  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,183
    Does it happen without your filter? I routinely run Win7 checked in a VM and have never seen this.

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
    via Email
    No, just with it. The altitudes do nit matter at all.
  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
    via Email
    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.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,183

    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?

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
    via Email
    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:\\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
    >
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,183

    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)?

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
    via Email
    > A full Windows 7 checked install runs nicely in VMware.
    Exactly :(
    > 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.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,183

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

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
    via Email
    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.
  • Scott_Noone_(OSR)Scott_Noone_(OSR) Administrator Posts: 3,183

    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.

    -scott
    OSR

  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244
    via Email
    > 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).
  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 244

    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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Writing WDF Drivers 21 Oct 2019 OSR Seminar Space & ONLINE
Internals & Software Drivers 18 Nov 2019 Dulles, VA
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 27 Apr 2020 OSR Seminar Space & ONLINE