APMichael

@Dave CCleaner: Thanks for the information. Unfortunately the bug is not completely fixed! The following DetectOS string is now working again: DetectOS=10.0|10.0 (= only for Windows 10) But this DetectOS string is now completely broken: DetectOS=|10.0 (= for Windows 10 and older) Because now it does not even work with an attached build number: DetectOS=|10.0.18363.959 (= for Windows 10.0.18363.959 and older)

Thanks for the new and revised entries: Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/53569aa911d38f8ce4aca373987ccbcf74ab6fae

I guess the problem is the same as reported here: The settings are stored in the file storage-sync.sqlite and CCleaner deletes the cache files. You should exclude the following for your Firefox profile: *.sqlite-shm;*.sqlite-wal

Thanks for the modified entry. Winapp2.ini update: https://github.com/MoscaDotTo/Winapp2/commit/7505e262e2dd3ad2a83aafca00a04477687287cb

@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