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

Home NTFSD
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


FltMgr assertion #2

Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 327
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: 327

    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,302
    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: 327
    via Email
    No, just with it. The altitudes do nit matter at all.
  • Dejan_MaksimovicDejan_Maksimovic Member - All Emails Posts: 327
    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,302

    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: 327
    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,302

    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: 327
    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,302

    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: 327
    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,302

    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: 327
    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: 327

    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
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 30 Mar 2020 OSR Seminar Space
Developing Minifilters 15 Jun 2020 LIVE ONLINE
Writing WDF Drivers 22 June 2020 LIVE ONLINE
Internals & Software Drivers 28 Sept 2020 Dulles, VA