Disk Cleanup won't delete certain files

JohnnyGuiYour file permissions are improperly set I'm sure (also check file ownership.) Either that, or the ACLs are corrupt / have been modified in some way. This is not exactly the same as the original one Microsoft uses for Windows 10 / 11, but it can also remove SID strings for accounts that may or may not exist on your PC (sometimes with upgrades or certain patches, the operating system cannot access the files because the ACLs have been modified to block access.) This can take anywhere between 30 minutes, to 4 hours btw. If you don't want to use this you can hand parse each entry with takeown / icacls.

@ECHO OFF
SETLOCAL
REM ++++++++++----------++++++++++----------++++++++++----------++++++++++----------++++++++++----------
REM ----------++++++++++----------++++++++++----------++++++++++----------++++++++++----------++++++++++

REM Batch file to reset ACLs on WinPE for offline images only:

icacls A: /remove "ALL RESTRICTED APPLICATION PACKAGES" /c /l /q
icacls A: /remove "ALL APPLICATION PACKAGES" /c /l /q
icacls A: /remove "NT AUTHORITY\Authenticated Users" /c /l /q
icacls A: /remove "NT SERVICE\TrustedInstaller" /c /l /q
icacls A: /inheritance:r /grant:r "NT SERVICE\TrustedInstaller":(OI)(CI)(F) /c /l /q
icacls A: /remove "NT AUTHORITY\SYSTEM" /c /l /q
icacls A: /inheritance:r /grant:r "NT AUTHORITY\SYSTEM":(OI)(CI)(F) /c /l /q
icacls A: /remove "BUILTIN\Users" /c /l /q
icacls A: /inheritance:r /grant:r "BUILTIN\Users":(OI)(CI)(F) /c /l /q
icacls A: /remove "BUILTIN\Administrators" /c /l /q
icacls A: /inheritance:r /grant:r "BUILTIN\Administrators":(OI)(CI)(F) /c /l /q
icacls A: /inheritance:r /grant:r "NT AUTHORITY\Authenticated Users":(OI)(CI)(F) /c /l /q
icacls A: /inheritance:r /grant:r "ALL APPLICATION PACKAGES":(OI)(CI)(F) /c /l /q
icacls A: /remove "Everyone" /c /l /q
icacls "A:\*.*" /reset /t /c /l /q

REM ----------++++++++++----------++++++++++----------++++++++++----------++++++++++----------++++++++++
REM ++++++++++----------++++++++++----------++++++++++----------++++++++++----------++++++++++----------

https://docs.microsoft.com/en-us/windows/win32/secauthz/sid-strings | https://docs.microsoft.com/en-us/windows/win32/secauthz/well-known-sids | https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-string-format | https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/takeown https://ss64.com/nt/takeown.html

https://docs.microsoft.com/en-us/windows/win32/secauthz/security-descriptor-definition-language-for-conditional-aces- | https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/icacls https://ss64.com/nt/icacls.html

Specifies a security descriptor in the security descriptor definition language (SDDL) format.
By default the security descriptor is taken from the parent directory. SDDL strings can be complex but flexible.
In its simplest form, a security descriptor that protects access, is known as a discretionary access control list (DACL). It is of the form:

D:<DACL_FLAGS>(<STRING_ACE>)(<STRING_ACE>)...(<STRING_ACE>)

Common DACL_FLAGS are:

"P" - The DACL should not be overiden (protected) by any ACLs from parent containers.
"AI"- The DACL should auto-inherit from the parent container.

STRING_ACEs are of the form:

<ACE_TYPE>;;<RIGHTS>;;;<ACCOUNT_ID>

Common ACE_TYPEs are:

"A" - Allow access.
"D" - Deny access.

Common RIGHTS are:

"GA" - All access.
"GR" - Read access.
"GW" - Write access.

Common ACCOUNT_IDs are:

"BA" - Built in administrators
"AU" - Authenticated users.
"CO" - Creator owner.
"WD" - Everyone.

Putting all this together, for example, gives read-access to all authenticated users:

D:P:(A;;GR;;;AU)

Similarly, gives everyone full access:

D:P:(A;;GA;;;WD)

"Sddl: The security descriptor of the resource displayed in a single text string in Security Descriptor Definition Language format. PowerShell uses the GetSddlForm method of security descriptors to get this data." -> https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/convertfrom-sddlstring?view=powershell-7.1

https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file | https://docs.microsoft.com/en-us/previous-versions/windows/desktop/indexsrv/unix-style-regular-expressions

https://docs.microsoft.com/en-us/previous-versions/windows/desktop/indexsrv/ms-dos-and-windows-wildcard-characters

https://ss64.com/nt/syntax-wildcards.html

https://ss64.com/nt/syntax-esc.html

NOTE: This is the final output, though you could obviously modify this script. There is no user account ID / SID string associated with WinPE, so you don't need takeown or anything else to modify or reset the ACLs. It individually removes, and consolidates permissions without waste (although it's pretty broad as far as user rights vs administrator rights are concerned.) For personal use it's very good, given it grants inheritance, so that if you have this issue, you can run icacls regardless of folder hierarchy, and it inherits the ACL from the root entry on the system drive. If you were to run icacls on its own, it would inherit this new ACL, and you couldn't go back, no matter HOW much you tried (unless you were to wipe out each ACL with your own setup. I haven't tried creating one that mimics the default Microsoft version exactly, but even that one has some annoying flaws too, such as restrictions for "Program Files" when logged in as admin, etc.)

C:\Users\<user_name>\Desktop>ICACLS C:
C: APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(F)
   NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(F)
   BUILTIN\Administrators:(I)(OI)(CI)(F)
   BUILTIN\Users:(I)(OI)(CI)(F)
   NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
   NT SERVICE\TrustedInstaller:(I)(OI)(CI)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\<user_name>\Desktop>

If it is necessary to use WinPE to modify the ACLs, I have written some WinPE ISO creation scripts here: https://techcommunity.microsoft.com/t5/windows-11/example-iso-patch-guide-for-windows-11-64-bit-21h2/m-p/3574791/highlight/true#M4464

NOTE: If you try to change the ACLs for system files on a running operating system image it will become non-bootable, or you will lose access to the files after you remove the ACEs, which is counter-productive. So you basically have to use WinPE if you want to be productive. It's much easier to test scripts on a non-system drive, with only a small amount of files, and a simple directory structure that doesn't span more than half a dozen entries. This is so you can manually inspect the entries in Windows Explorer. ( Right Click on a File -> Properties -> Security -> Advanced )

ACLs also affect Windows Apps as well. If you don't include "All Application Packages / Authenticated Users," you will run into serious issues with any Windows Apps. Ironically, Microsoft disables inheritance so that only "Program Files" and a few other folders have this particular setting, yet even that can get corrupted. I found it far easier to just set all file permissions at the root folder, and then enable inheritance. When you run icacls after that point, (with /reset /t /c /l) it will purge any entry that does not match the original folder hierarchy for the root ACL, without you even noticing it (which is extremely convenient for obvious reasons.) If you don't allow icacls to operate on symbolic links, you will get a far higher failure rate. Although some would not want the exact same folder permissions, with user accounts in particular, unless the computer was air-gapped on the network / network shares were disabled, and they were the ONLY person who was using the device.

"Microsoft Store Apps fail to start if default registry or file permissions modified" -> https://docs.microsoft.com/en-us/troubleshoot/windows-client/shell-experience/microsoft-store-apps-fail-to-start

https://docs.microsoft.com/en-us/windows/win32/shell/appids#registering-an-application-as-a-host-process

https://docs.microsoft.com/en-us/windows/configuration/find-the-application-user-model-id-of-an-installed-app