APMichael

@Dave CCleaner: Many thanks for your feedback. Then we very much hope that the bug can be solved quickly...

Version 5.68.7820 ...

Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/a51a6fe1f86e8e097eb2a116e27e10628e06d6db

I don't think it is necessary to separate those icon-less sub-apps again. This was fixed the same day.

Thanks for the new and revised entries. The new FileKey2 is already covered by FileKey1 (same path with *.*|RECURSE). "Microsoft.XboxGamingOverlay" is the separate app "Game Bar". So I updated the entry [Game Bar *] for you: [Game Bar *] DetectOS=10.0| LangSecRef=3031 Detect=HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\Microsoft.XboxGamingOverlay_8wekyb3d8bbwe FileKey1=%LocalAppData%\Packages\Microsoft.XboxGamingOverlay_*\AC\INet*|*.*|RECURSE FileKey2=%LocalAppData%\Packages\Microsoft.XboxGamingOverlay_*\AC\Microsoft\CryptnetUrlCache\*|*.*|RECURSE FileKey3=%LocalAppData%\Packages\Microsoft.XboxGamingOverlay_*\AC\Temp|*.*|RECURSE FileKey4=%LocalAppData%\Packages\Microsoft.XboxGamingOverlay_*\AC\TokenBroker\Cache|*.*|RECURSE FileKey5=%LocalAppData%\Packages\Microsoft.XboxGamingOverlay_*\LocalCache|*.*|RECURSE FileKey6=%LocalAppData%\Packages\Microsoft.XboxGamingOverlay_*\LocalState\Cache|*.*|RECURSE FileKey7=%LocalAppData%\Packages\Microsoft.XboxGamingOverlay_*\LocalState\DiagOutputDir|*.txt FileKey8=%LocalAppData%\Packages\Microsoft.XboxGamingOverlay_*\TempState|*.*|RECURSE

Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/c25dd01bd9e5db832817b1c3c200297e76934117

Great news! Let's hope this helps in the long run.

Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/f432baa2defa1a8e8ac951591feca26862d07422

@siliconman01 The AV vendors are really getting on my nerves. After weeks of silence they suddenly start flagging Winapp2ool again... @godfreythemasterbaiter Thank you for the hint and the description. Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/4fd8ec6ddf25251f7aebcbcf6acc47e49af870c7 Winapp3.ini update: https://github.com/MoscaDotTo/Winapp2/commit/0081c771f684d2465dda06d43baf4295e86aac7c

Still not fixed in version 5.67.7763! Very disappointing! You have broken a function that has worked for years, please fix it as soon as possible.

Still not fixed or optimized in v5.67.7763!

Thanks for the modified entry. Winapp2.ini updates: https://github.com/MoscaDotTo/Winapp2/commit/a43591f6046872ca37e0f9cc629abd90c89c1e98 https://github.com/MoscaDotTo/Winapp2/commit/efac42536ab1ac882e789068291d05b9952d9412

Sorry, but this is just a "cosmetic thing". Whether there is a 0 more or less shouldn't bother you. I just took 5 digits now, because that should be enough "forever". An adjustment to the actual number of entries would only work with more lines of code, but I don't have time for that at the moment. Ok, I understand, but as already written, the batch script unfortunately skips blank lines and therefore the line numbers do not match those of the INI and are therefore actually useless. In addition, I still don't understand what the indication of the line numbers is supposed to help. (I can find an entry also by its name in the INI, the line numbers are not needed for this). Maybe you can find someone who can rewrite the batch script according to your wishes or better rewrite it in another programming language. (By the way, since this is rather off-topic, we should discuss possible further things via PM.)

@Nergal CSGalloway's question was not directly related to Winapp2.ini, but to a batch script on GitHub. Unfortunately, I have very little time for other things at the moment, but with a little trick I was able to insert the leading zeros quickly. You can download the updated batch script on GitHub. Excuse me, but I don't quite understand the line number question. Which line number should be output where exactly? And what use is the information about the line number then? Since the batch script skips all blank lines, the line numbers would not match those in Winapp2.ini anyway. Please keep in mind that this is only a simple batch script. Compared to a "real" programming language it has very limited functionality and performance.

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.