Jun 13 2022 12:41 PM
Disk Cleanup via Windows settings doesn't delete the checked "Temporary files" (770mb) nor Windows Defender files. All the other checked files do get cleaned up normally. It completes as if it successfully deleted everything but it doesn't when I click Refresh.
Trying to delete these files via the Disk Cleanup tool (cleanmgr.exe) as Administrator or in Safe mode also doesn't work. I am the only user and Administrator on the PC.
I am aware I could try to go to the temp folder and delete the files manually, but why doesn't it work this way? Is this reproducible at anyone's end?
Jun 13 2022 01:07 PM
Hi @JohnnyGui
Some temporary files are needed, but try restarting and disk cleaning should start automatically if the configuration is correct.
Jun 13 2022 01:28 PM - edited Jun 13 2022 01:30 PM
If some are needed then it's quite confusing that it shows up in Disk Cleanup.
I rebooted and restarted several times but it didn't help.
The weird part is that on the Storage page in Settings it shows less space taken by temporary files than when I click on it to show the details.
Are you experiencing the same?
Jun 13 2022 02:00 PM
Jun 13 2022 02:04 PM
Yes, deliver optimization files deletes normally. Temporary files of around 777mb and Defender files has been around for almost a week now and can't be deleted. I noticed extra space added on top of the 777mb can be deleted but not more.
Jun 13 2022 02:14 PM
Jun 13 2022 02:15 PM
Jun 13 2022 02:21 PM
Jun 13 2022 03:18 PM - edited Jun 13 2022 03:29 PM
Thanks for testing this out.
I just noticed something that might've caused confusion here. When clicking on "Temporary Files" on the Storage page in Settings, there is an extra "Temporary files" with a checkbox that I can specifically check and delete among the other deletable files (defender, delivery optimization, etc.).
I attached an example picture. Not sure if you have the same line at your end.
Jun 14 2022 03:15 PM
@JohnnyGui I am experiencing exactly the same issue/s. The windows update, defender and temp files do not clear. I have been trying various ways to delete the past few days. This is seems to have started in the past couple of updates. I am currently showing 2.16g windows update files that will not delete. This is a big deal when trying to clean up files to capture an image. By not being able to clean up all files it's is increasing my image size approximately 3g that is not needed. Any help from Microsoft would be appreciated.
Jun 15 2022 02:25 PM - edited Jun 15 2022 02:26 PM
Thanks for the reply.
I have moved 7 days old files rom the Appdata/Local/Temp folder itself and it disappeared from the Disk Cleanup. However, today 70mb of temp files popped up in Disk Cleanup that I couldn't delete.
I know it's not that much space but I don't get why it simply doesn't work.
Jun 19 2022 06:26 AM - edited Jun 19 2022 06:27 AM
No one else who noticed the same thing on his/her Windows 11 device?
Jul 14 2022 06:08 PM - edited Jul 14 2022 06:10 PM
Same here ... I have 2.48Gb "Windows Update" files that Disk Cleanup simply refuses to delete. Restart does not help. Running the usual sfc and DISM commands also no help. It's just annoying behaviour (bug I assume) ... it doesn't throw any error ... but the same space allocation shows up immediately after Disk Cleanup completes and you rerun it.
Jul 14 2022 06:44 PM - edited Jul 14 2022 06:46 PM
Question, when going to the temp folder (type %temp% in the run application) do you see many folders with numbers and letters separated by -'s ? Do these folders contain an .exe file called Dismhost.exe?
@wrd2093au Curious whether you also have these mentioned folders in the temp folder containing DismHost.exe
Jul 14 2022 06:53 PM
Jul 15 2022 04:16 AM
So there's only one folder containing DismHost.exe?
Are the Windows Update files the only files that won't delete? Or are there other files (such as Temporary files) that are problematic?
Jul 15 2022 04:36 PM
Jul 18 2022 10:29 PM
@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 ++++++++++----------++++++++++----------++++++++++----------++++++++++----------++++++++++----------
SID Strings | Well-known SIDs | Security Descriptor String Format | Takeown (SS64)
Security Descriptor Definition Language for Conditional ACEs | Icacls (SS64)
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-sddlstri...
Naming Files, Paths, and Namespaces | UNIX-Style Regular Expressions
MS-DOS and Windows Wildcard Characters
How-to: Match filenames with Wildcards
How-to: Escape Characters, Delimiters and Quotes at the Windows command line
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...
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-f...
Application User Model IDs (AppUserModelIDs)
Find the Application User Model ID of an installed app
Jul 19 2022 03:19 AM
Hi @Mousefluff
Hi, tell everyone how your response relates to the topic of the post?
I do not recommend following all these steps, because it is not needed and can lead to an irreversible error!
Jul 20 2022 03:46 PM
This is cumbersome not to mention quite risky.
@A1-A1 Could you please check something out for me?
1. In Windows Settings, go to System -> Storage -> Temporary files and clean the files as usual.
2. Now, go to the temp folder (Start menu -> Run -> %temp%).
Is there a folder created on that exact timestamp when you went to the Storage settings and cleaned the files? Its name consisting of numbers and letters separated by -'s and contains an executable called Dismhost.exe (among many others files)?
Waiting for your reply.