APMichael

I am not an employee of Piriform, so this is just my humble opinion: Unfortunately, I have not been able to reproduce the problem on any system, neither with Office 2016 nor 2019. I also tried to reproduce the problem in a virtual machine for several days, but this was not successful either. As far as I know Piriform cannot reproduce the problem either. So how do you want to fix a bug that cannot be reproduced on your system? At least someone who always has this problem could help by finding out which cleaning rule is responsible for it. To find the cleaning rule, one could proceed as follows: - Go to "Custom Clean", right-click on the name of the first section "Microsoft Edge" and select "Clean Microsoft Edge". - Run Office to check if it is broken. - If not, repeat with the next section ("Edge Chromium", "Internet Explorer", ...) until you find the responsible section. - Repair the Office installation. - Now right-click on the first cleaning rule of the responsible section and select "Clean <rule name>". - Run Office to check if it is broken. - If not, repeat with the next cleaning rule until you find the responsible cleaning rule. This would not only help Piriform, but also all other affected users.

Yes, "/WAIT" instructs "START" to do this. Syntax: START "title" [/D path] [options] "command" [parameters] Options: /W or /WAIT - Start application and wait for it to terminate.

You could create a batch file like the following and name it "ccsleep.bat" for example: @ECHO OFF START "CCleaner" /WAIT "%ProgramFiles%\CCleaner\CCleaner64.exe" /AUTO "<path_to_psshutdown>\PSSHUTDOWN.EXE" -d -t 0 PsShutdown can be downloaded here: https://docs.microsoft.com/en-gb/sysinternals/downloads/psshutdown

This entry is already included in Winapp3.ini: [Windows Latest Cumulative Update *] Edit: @Special It happens. Don't worry about it.

Thanks for the new and revised entries. Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/43f204e5e220555c1d9054bb8f40a0feed399c8a Winapp3.ini update: https://github.com/MoscaDotTo/Winapp2/commit/d42b0f628c6c66b7a5d0101d12b9642a5ffbd8f6

The problem seems to be caused by CCleaner being blocked by the firewall:

Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/4e740fec28c04a9c94dd5368480f9e7c68420b7b Winapp3.ini update: https://github.com/MoscaDotTo/Winapp2/commit/ff6dcc530e4bda1d2d9abd2adca04c3abe65b429

If still of interest: The highlighted registry key "Edge" on your screenshot is the correct one. Click on "Edge" and delete it. You can also delete the key "EdgeUpdate". Yes, you can delete the entire folder "Edge" under "C:\Users\<your user name>\AppData\Local\Microsoft\". This folder only contains the Edge Chromium user profile ("User Data"), which you no longer need. The old Edge has its own keys and folders.

Check if the following folders or registry keys still exist: C:\Program Files (x86)\Microsoft\Edge C:\Users\<your user name>\AppData\Local\Microsoft\Edge HKEY_CURRENT_USER\Software\Microsoft\Edge After deleting them, Edge Chromium should hopefully no longer be detected by CCleaner.

Just a reminder: the bug is not yet fixed in version 5.66.7716. Probably the bug report came too short before the release of the current version.

I had a little more time to check the bug and have to correct parts of my previous post. (I use Windows 10 for my following examples.) The following DetectOS strings no longer work: DetectOS=|10.0 (= for Windows 10 and older) DetectOS=10.0|10.0 (= only for Windows 10) The problem seems to be that the version number after the pipe symbol now also needs the build number, because the following strings work: DetectOS=|10.0.18363.778 DetectOS=10.0|10.0.18363.778 Please make sure that CCleaner, if no build number is included in the string, behaves like the previous versions and accepts a simple "|10.0" again. Thanks! @hazelnut: Thanks for the flagging.

Thanks for the new entries. Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/ea91bacc032800bd1e82d17c4ed6afab1c80baf0 Winapp3.ini update: https://github.com/MoscaDotTo/Winapp2/commit/2a168556bf228258d1d1b5dfea625e379b558335 And get the new Winapp2ool version 1.4: https://github.com/MoscaDotTo/Winapp2/releases

There is a bug in the current CCleaner version: A DetectOS according to the scheme "DetectOS=from|to" (e.g. "DetectOS=6.2|6.3") does not work anymore and CCleaner therefore sorts out the entry. The other combinations with a pipe symbol still seem to work (e.g. "DetectOS=|10.0" or "DetectOS=10.0|"). The bug was found by @dvdbane and reported here: https://community.ccleaner.com/topic/32310-winapp2ini-additions/page/331/?tab=comments#comment-318930

This problem is not caused by Winapp2.ini, it is definitely a bug in the current CCleaner version. A DetectOS according to the scheme "DetectOS=from|to" does not work anymore. Edit: https://community.ccleaner.com/topic/58081-detectos/

End all tasks with "CCleaner" in their name. According to the screenshot this would be the task: "CCleaner emergency updater (32 bit)". Hopefully it should work after that.

The VirusTotal summary is still clean: https://www.virustotal.com/gui/file/59467eb6dac8716afbd617f7e01b1b32dc00056ad2dd92f4016ae721809fd1af/detection Did you possibly mean blocking by SmartScreen? About your question: https://github.com/MoscaDotTo/Winapp2/issues/412 You could use the previous version 1.02 for this. Select "WinappDebug" (1) and enable "Toggle Autocorrect" (3). When you execute "Run" (1) the lines will be inserted automatically again.

Winapp2ool update: https://github.com/MoscaDotTo/Winapp2/releases Many thanks to @Winapp2.ini for his hard work! Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/d4404678fffbd62cc1ab0f859f87cfcc930f0773 Only adjustments for the new Winapp2ool version.

We can change the detection, but CCleaner will still only delete the folders and files defined in Winapp2.ini after uninstalling the application. A complete removal of all leftovers after an uninstall will always require manual work or a special uninstaller tool. Right! This entry deletes the data and few but important settings of all networks ever connected. This may not be a big problem on a stationary PC with only one network connection, but on a Notebook with many changing network connections (different private, business and public networks) this must be set again for each network as desired. Windows saves the network/firewall category (Public, Private, Domain) there, hence the request after a reboot. Also, some people change the name of a LAN there (under Windows 7 this was even possible via the Control Panel).

No, this function does not exist. But as @Andavari has already written, "=False" can be simply replaced by "=True" with Notepad. (By the way, you can also right-click on a section name in CCleaner and select "Check all". But this does not directly change the Winapp2.ini.)

1) No, the order does not matter. For a fast and automated error checking, however, an order had to be determined. And since only very few entries have ExcludeKeys, they were placed at the end of an entry. 2) Yes, the corrected entry is already included since last December. The tool you mentioned does not use its own Winapp2.ini file, but downloads ours from GitHub. Therefore, it's also better to report problems with entries directly here or on GitHub, rather than in the tool's forum.

Thanks for the modified/revised entries. Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/ae7b169afd579bb15f5f799e8162e242483958e2

Please check out this thread:

Thanks for the suggestions and revised entries. Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/b84a73fb8322bfb42a14e621fd41a408b627fb5e

I'm not sure. If this is not cleaned up by CCleaner, then someone would probably have made an entry for it a long time ago. If you search the forum for "OfflineCache", CCleaner seems to clean it up. The entry "Cookies" should do this. CCleaner cleans up the database directly (and therefore does not delete the ".sqlite" file itself). https://community.ccleaner.com/topic/32310-winapp2ini-additions/page/263/?tab=comments#comment-288245 Quote: "... [Pale Moon - Offline Cache*] ... ok, found with Firefox -> Cookies (!!!) ..." Edit: I can now confirm that the "OfflineCache" is cleaned by CCleaner (entry "Cookies"). You can test it yourself as follows: - Open a website using the offline cache: https://html.spec.whatwg.org/demos/offline/clock/clock2.html - Check "appcache" with: about:cache - Close Firefox and run CCleaner entry "Cookies". - You can now see that CCleaner deletes the subfolders of "OfflineCache". - Open Firefox and check "appcache" again: about:cache - You can see that there are no more entries. (The CCleaner entry "Compact Databases" then reduces the size of the cleaned ".sqlite" file back to the original size of 256 KB.)

I think 3) should be: 3) Navigate to: C:\Users\<your username>\AppData\Local\ However, the question remains why this only occurs with a few Office users. I also have these files in the Temp folder, but I can delete them without any problems. My Office 2016 has never been affected by CCleaner. By the way, there is unfortunately still no official answer here either: