OSUninstallWindow DISM Difficulties

Detecting OSUninstallWindow DISM Difficulties

It’s pretty easy to tell these commands don’t work as they should. On Version 1809, they throw “Error 3: The system cannot find the path specified.” On Version 19H1 (Build 12298), they throw “Error 1168: Element not found.” I’ve reported this to the Windows 10 Feedback Hub under the title “dism /online /get-osuninstallwindow not working.” I hope you’ll check the status on your Windows 10 PCs and upvote this item if you experience the same errors. I’ve checked all 9 PCs here at Chez Tittel, and all are subject to these errors. [As explained in the concluding section below, these errors will present on any PC where Windows.old has already been cleaned out.]

Here’s an illustration from a 19H1 Insider Preview test machine. It shows proper syntax for both commands in an admin PowerShell session. You can run them in an Administrative Command Prompt window, if you prefer.

Something, somewhere is going sideways with this usually ho-hum, dead easy DISM command sequence.

At present, default value for the OSUninstallWindow is 10. In fact, that means ten days. Thus, on Day 11 after you upgrade Windows 10, it fires off a disk cleanup task that gets rid of Windows.old and other leftovers from an upgrade install. When the aforementioned DISM command (Set-OSUninstallUpgrade) is working, that’s easy to change. But for the time being, it’s stuck at 10 days. You’ve been warned!

Again: check your PCs. If one of these errors pops up for you, please upvote my Feedback Hub item. Look for “dism /online /get-osuninstallwindow not working.” Thanks in advance for your help and support!

Explanation for the Errors

Having now spent a bit more time researching this matter, and working with my friend and business partner Kari Finn, I’ve got it figured out. These DISM commands work only if a Windows.old folder is present on the system drive. The retention info is apparently stored within that folder structure. If it’s not around, you can neither get nor set the value for OSUninstallWindow. How do I know? Because when those commands run on a Windows 10 install with Windows.old present, they work as advertised. When Windows.old is absent, either the path is missing or the item is absent depending on Win10 version.

I disagree with Microsoft’s implementation. To my way of thinking, right or wrong, the retention interval is an abstract value. Users should be able to set it whether Windows.old is present or absent. But that’s not how Microsoft handles the OSUninstallWindow. Thus, I’m changing my feedback hub request to ask them to turn it into a Group Policy or a Registry setting. It shouldn’t depend on the presence or absence of a specific folder hierarchy. ‘Nuff said.