Command-line Sequence Kills Resistant Windows.old Files
Yesterday, while poking around on my Lenovo T520 I found something unexpected. A Windows.old folder was still hanging around. This, despite having upgraded more than 10 days ago to 1809, and also having cleaned up the previous OS install manually. “Hmmm,” I thought to myself, “wonder what it is this time?” When my usual techniques for stomping out persistent Windows.old failed, I turned to Google. I quickly learned that a specific command-line sequence kills resistant Windows.old files and folders.
This laconic answer to the lengthy MS.answers post fixed my problem, too.
I translated the network path shown into a purely local path so I could run the command right on the affected PC itself.
Which Command-line Sequence Kills Resistant Windows.old Files and Folders?
That command is:
rd /s /q %systemdrive%\Windows.old
Here rd stands for remove directory (also known as the rmdir command). /s stands for recurse, which instructs it to remove all dependent folders. /q stands for quiet, which means it ignores any error or other messages that Windows hands out during the deletion process. This turns out to be the key to extirpating the resistant folder structure.
When you run this command on your target PC, you will have to use the drive letter for its affected system drive. This may or may not be the usual C:. That’s because when you boot to an alternate OS image, drive assignments don’t often remain the same. I used Kyhi’s excellent Windows 10 Recovery Tools — Bootable Rescue Disk, which does preserve existing drive mappings. But if you use the built-in Windows Recovery environment, your old C: drive could show up as something else. Use diskpart to check, please!
Why This Folder Hierarchy Resists Deletion
The affected folder hierarchy explains why this item resists deletion. It looks like the following string, laid out in descending fashion. (It is, of course, all on one line in Windows. But I can’t reproduce that within a WordPress web page without unpredictable line breaks. Thus, I break it across 4 lines here.)
Users\<account-name>\AppData
Local\Packages\
Cortana_cw5n1h2txyewy\
Localstate..
Note the two periods at the end of the final folder in the sequence. Note also that when I tried to examine this folder, Windows reports that the file can’t be found or doesn’t exist. Thus, what we’re dealing with here is a damaged file and folder structure. There’s actually no file at the bottom of this folder list — or at least, no file that I can see using File Explorer or normal command line inspection techniques. That also explains why my usual deletion methods don’t work. The preceding command sequence zaps whatever it finds, recursively (/s) and without stopping for error messages (/q) along the way. That does the trick!
[Note: I found this command string thanks to a post at Answers.Microsoft.com, which led me to this solution after my usual clean-up techniques failed. They work fine on intact file/folder structures, but this command is necessary to kill damaged or incomplete ones.]