Need help finding the reason for "access denied" with .kdfiles

WINDBG
1

Hi,

to improve my workflow I decided to give .kdfiles a try again.

I noticed that the path expected in the mapping seems to require the
same path (case-insensitive) as is given under
HKLM\SYSTEM\CurrentControlSet\Services for the respective driver. So
instead of \SystemRoot\System32 I am passing ??\C:\Windows\system32 as
the prefix. The difference is that now I actually get to see something
from .kdfiles whereas before apparently it failed to match anything.

My map file looks like this:

map
??\C:\Windows\system32\Drivers\foo.sys
D:\foo.sys

and I ran .kdfiles again to make sure that the mapping took effect (it did).

However, when booting my target machine I see the following in the
Command Output pane of WinDbg:

KD: Accessing ‘D:\foo.sys’ (??\C:\Windows\system32\Drivers\foo.sys)
File size 264KKdPullRemoteFile(87DF14C0): About to overwrite
??\C:\Windows\system32\Drivers\foo.sys and preallocate to 42000
KdPullRemoteFile(87DF14C0): Return from ZwCreateFile with status c0000022

WARNING: No file I/O done by target, .kdfiles files may not be updated

Is there a way by which I can track down why I am receiving
STATUS_ACCESS_DENIED here?

Thanks,

// Oliver

PS: The target is Windows 7 Enterprise SP1 x86 (checked build), the host
running WinDbg is Windows 7 SP1 x64 (free build). WinDbg is version
10.0.10586.567 AMD64.

C:\Windows\System32\drivers>icacls foo.sys
foo.sys NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Users:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

2

Finding the right name to put in the map file is always a pain. My trick is
to set a breakpoint at the start of KdPullRemoteFile. The first argument is
a PUNICODE_STRING with the name that much match the one in your map file.
The steps for this trick are here:

https://www.osr.com/nt-insider/2014-issue3/updating-drivers-kdfiles/

As for the access denied…

Very strange. For some reason the kernel can’t open the file on your target
machine. Given that it’s a call to ZwCreateFile it should “just work”… I’d
say you could run Process Monitor on the target, but I’m afraid that it
won’t tell you anything more than “the call is failing with access denied.”
Any weird file system filters?

The ultimate hammer is to use the NTFS status debugging trick to figure out
if/where NTFS is returning access denied:

eb Ntfs!NtfsStatusDebugEnabled 1
ed Ntfs!NtfsStatusBreakOnStatus 0xc0000022

Going from here to the answer takes a good deal of spelunking. But, if you
hit the breakpoint and print the call stack maybe we can come up with some
more guesses.

-scott
OSR
@OSRDrivers

“Oliver Schneider” wrote in message news:xxxxx@windbg…

Hi,

to improve my workflow I decided to give .kdfiles a try again.

I noticed that the path expected in the mapping seems to require the
same path (case-insensitive) as is given under
HKLM\SYSTEM\CurrentControlSet\Services for the respective driver. So
instead of \SystemRoot\System32 I am passing ??\C:\Windows\system32 as
the prefix. The difference is that now I actually get to see something
from .kdfiles whereas before apparently it failed to match anything.

My map file looks like this:

map
??\C:\Windows\system32\Drivers\foo.sys
D:\foo.sys

and I ran .kdfiles again to make sure that the mapping took effect (it did).

However, when booting my target machine I see the following in the
Command Output pane of WinDbg:

KD: Accessing ‘D:\foo.sys’ (??\C:\Windows\system32\Drivers\foo.sys)
File size 264KKdPullRemoteFile(87DF14C0): About to overwrite
??\C:\Windows\system32\Drivers\foo.sys and preallocate to 42000
KdPullRemoteFile(87DF14C0): Return from ZwCreateFile with status c0000022

WARNING: No file I/O done by target, .kdfiles files may not be updated

Is there a way by which I can track down why I am receiving
STATUS_ACCESS_DENIED here?

Thanks,

// Oliver

PS: The target is Windows 7 Enterprise SP1 x86 (checked build), the host
running WinDbg is Windows 7 SP1 x64 (free build). WinDbg is version
10.0.10586.567 AMD64.

C:\Windows\System32\drivers>icacls foo.sys
foo.sys NT AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Users:(I)(RX)

Successfully processed 1 files; Failed processing 0 files

3

For mapping files correctly CTRL-ALT-D in the debugger is very helpful. See https://msdn.microsoft.com/en-us/library/windows/hardware/ff552148(v=vs.85).aspx for more info.

Access denied may also be because the file is already open by something else.

4

Hi,

thanks.

On 2016-06-23 15:57, xxxxx@microsoft.com wrote:

For mapping files correctly CTRL-ALT-D in the debugger is very helpful. See https://msdn.microsoft.com/en-us/library/windows/hardware/ff552148(v=vs.85).aspx for more info.
Have used that before, but didn’t think of it for this issue.

Access denied may also be because the file is already open by something else.
Is that very likely? This is during early boot and the drivers whose
files are being replaced are mini-FSFD (well, one is, the other is
essentially a supplement to the former).

Thanks for your insight,

// Oliver

5

Hi Scott,

thanks for the answer.

On 2016-06-23 14:57, Scott Noone wrote:

Finding the right name to put in the map file is always a pain. My trick
is to set a breakpoint at the start of KdPullRemoteFile. The first
argument is a PUNICODE_STRING with the name that much match the one in
your map file. The steps for this trick are here:

https://www.osr.com/nt-insider/2014-issue3/updating-drivers-kdfiles/
Another list member whose message apparently got filtered or moderated
contacted me off-list and told me that he’s using another trick: leaving
off anything before System32\.

Amazingly I found that indeed without either of the possible prefixes:

* \SystemRoot or
* ??\C:\Windows

the .kdfiles mapping would be picked up on an access of the file.
Issuing .kdfiles in the debugger still showed the mapping without the
prefix, whereas the output of the kernel debugger indicated that it
“magically” picked the correct prefix for my case:

KD: Accessing ‘D:_foo\win32\release\foo.sys’
(??\C:\Windows\system32\Drivers\foo.sys)
File size 137KKdPullRemoteFile(87DFE020): About to overwrite
??\C:\Windows\system32\Drivers\foo.sys and preallocate to 22400
KdPullRemoteFile(87DFE020): Return from ZwCreateFile with status c0000022

WARNING: No file I/O done by target, .kdfiles files may not be updated

As for the access denied…

Very strange. For some reason the kernel can’t open the file on your
target machine. Given that it’s a call to ZwCreateFile it should “just
work”… I’d say you could run Process Monitor on the target, but I’m
afraid that it won’t tell you anything more than “the call is failing
with access denied.” Any weird file system filters?
Hmm, I’ll see whether ProcMon can give me any insight that early during
the boot process.

The ultimate hammer is to use the NTFS status debugging trick to figure
out if/where NTFS is returning access denied:

eb Ntfs!NtfsStatusDebugEnabled 1
ed Ntfs!NtfsStatusBreakOnStatus 0xc0000022
Thanks, a new trick in my tool chest!

Going from here to the answer takes a good deal of spelunking. But, if
you hit the breakpoint and print the call stack maybe we can come up
with some more guesses.
If I succeed with it, I’ll get back to this thread with a call stack.

Last but not least I think I found a possible explanation. For example I
had accidentally tried first to overwrite the free build with a checked
build. However, later I ended up being able to overwrite the checked
build (copied in after the target system was up) on next boot. My hunch
is that the file sizes could play a role. The checked builds are of
course quite a bit bigger than the free builds.

Thanks for your insight,

// Oliver

6

On the host PC the access denied may result from the file being open by another tool. Different but slightly related, in that past with older versions of WinDbg it has held PDB’s open with exclusive access on the host machine, which could prevent tools on the host machine from recompiling.

If your driver is marked with a start type as boot, then you will need to enable the boot debugger so KdFiles can replace the driver while the OS loader is loading the driver:
Bcdedit /bootdebug on