Procmon (v3.53) not seeing NtCreateFile() call RRS feed

  • Question

  • This is a somewhat complex situation that I'll try to describe as concisely as possible.

    I've been using Procmon (v3.53) to try to debug an issue where an MSI install as a non-admin user (verified with multiple separate msi's) fails when that user has a redirected roaming profile.[1]  (All of this on a fully patched Windows 10 version 2004 system, with Windows Installer version 5.0.19041.1) 

    Specifically, the installer fails trying to create the directory z:\AppData\Microsoft\Installer (where z: is a mapped network share)  Using WinDbg, I was able to prove that msiexec.exe (the service process that runs as SYSTEM, though it impersonates the user running the installer during the problematic behavior) ultimately calls CreateDirectoryW() for the above-mentioned directory.  In turn, CreateDirectoryW() calls NtCreateFile() (with all the appropriate arguments as far as I can tell, ie. FILE_DIRECTORY_FILE and FILE_CREATE) which disappears into the kernel (kernel debugging is beyond my current ability) and ultimately returns error status 0xc000003a. (Path Not Found)

    I hoped Procmon could give me additional visibility here (since it can provide kernel stack traces) but strangely, it doesn't show this particular NtCreateFile() call.  I even tried both raising (to 409999) and lowering (to 140000) procmon's filter altitude (and rebooting and verifying the change with fltmc) in the hopes that would allow procmon to see this particular NtCreateFile() call, but to no avail.

    This being the first time I've encountered file system activity that Procmon can't see, I figured I'd report it.

    If there's any additional info that would be useful, please let me know and I'll be happy to provide it.


    - Chris

    1. More information about this issue can be found at these posts (not mine, but describing the exact issue):

    • Edited by adiemu5 Tuesday, August 11, 2020 8:49 PM Provide the actual links
    Saturday, August 8, 2020 5:19 AM

All replies

  • Probably some other driver is "eating" the call blocking it...

    If you are familiar with fltmc, try disabling one by one those drivers in the kernel (using autoruns) and at each driver disabled perform a reboot and test again until you find the driver which is blocking the call..


    Sunday, August 9, 2020 9:13 AM
  • Mario,

    Thanks for the suggestion.  While I understand the mechanics of what you're suggesting (basically just disabling the services for those filter drivers one by one, rebooting after each), I don't know enough about Windows to know if we can safely do that as all of them show up in AutoRuns as being part of Windows.  (We've already completely disabled our endpoint protection on this isolated test box, which is why its filters don't show up)  Specifically:

    > fltmc
    Filter Name                     Num Instances    Altitude    Frame
    ------------------------------  -------------  ------------  -----
    bindflt                                 0       409800         0
    storqosflt                              0       244000         0
    wcifs                                   0       189900         0
    CldFlt                                  0       180451         0
    FileCrypt                               0       141100         0
    luafv                                   1       135000         0
    npsvctrig                               1        46000         0
    Wof                                     3        40700         0
    FileInfo                                4        40500         0

    Can we safely disable all of these and still expect the system to boot/work?  Or are there some we should leave?

    And if the issue is one of these eating the call, shouldn't having run Procmon both at the very highest altitude (ie, above everything) and the very lowest altitude (ie, below everything) have shown something?  Or am I misunderstanding how altitudes and/or the filter stack work?



    • Edited by adiemu5 Monday, August 10, 2020 5:07 PM
    Monday, August 10, 2020 5:04 PM