How to Delete Windows.old and Reclaim the Disk Space

A laptop comes back from a Windows 11 upgrade with the disk at 97% and a folder on C:\ that Explorer refuses to delete. That folder is the previous installation, and it is holding anything from ten to forty gigabytes for a reason. This guide covers how to delete Windows.old the way Windows expects, what to check first, and how to do it across a fleet without a technician visiting each desk.

What Windows.old Holds and Why It Exists

Every feature update and every in-place upgrade moves the old installation aside instead of overwriting it. The Windows folder, Program Files, ProgramData and the Users tree from the previous version all land under C:\Windows.old. That copy is what the "Go back" button in Settings uses to roll the machine back if the new version misbehaves, which is why Microsoft's own page on the folder warns that deleting it "can't be undone".

It is not alone. The upgrade also leaves $WINDOWS.~BT, the hidden folder where Setup staged the new build, and sometimes $WINDOWS.~WS from the Media Creation Tool or a Windows10Upgrade folder from the Upgrade Assistant. Disk Cleanup lists those under "Temporary Windows installation files", and a failed upgrade that ended in error 0xC1900101 often leaves them behind without a Windows.old at all.

Size depends on what the old installation carried. The r/WindowsHelp thread further down measured one at 40 GB on a machine fresh from Windows 10, which on a 128 GB SSD is the difference between a usable laptop and one that cannot take the next cumulative update.

The 10-Day Clock and the Task Behind It

Microsoft's page states the rule in one sentence: "Ten days after you upgrade to Windows, your previous version of Windows is automatically deleted from your PC." The job runs as a scheduled task under Task Scheduler Library, Microsoft, Windows, Setup, named SetupCleanupTask, and it fires some days after the upgrade rather than on a visible schedule. When it runs, the "Go back" option disappears with the folder.

The window is adjustable, and knowing that saves a conversation. Microsoft's DISM reference documents DISM /Online /Get-OSUninstallWindow to read the current value and DISM /Online /Set-OSUninstallWindow /Value:<days> to change it, with a range of 2 to 60 days; anything outside that range falls back to the default of 10. There is also DISM /Online /Remove-OSUninstall, which removes the rollback option on purpose, and the page is explicit that it is a setting for IT administrators, not for OEM imaging.

The clock is less reliable than the page suggests. In the r/SCCM thread below, one administrator reports that in their domain environment the folder "rarely ever gets removed", and another says it has not cleaned itself up "in over 100 upgrades". The replies that say "just wait" are not wrong on a home PC; on a managed fleet the task is one of the things that gets starved by shutdown schedules, power policies and machines that never sit idle long enough.

Check Three Things Before You Delete

The folder is a rollback, so the first question is whether anyone still needs one. If the upgrade is a week old, the user has signed in daily, printers and the line-of-business app work, and nothing is waiting on a driver, the rollback has done its job by not being needed. If the machine is still throwing new errors, keep the folder and fix the errors first, because "Go back" is faster than a repair install and loses nothing.

The second check is user data. Windows.old\Users is a complete copy of every profile as it was at upgrade time. On a clean upgrade that is a duplicate. After a profile mishap, a user who picked "Keep nothing" by mistake, or an upgrade that created a fresh account, it is the only copy. Open the user's folder inside Windows.old, look at Desktop, Documents and AppData, and copy out anything that does not exist in the live profile before anything else happens.

The third check is the one people skip: whether the folder is already on its way out. A dir C:\Windows.old that shows the folder half-empty, or a Disk Cleanup entry for "Previous Windows installation(s)" that reads a few hundred megabytes rather than tens of gigabytes, means the cleanup task has already started. Let it finish rather than racing it.

Britec09's walkthrough from earlier this year makes the same case for looking before deleting, and shows the Settings and Disk Cleanup routes on a live machine:

Why a Plain Delete Fails, and What It Leaves Behind

The folder is owned by TrustedInstaller and SYSTEM, and the permissions inside it are the previous installation's, not yours. Explorer's delete walks the tree, hits the first file an administrator cannot touch, and stops with "You require permission from SYSTEM". A third-party uninstaller or cleaner does the same thing with more confidence and fewer messages.

The result is worse than the original problem. In the r/WindowsHelp thread below, a user fresh off a Windows 10 to 11 upgrade found Windows.old at 40 GB, ran a third-party uninstaller against it, and was left with a set of folders Windows would not let them remove and no obvious way to get the space back. The top reply, with 19 points, is the whole fix: run the real Disk Cleanup from the drive's properties. The other high replies say the same thing in different words, because the supported tools know how to take the folder apart and a generic delete does not.

There is a second trap in the folder itself. The old Users tree contains junction points such as "Application Data" and "Local Settings" that exist for compatibility with old software. A recursive ownership change that follows them can wander into locations outside Windows.old, which is why the takeown fallback later in this post is the last resort and not the first.

Three Supported Routes and One Fallback

Settings. Open Settings, System, Storage, then Temporary files. Tick "Previous Windows installation(s)" and choose Remove files. On Windows 11 the same item also surfaces under Cleanup recommendations on the Storage page, which is the route Microsoft's KB5012334 documents. It needs an administrator account and takes a few minutes.

Disk Cleanup. Search for Disk Cleanup, pick the system drive, then click "Clean up system files" so the tool relaunches elevated. The list that comes back includes "Previous Windows installation(s)" and "Temporary Windows installation files", which is where $WINDOWS.~BT and $WINDOWS.~WS go. Tick both, confirm, and expect a second prompt asking whether you are sure about the previous installation. Disk Cleanup is still the tool that handles the stubborn leftovers a half-finished delete leaves behind, which is why it is the answer in both Reddit threads above.

cleanmgr with a saved profile. The same tool runs without a window. Every Disk Cleanup checkbox maps to a key under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches, and cleanmgr /sageset:<n> saves your ticks as a StateFlags<n> value under each key, so cleanmgr /sagerun:<n> replays them silently. For a script, set the flag directly and run the profile:

code
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Previous Installations" /v StateFlags0777 /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Temporary Setup Files" /v StateFlags0777 /t REG_DWORD /d 2 /f
cleanmgr /sagerun:777

Run it elevated, and give it a timeout in whatever launches it, because cleanmgr has a habit of waiting on a dialog nobody can see when something else holds a file open. The same mechanism cleans the component store, but keep that job separate: DISM /Online /Cleanup-Image /StartComponentCleanup is covered in our DISM guide and has nothing to do with Windows.old.

The fallback. When the three routes above all fail to clear the folder, usually after something else has already mangled the permissions, take ownership and remove it by hand from an elevated prompt:

code
takeown /F C:\Windows.old /R /D Y
icacls C:\Windows.old /T /grant Administrators:F
rd /S /Q C:\Windows.old

Microsoft published the same three lines in an archived engineering post, noting that the folder "cannot be deleted even with administrator privileges" without the ownership step. Run it only on C:\Windows.old, never on a wildcard, and read the output: a run that reports access denied on a handful of files has usually hit a junction, and the right move is to remove the Users subtree first with the same commands scoped to it.

Across a Fleet

On one machine the Settings route is a two-minute job. On two hundred machines after a feature update the question is which ones still carry the folder, how big it is, and how many days have passed since the upgrade, because the answer to "delete it now" changes at day ten. The administrator in the SCCM thread above got the right advice: a baseline that detects the folder and removes it after a set number of days, run daily, rather than a one-off push.

The detection half is a short script. It reports the folder's size and the days since the upgrade, which Windows records as the install date of the current build:

powershell
$old = 'C:\Windows.old'
if (Test-Path $old) {
  $gb   = [math]::Round((Get-ChildItem $old -Recurse -Force -ErrorAction SilentlyContinue |
           Measure-Object Length -Sum).Sum / 1GB, 1)
  $days = (New-TimeSpan -Start (Get-CimInstance Win32_OperatingSystem).InstallDate).Days
  "$env:COMPUTERNAME  Windows.old=${gb}GB  days-since-upgrade=$days"
} else { "$env:COMPUTERNAME  no Windows.old" }

Run that across the fleet first, read the list, and only then run the cleanmgr profile on the machines past the day you picked. If you run OpenFrame, that is one script run across a client's devices with the output collected in one place, so the machines with 40 GB sitting idle are a sorted list rather than a surprise. Pair it with a disk health check on the ones that were low before the upgrade, because a drive that was at 95% with Windows.old present is one the SSD health check should see next.

Two things not to do at scale. Do not push the takeown fallback as the first pass; it is a per-machine repair for a folder that something else broke. And do not set the rollback window to two days to make the folder vanish faster; the ten days exist so the user who finds the broken printer on day six still has a way back.

When to Delete It and When to Wait

The call comes down to three gates. If the upgrade is younger than ten days and the user has not confirmed the machine is fine, wait; the folder is doing its job and Windows will remove it on its own. If the upgrade is stable, or older than the window, and the disk is above 85%, remove it through Settings or Disk Cleanup today and take the setup leftovers with it. If anything in Windows.old\Users might be the only copy of a file, copy that out first and then delete, in that order, because the delete is the one step on this page that has no undo.

Windows.old is a rollback with a ten-day fuse, not junk. Check the fuse, check the user's files, and then let Settings or Disk Cleanup take it apart; the takeown commands stay in the drawer for the machine where someone already tried something else.

If the disk is still full afterwards, the next suspects are the ones that do not show up in Temporary files, starting with the page file and the preinstalled apps a debloat pass removes.

Our debloat guide covers that list.