ZwOpenFile fails with STATUS_OBJECT_NAME_NOT_FOUND on existing file

Long time no see! I`m back with “another one” :smiley:

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

“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)” 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.

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)” 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. :expressionless:

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

@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…

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

That’s the best idea yet. Try that.

Peter

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?

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

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 …

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”.

@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.