tzdvl

(Except the above quote wasn't me replying...) Ah, Thanks! That makes sense. It appears Ccleaner is able to detect registry entries that are hidden from us mere mortals, but also is "wise" enough to not mess with those hidden entries. Ccleaner just TEASES us, by repeatedly showing an entry as an error, even though it can't (shouldn't) actually be fixed! Glad I'm not the one sorting all this out! And thanks to you moderators for the excellent advice!

Again: Reply from Nukecad:

I guess what I'm interested to know is, how is Ccleaner's registry cleaner "finding" and displaying an "erroneous" registry key that doesn't seem to actually exist? If I just simply open RegEdit, and navigate to the key HKCR\CLSID\{265b1075-d22b-41eb-bc97-87568f3e6dab}\LocalServer32 the (default) value shown is C:\Windows\System32\Speech_OneCore\Common\SpeechRuntime.exe -ToastNotifier But if I open Ccleaner and run the registry cleaner it displays the entry LocalServer32\C:\Windows\SysWOW64\Speech_OneCore\Common\SpeechRuntime.exe -ToastNotifier If I then right-click that entry, and select "Open in RegEdit...", RegEdit opens to the VERY SAME key, but the (default) value NOW shows C:\Windows\SysWOW64\Speech_OneCore\Common\SpeechRuntime.exe -ToastNotifier If I then close RegEdit (and Ccleaner, WITHOUT actually running the cleaner), reopen RegEdit, and navigate back to the same key, the (default) value has reverted back to showing C:\Windows\System32\Speech_OneCore\Common\SpeechRuntime.exe -ToastNotifier How is this possible? I've never seen a registry value change back and forth like that. How can Ccleaner appear to change a registry value without actually selecting the entry and running the cleaner?

I, too, have noticed that Ccleaner has recently been flagging the above registry error on my system the past few days... I understand and agree with the warnings about registry cleaning in Windows 10... BUT, I've found some REALLY WEIRD behavior in Ccleaner in this instance! First of all, on my computer the file in question (SpeechRuntime.exe) exists in the C:\Windows\System32\Speech_OneCore\Common\ folder. It is NOT present in the C:\Windows\SysWOW64\Speech_OneCore\Common\ folder. I understand why Ccleaner will flag the error if a registry entry points to the non-existent SysWOW64 location. NOW. if I open Ccleaner, and run the Registry Cleaner, I see the entry for LocalServer32\C:\Windows\SysWOW64\Speech_OneCore\Common\SpeechRuntime.exe -ToastNotifier . If I right-click that entry, and select "Open in RegEdit...", Regedit opens to the expected key, showing the value LocalServer32\C:\Windows\SysWOW64\Speech_OneCore\Common\SpeechRuntime.exe -ToastNotifier , as expected. BUT, if I simply close RegEdit, and reopen it to the same key, the value NOW shows the "correct" location LocalServer32\C:\Windows\System32\Speech_OneCore\Common\SpeechRuntime.exe -ToastNotifier . WHY is Ccleaner finding an erroneous registry value that apparently doesn't actually exist? And how can the value seem to change with simply closing regedit, and reopening to the same key?

OK, I did a little experimenting this morning, and it seems that the " ^partitionkey=%28http%2...." versions of cookies do not function to save logins or website preferences. I used the Amazon.com website for a trial. I cleared out my Amazon cookies, visited the website, signed in, and set my preference for saving my browsing history. I then opened CCleaner, and I see four cookies: After a few trials of having CCleaner save each of the individual cookies, one at a time, then cleaning the others, I found that having CCleaner save only the www.amazon.com^partitionkey+%28http%2camazon.com%29 cookie does NOT preserve my login or saved preferences. The only cookie that preserves my login/preferences is the amazon.com version. Curiously, saving just the www.amazon.com cookie does NOT work. So, out of the four trials, this is how I must use CCleaner's "Cookies to Keep" feature so that it works as it should: If I then clean the remaining three cookies, the Amazon website opens with me signed in, and my preferences intact, as I would expect. Interesting!

Because your (not partitioned) old version is globally keeping them? That is what I've been thinking. Maybe I should replace the "global" cookies I've saved with the site-specific versions? I'll have to experiment. I hope the developers can sort this out!

Thanks for the excellent explanation. Makes sense. I have never used CCleaner to clear or manage my logins or passwords in Firefox. I have always managed these directly in "Saved Logins & Passwords" under Firefox's privacy settings. CCleaner is set like this: I only use CCleaner to manage cookies in Firefox. I move any cookies I need to preserve new logins or preferences to "Cookies to Keep" before cleaning. That's why I was interested to know what to do with the " ^partitionkey=%28http% " cookies now being displayed. If I just continue to ignore and delete them, am I defeating Firefox's new management strategy? Should I replace my previously saved login cookies with the version specific to the "partitioned" website? How should users interpret the info shown in CCleaner? We need some guidance!

I have noticed that since the latest Firefox update to v85.0, CCleaner now displays most cookies in a format similar to: www.xyzxyz.com^partitionkey=%28http%2cxyzxyz.com%29 where it used to just display: www.xyzxyz.com and xyzxyz.com I think this is due to a change in how Firefox 85 handles (isolates?) cookies and "supercookies"? I don't begin to understand this stuff, but previously it was easy to save login cookies in CCleaner. The cookies now displayed in the new format are duplicates of my previously saved cookies, but cleaning out the "new" versions does not affect logins or preferences. In other words, it is not necessary to tell CCleaner to save the new versions instead of, or in addition to, the previous versions. Could someone explain how a CCleaner user should interpret and work with the "new format" cookies now displayed in CCleaner? Thanks!