Winapp2.ini

Hopefully this version doesn't suffer from the same false positive problem the previous ones have but if it does we'll use the release version on the page above as the watershed release to have vendors whitelist

Hey Ishan! Hope you've been well!

They're being used by the Connected Devices Platform (user) service. Stopping it should allow the files to be deleted. Not sure if you'd need to stop the parent service (Connected Devices Platform) too

I think this might just be a build configuration issue, I'll tinker with visual studio and see if I can get it built correctly

DeleteMe keys are definitely caused by winapp2ool, I'll look into it! the beta version supports keys without a value so it may be worth checking out whether that fixes the issue Edit: This issue is not present in the beta, but it WILL break any intended functionality of the LCD keys which are not formatted the same way as other keys (though if I had to guess this is a ccleaner bug?)

wow! does this build work? https://github.com/MoscaDotTo/Winapp2/blob/Branch1/winapp2ool/winapp2oolXP.exe I thought it might be a quick fix so I just targeted that one change, this version of winapp2ool xp may be otherwise unpolished. if things seem weird let me know, and definitely let me know if it crashes still

@dvdbane this should be fixed in the latest beta build, sorry it took so long!

You can try running the Trim function of winapp2ool to rid yourself of these entries, however if CCleaner is detecting them and showing them to you, it means the removed software left whatever aspect of itself winapp2.ini is using to detect it. You have two options for ridding yourself of these "leftover" entries: manually delete the entry from winapp2.ini (be aware that it may return if the detect criteria are still present on the computer - which it sounds like they may be!) or manually delete the detect criteria from the computer. This will prevent CCleaner from detecting the entry as valid and will cause winapp2ool to actually Trim these entries out of your file after you've done it.

Good point, thanks!

Perhaps a check for wildcards (and semicolons) in ExcludeKeys with the FILE switch will suffice

https://github.com/MoscaDotTo/Winapp2/#how-to-use-winapp2ini-for-the-following-cleaners

This is an error, I'll look into it when I've some time this week

Generally what I expected, the limitations of the (front end) scripting interface are pretty apparent when you consider some of the problems we try to tackle with winapp2.ini (and increasingly lean on code generation from winapp2ool to handle). barring some major rewrite of their ini interface, i would expect increasingly many future additions to the application to rely on these.

The changelogs used to be more specific about winapp and winsys changes. the best option is to diff the built in ini files between versions

@dvdbane Do the keys that are not in wow64node exist on your system too?

Thanks for pointing this out, I'll look into it when I get some time

It may be worth looking into the fact that although Easy Clean doesn't support winapp2.ini, it does seem to be doing expensive work when a winapp2.ini file is present

I must admit I did not attempt to reproduce the behavior before making my post and I do see the perceived difference between the issues If I had to guess, when CCleaner loads the Easy Clean mode (either by default or when switched to as a tab if not loaded first), it force reloads its configuration including winapp2.ini (even though it is not used) and does so before it displays its pane (ie. before the ccleaner window is spawned if the easy clean tab is the default), probably blocking the main thread while it does so If you set the default tab to custom clean, you'll observe the normal delayed availability of the buttons as expected, but when switching to the custom clean, my ccleaner window became non responsive before switching and then once again after it loaded The best you can do to treat this as an end user is to trim winapp2.ini which is why I suggested it; Given that this seems to be a pretty glaring ccleaner bug, I'd suggest you post it to the bug report sub forum: https://forum.piriform.com/forum/8-ccleaner-bug-reporting/ I'm not a ccleaner developer so I don't have the agency to fix the bug you're describing here, but I think they'd be keen to hear it. I think ultimately the slow loading of the large ini is the fault here and you'll see it whether it happens before or after the window displays itself; untrimmed ini clearly had the longest delay on my machine, the trimmed ini was still slow to load but noticeably faster, and an empty file just called winapp2.ini caused no delay at all

The general solution to this is to trim the winapp2.ini file, ccleaner will load much more quickly. I wouldn't imagine CCleaner's mechanism for loading entries was ever intended to handle the thousands of entries the untrimmed file contains I think this is right and the suggestion i'd have is for the developers to simply defer loading winapp2.ini until the custom clean screen is loaded if it's not supported in the easy clean

It follows the same structure as %appdata%\mozilla\profiles

Should definitely include a warning alongside this if one is created; this folder is typically created as part of the "refresh firefox" process and can contain important data. It's also optionally created when uninstalling firefox as a profile backup

Downloads are still available at mirror sites right now, I don't think we need to jump onto alternatives just yet Loads of people offered hosting on Twitter but the developer didn't respond

Enabling BITS on nightly for me results in the update downloading only after pages have loaded

I think the Clover entry is correct as it is, IIRC.

The new firefox branding seems to be launching