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

Home NTDEV

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/


Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

ZwOpenFile fails with STATUS_OBJECT_NAME_NOT_FOUND on existing file

MecanikMecanik Member Posts: 34

Long time no see! I`m back with "another one" :D

I'd like to believe after all these years messing around with Win/NT API's that I know what I`m doing. However it's seem that I don't, at least in some cases.

In one of my projects I need to open some files and read them (from user-mode not kernel-mode). The error code does not make sense to me as I have checked for file existence and permissions.

My code for opening the file is as follows:

ZwOpenFile(&hFileHandle, FILE_GENERIC_READ, &FileObjectAttributes, &IoStatusBlock, FILE_SHARE_READ,
    FILE_NON_DIRECTORY_FILE | FILE_SYNCHRONOUS_IO_NONALERT | FILE_OPEN_FOR_BACKUP_INTENT | FILE_COMPLETE_IF_OPLOCKED);

Can someone please shed some light as to why this would fail randomly on random files that actually exist and permissions are not "special"?

Many thanks

A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

Comments

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    “Fail randomly”…. Well, it won’t fail randomly. It’ll fail for a specific reason. There really isn’t much randomness injected by the OS in which system service calls succeed and which fail. Except when low resource simulation is enabled in verifier.

    So… how ‘bout we start again. You give us the errors you’re getting back, an example of the actual path(s) you’re using, and a clear description of what you mean by “fail randomly”…. Then I’m willing to bet we can help you.

    Lacking that information, there isn’t much we can do…

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MecanikMecanik Member Posts: 34
    edited September 4

    @Peter_Viscarola_(OSR) said:
    “Fail randomly”…. Well, it won’t fail randomly. It’ll fail for a specific reason. There really isn’t much randomness injected by the OS in which system service calls succeed and which fail. Except when low resource simulation is enabled in verifier.

    So… how ‘bout we start again. You give us the errors you’re getting back, an example of the actual path(s) you’re using, and a clear description of what you mean by “fail randomly”…. Then I’m willing to bet we can help you.

    Lacking that information, there isn’t much we can do…

    Peter

    Absolutely, my bad for not providing some path/file. Error wise it is the only error I am getting, nothing else.

    The project has a feature which is antivirus-like functionality so I open files under _\??\C:\Windows\system32\drivers\ _in this example.

    One path+file example: ??\C:\Windows\system32\drivers\HWiNFO64A.SYS

    As the name suggests, this is a driver for HWID info software. The file is there and exists. The full path is obtained from iterating the existing loaded drivers in this example.

    Why I said "randomly"; I have no idea. What I should have said is "specific" files, like the one above.

    The code I`m using is able to open any .SYS files for reading in general, however "some" fail with STATUS_OBJECT_NAME_NOT_FOUND.

    I cannot imagine it would be a case of "file in use" or "wow64" redirection; maybe I am wrong? You are the experts, I will leave you to comment on that.

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    Well, hmmmm...

    The file is there and exists

    You can list it with "dir"?

    Is it a hard link or something else strange?? You can us PS to determine this this:

    dir 'c:\windows\system32\drivers\hwinfo64a.sys'| ?{$_.LinkType} | select FullName,LinkType,Target

    "some" fail with STATUS_OBJECT_NAME_NOT_FOUND

    I wonder if these are sym links that point to non-existent files... or something??

    Good question...

    Peter Viscarola
    OSR
    @OSRDrivers

  • MecanikMecanik Member Posts: 34

    @Peter_Viscarola_(OSR) said:
    Well, hmmmm...

    The file is there and exists

    You can list it with "dir"?

    Is it a hard link or something else strange?? You can us PS to determine this this:

    dir 'c:\windows\system32\drivers\hwinfo64a.sys'| ?{$_.LinkType} | select FullName,LinkType,Target

    "some" fail with STATUS_OBJECT_NAME_NOT_FOUND

    I wonder if these are sym links that point to non-existent files... or something??

    Good question...

    Thank you, unfortunately this returns nothing for this file. If I try it on another file it returns results.

    The file on disk: https://prnt.sc/1r86khx

    I cannot comprehend what wizardry is this, the file is there and loaded into the system as well. :|

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,445
    via Email
    Well it is just a guess, but my guess is that the company that sells
    hwinfo64.sys is doing something to block access to their driver. I would
    turn procmon on and look at what is going on in real-time. Whatever they
    are doing seems wrong.

    Mark Roddy
  • MecanikMecanik Member Posts: 34

    @Mark_Roddy said:
    Well it is just a guess, but my guess is that the company that sells
    hwinfo64.sys is doing something to block access to their driver. I would
    turn procmon on and look at what is going on in real-time. Whatever they
    are doing seems wrong.

    Mark Roddy

    I`m not arguing that, however there are several drivers that give the same result. Asus, AMD, plenty more...

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,663

    I would turn procmon on and look at what is going on in real-time.

    That’s the best idea yet. Try that.

    Peter

    Peter Viscarola
    OSR
    @OSRDrivers

  • MecanikMecanik Member Posts: 34
    edited September 5

    Well, this is embarrassing. I've made a small console app (x86) to test this with procmon and the particular file mentioned here started to "open" magically.

    So I tested with another one with the same issue:

    High Resolution Date & Time: 05/09/2021 07:58:58.4208836
    Event Class:    File System
    Operation: IRP_MJ_CREATE
    Result: NAME NOT FOUND
    Path: C:\Windows\SysWOW64\drivers\AsIO2.sys
    TID:    1196
    Duration: 0.0000212
    Desired Access: Generic Read
    Disposition: Open
    Options:    Synchronous IO Non-Alert, Non-Directory File, Complete If Oplocked
    Attributes: n/a
    ShareMode: Read
    AllocationSize: n/a
    

    Am I just being stupid... or what the heck does wow64 redirection have to do with this?

    Post edited by Mecanik on

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

  • Justin_SchoenwaldJustin_Schoenwald Member - All Emails Posts: 27

    I had similarly inexplicable file access/visibility issues - my only note regarding solution was "Application Experience service must run or errors with file cache" (?)

  • craig_howardcraig_howard Member Posts: 182
    edited September 5

    The Wow64 dll redirection is one of those things that if it all works well then it's magic, if it doesn't, well, then you're in a special world of hurt. Here's some background on it [ https://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/64-bit+File~Redirection.txt ], do some GoogleFu on "wow64 dll redirection" for lot's of more info on this ...

    Usually you don't run into these problems because the app and dll's are all linked to the same platform (x64 or x86) so it never comes up ... you can, however, somehow manage to link in a library on an x86 application that is only x64 and then you've got trouble (so I would check my linker path and libraries)

    The other interesting issue is that you're calling the driver from an x86 client (note that the driver is labeled 'hwinfo64.sys') and the driver is likely an x64 driver. This could also be an issue with DLL sideloading, which is normally a malware technique but has some legitimate uses [ https://stackoverflow.com/questions/108971/using-side-by-side-assemblies-to-load-the-x64-or-x32-version-of-a-dll ] and you might be accidentally doing a sideload of your application system dll's

    Although x64 drivers can communicate with x86 clients, it sometimes causes problems (and I flat out disallow any x86 application IOCTL access with my drivers, create/close/read/write is as far as they can go) ... if you haven't already, do a pure x64 build of your client and run procmon; that will eliminate any x86 dll's in the mix ...

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,093

    Well, if a 32-bit process tries to open "C:\Windows\System32\Drivers", it will not find anything there. The path gets rewritten to SysWOW64, where there are no drivers. Is that what you were doing? You can turn that off with the bizarrely named Wow64DisableWow64FsRedirection, or you can read from "C:\Windows\SysNative\Drivers".

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • MecanikMecanik Member Posts: 34
    edited September 6

    @craig_howard said:
    The Wow64 dll redirection is one of those things that if it all works well then it's magic, if it doesn't, well, then you're in a special world of hurt. Here's some background on it [ https://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.web+WinBatch/64-bit+File~Redirection.txt ], do some GoogleFu on "wow64 dll redirection" for lot's of more info on this ...

    Usually you don't run into these problems because the app and dll's are all linked to the same platform (x64 or x86) so it never comes up ... you can, however, somehow manage to link in a library on an x86 application that is only x64 and then you've got trouble (so I would check my linker path and libraries)

    The other interesting issue is that you're calling the driver from an x86 client (note that the driver is labeled 'hwinfo64.sys') and the driver is likely an x64 driver. This could also be an issue with DLL sideloading, which is normally a malware technique but has some legitimate uses [ https://stackoverflow.com/questions/108971/using-side-by-side-assemblies-to-load-the-x64-or-x32-version-of-a-dll ] and you might be accidentally doing a sideload of your application system dll's

    Although x64 drivers can communicate with x86 clients, it sometimes causes problems (and I flat out disallow any x86 application IOCTL access with my drivers, create/close/read/write is as far as they can go) ... if you haven't already, do a pure x64 build of your client and run procmon; that will eliminate any x86 dll's in the mix ...

    Thank you for your input, I do know however what WOW64 is... in fact I have been dealing with it for a long time because I make complex system calls through it. What I do not understand is why "some" drivers fail only due to this error, so I went to _C:\Windows\SysWOW64\drivers_ and I found only 4 drivers there; the ones always failing to open.

    @Tim_Roberts said:
    Well, if a 32-bit process tries to open "C:\Windows\System32\Drivers", it will not find anything there. The path gets rewritten to SysWOW64, where there are no drivers. Is that what you were doing? You can turn that off with the bizarrely named Wow64DisableWow64FsRedirection, or you can read from "C:\Windows\SysNative\Drivers".

    I tend to disaggree? From 250+ drivers loaded on my x64 system, I can open them all from user-mode just fine with ZwOpenFile directly. The ones failling are because the developers copied the drivers to C:\Windows\SysWOW64\drivers\ as well.

    Why, it beats me. It's an x64 system, having "wow64" drivers make no sense.

    Checking the HWiNFO64A.SYS loaded into the system I can see 2 of them loaded: https://prnt.sc/1rd4bjq

    https://prnt.sc/1rd4fm3
    https://prnt.sc/1rd4hd1

    Nevertheless I was able to resolve this issue from the x86 app by disabling redirection (RtlWow64EnableFsRedirectionEx...).

    However I still do not understand what is going on, I understand the situation about DLL's but not drivers.

    A5EF6AC930666A823A905224B7829A417718CA3360E62B9F890B722B20B8BDA5AE187C20E8F7070EADC6B82998999F02

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers TBD Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online