How to delete this file? (Windows 10 RS3 - 16299)

NTFSD
1

Hi,

I got a strange situation from the file system point of view. After update to Windows 10 RedStone3, I wanted to delete the C:\Windows.old directory. It turned out I can’t because of this file:

c:\Windows.old\WINDOWS\System32\DriverStore\FileRepository\nv_dispiwu.inf_amd64_9ff5ab165faead52\nvlddmkm.sys

The call to NtOpenFile(with FILE_DELETE_ON_CLOSE) returns STATUS_CANNOT_DELETE. I played with FileTest a bit and found out that the file has two hardlinks:

  1. c:\Windows\System32\DriverStore\FileRepository\nv_dispiwu.inf_amd64_9ff5ab165faead52\nvlddmkm.sys
  2. c:\Windows.old\WINDOWS\System32\DriverStore\FileRepository\nv_dispiwu.inf_amd64_9ff5ab165faead52\nvlddmkm.sys
  • The file has NULL DACL
  • The file is not currently in use - checked by NtQueryInformationFile(FileProcessIdsUsingFileInformation)
  • Volume scan found no (read: zero) errors

So why I cannot remove the second hardlink using NtSetInformationFile(FileDispositionInformation)?

2

You can get STATUS_CANNOT_DELETE if it has an active image section. Is the
driver loaded? You can try running drivers.exe and see if it’s listed.

-scott
OSR
@OSRDrivers

3

Hi, Scott,

confirmed. I didn’t realise that since certain Windows version, drivers are locked that way.
The “nvlddmkm.sys” driver is indeed in the list of loaded kernel modules (the path matches).
That means that I am stuck with “C:\Windows.old” directory forever. Or until I update the driver. Meh.

4

Starting in some version of Win10 most drivers are no longer pagefile
backed, so they work just like standard DLLs/EXEs. Super annoying change…

Your particular case is pretty messed up. Seems like an unexpected
limitation that you can’t delete *a* link for a file that is mapped as an
image (I’ll buy that you can’t delete the last link).

I suppose in this case there’s a chance that booting into VGA mode would let
you delete it :slight_smile:

-scott
OSR
@OSRDrivers

5

> Your particular case is pretty messed up. Seems like an unexpected limitation that

you can’t delete *a* link for a file that is mapped as an image
(I’ll buy that you can’t delete the last link).

Yes, it was the “Windows.old” link that I wanted to delete. And the state is indeed messed up so that the same file is hardlinked by both current and previous Windows installation

I suppose in this case there’s a chance that booting into VGA mode would let you delete it :slight_smile:

Surprisingly, the “Delete Previous Windows Versions” feature in control panels worked. So there is a way (unknown to me) to do that. I’ll play with it some more when I have time.

6

> Your particular case is pretty messed up. Seems like an unexpected

limitation that you can’t delete *a* link for a file that is mapped as an
image (I’ll buy that you can’t delete the last link).

How about trying to unlinking it from the Linux subsystem (or whatever they
call it).
As well all know there is a wheen of new ways to delete things added for
that.

Or try a destructive rename - that’s the sort of thing that might do a
different check…

R

7

In playing around with this more, you can successfully delete the link if
you use the new FileDispositionInfoEx class (without the
FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK bit set).

Wrote a small test app to demonstrate the behavior. It creates a hard link
against the running executable and tries to delete it both the non-Ex and Ex
way:

https://github.com/OSRDrivers/deleteex

You can see the non-Ex way fails but the Ex way successfully removes the
link.

-scott
OSR
@OSRDrivers

8

Nice catch, Scott. I can confirm what you found.

I updated FileTest to support CreateHardLink. Also, I improved FileTest’s tree-deleting function (NtDeleteFsObject) to include the new FILE_DISPOSITION_INFORMATION_EX when necessary.

The credit goes to you:
https://github.com/ladislav-zezula/FileTest/blob/master/Page05FileOps.cpp

The new FILE_DISPOSITION_INFORMATION_EX has been already in FileTest for a while, with the fancy clickable flags as well.

Thanks!