Force-Deleting Protected Windows Folders

Take ownership and delete folders that resist removal even from an Administrator account, using takeown, icacls, and an escalation ladder.

Some Windows folders refuse to delete even when your account is an Administrator — most commonly Windows.old, but the same wall shows up with upgrade staging folders, leftover program directories, and folders copied from another machine. This page documents the general technique for clearing them, using Windows.old as the worked example.

Why Administrator isn't enough

Being in the Administrators group only lets you request elevation. The files themselves are owned by TrustedInstaller or SYSTEM, and their ACLs block deletion regardless of your group membership. Right-click-deleting will nag for permissions or fail partway through.

The fix is always the same three-move pattern:

Reassign ownership away from TrustedInstaller/SYSTEM to yourself (or the Administrators group).
Grant yourself full control in the ACL.
Act — delete (or modify) the now-accessible files.

Everything below is just this pattern with progressively heavier tools for progressively more stubborn targets.

Try the built-in cleanup first (for intact `Windows.old`)

If the folder is still complete, let Windows handle ownership and permissions for you — don't reach for the command line yet.

Settings → System → Storage → Temporary files → tick Previous Windows installation(s) → Remove files.

Run cleanmgr, select C:, click Clean up system files (this re-elevates properly), tick Previous Windows installation(s), then OK.

Disk Cleanup keys off the folder being intact. If you've already manually deleted most of Windows.old and only fragments remain (e.g. the leftover Program Files, Program Files (x86), and Windows subfolders), it won't list "Previous Windows installation(s)" anymore — skip straight to the ownership method below.

Windows.old is your rollback path. Once it's gone, "Go back to the previous version of Windows" is no longer available. Windows also auto-purges it after about 10 days, so if you aren't tight on disk space you can just let it expire.

The ownership method

Run everything from an elevated terminal — right-click → Run as administrator, even on an admin account, so you get the elevated token. takeown and icacls are classic executables (takeown.exe, icacls.exe), not PowerShell cmdlets, but they run fine from either PowerShell or Command Prompt.

Take ownership and grant full control

takeown /f C:\Windows.old /r /d y
icacls C:\Windows.old /grant administrators:F /t

takeown /r /d y recurses and auto-answers yes to the ownership prompts.
icacls ... /t pushes the full-control grant down the whole tree.

Delete the folder

Remove-Item C:\Windows.old -Recurse -Force

Or with the classic command:

rmdir /s /q C:\Windows.old

Point these at C:\Windows.old specifically — never C:\Windows. They're one keystroke apart, and reassigning ownership on your live C:\Windows breaks Windows servicing.

icacls is spelled i-c-a-c-l-s (from "ICACLS", the ACL tool). If you get "not recognized" after fixing the spelling, confirm C:\Windows\System32 is on your PATH, or call the tool by full path: C:\Windows\System32\icacls.exe.

Still "Access Denied"? The escalation ladder

Work down this list. Note which command throws the error — takeown, icacls, or the delete — since that narrows the cause.

Use the well-known SID instead of a group name

On non-English Windows the group isn't called administrators, and icacls rejects the wrong string. The well-known SID sidesteps localization entirely:

takeown /f C:\Windows.old /r /a /d y
icacls C:\Windows.old /grant *S-1-5-32-544:F /t /c

/a assigns ownership to the Administrators group; /c tells icacls to keep going past errors so one stubborn file doesn't halt the whole grant.

Delete with robocopy's empty-mirror trick

More reliable than Remove-Item for trees with long paths or many small files:

mkdir C:\empty
robocopy C:\empty C:\Windows.old /mir
rmdir /s /q C:\Windows.old
rmdir /s /q C:\empty

/mir mirrors the empty folder onto the target — emptying it — then you remove the now-empty shells.

Handle the specific holdouts

If it's still denied, the blocker is usually one of:

A leftover WindowsApps folder (under Program Files) — these carry unusual ACLs even ownership doesn't fully cover. Target that folder directly with the takeown/icacls pair, then retry.
A locked file — reboot and run the whole sequence again before touching anything else, so nothing is held open. A file that keeps failing is usually locked by a running process, not a permissions problem; Resource Monitor's Associated Handles search will find the culprit.

Escalate to a SYSTEM shell

Some files only yield to the SYSTEM account, which outranks even your elevated admin token. Grab PsExec from Sysinternals and launch a SYSTEM-level prompt:

psexec -sid cmd

Run the takeown / icacls / rmdir sequence from that window to clear the last holdouts.

Where else this applies

The method has nothing to do with Windows.old specifically — it's the general answer to "I'm an admin but Windows won't let me touch this." Same commands, same order, aimed at a different folder:

Upgrade staging folders — $WINDOWS.~BT and $Windows.~WS, same family as Windows.old.
Leftover program folders in Program Files or ProgramData after a botched uninstall — same TrustedInstaller/SYSTEM ownership.
Folders copied from another machine or old drive, whose ACLs reference a SID that doesn't exist on this system. You get "access denied" because the owner is a ghost account; takeown/icacls reassigns it to you.
User profile remnants in C:\Users after deleting an account — often owned by the now-gone SID.

Cautions when reusing this

Never run takeown/icacls against C:\Windows, C:\, or C:\Program Files as a whole. Reassigning ownership on live system trees breaks servicing — Windows Update stops working — and can wreck the install. Point it at specific dead folders only.

takeown/icacls is one-directional in practice: it does not restore the original ACLs afterward. That's fine for folders you're deleting, but if you're taking ownership of something you intend to keep and use, you've permanently changed its permissions. Snapshot the ACLs first with icacls <path> /save <backupfile> /t if you might need to reverse it.

When a delete keeps failing on one specific file, it's almost always locked by a running process rather than a permissions issue. Reboot or close the offending process — more takeown attempts won't help.

Force-Deleting Protected Windows Folders

On this page