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

Before Posting... Please check out the Community Guidelines in the
Announcements and Administration Category, below.

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

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)?

Comments

  • Scott_NooneScott_Noone Posts: 2,989
    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
  • 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.
  • Scott_NooneScott_Noone Posts: 2,989
    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 :)

    -scott
    OSR
    @OSRDrivers
  • > 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 :)

    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.
  • > 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
  • Scott_NooneScott_Noone Posts: 2,989
    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
  • 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!
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!