rhino

yeah restarting and installing from scratch didn't change anything. But I may have found where the issue comes from, not very precisely but that's already a lead. First to the fact that the hang with IE history cleaning occurs one time out of two, that's just because IE history gets actually cleaned during the first try, and there's nothing to clean the second time - obviously. As to what may be the possible cause of the problem, ie where CC gets stuck, I found that the issue disappears after uninstalling "Messenger" and "Messenger companion" from Windows Live 2011.

I think I've been reporting that in the past. Stopped happening and it happens again with 3.06.1433 (64bit). It happens exactly one time out of two, and when it does I must kill CC process and restart it, then np, any clue? I have reinstalled CC, not using any ini file, so from scratch, no change. edit: the issue only involves IE history

found that the latest version of CC (3.04) was compacting "global-messages-db.sqlite", ie global search database in Thunderbird. I know that some people complain about the fact that this file's size increases constantly, but I'd rather that CC wouldn't tale care of it. And I can't see Thunderbird in CC application scope in the UI. So how can I disable that checking? thanks. ...but wait... having a closer look at CC Firefox section, I see that it's in fact called Firefox/Mozilla, meaning that it may include Thunderbird at least for the setting "compact databases" usually restricted to urlclassifier.sqlite in Firefox. So I may have the answer to my question. Remains that I would have prefered two separate settings for FF and Thb

- only URL I visit before testing the cleaning ability in CC is my homepage ... www.google.com )) - I got all rules checked except "passwords" - no I don't have IE9 running when cleaning (but I've noticed in the past that, at the contrary of FF and Chrome, it was possible to clean IE with CC while IE was running). Also, I just checked history again and cc gets stuck while cleaning as I described. There's no instance of IE that appears to be running in task manager.

... and now that I re-enabled other cleaning parameters for IE9, history cleaning freezes again. Gets solved again after disabling tracking protection. This must be linked to the cleaning of something else, index.dat may be...and only when tracking protection is running.

yeah that's funny, and this explains why during a few days with IE9RC there was no problem; I just turned tracking protection back on and CC can still clean IE history normally, meaning that to solve the issue you just have to switch that off and back on in IE9.

okay I got it,first no if I leave just history checked that doesn't change anything, but I found the culprit: it's the new "tracking protection" system when enabled, then the issue occurs in CC. As soon as you turn it off, CC cleans IE9 history normally. ps: thing is that as mentioned some similar issue happened already a while ago, in IE9 beta, when the tracking protection didn't exist yet. Must have been the "in private filtering" at the time I suppose, explaining how it could happen with IE8 too for others.

I use normal deletion, no secure one. On a side note, just saw in another section of your forum that a user was having a similar issue on IE9. So I wanted to mention that a few other users reported on another forum where I post that this happened to them on IE8 as well some times ago (end 2010). What I don't get is why, like the first time, it suddenly happens, without any CC update, and without any IE update... I updated to IE9 RC a few days before getting the issue.

okay I attempted a re-install, same result. Tried to use the 32 bit executable, same problem. I'll just have to exclude IE history from CC from now on. ps: I'm runing IE9RC on W7/64 edit: forgot to mention, if I attempt to create a dump file while CC is freezing I get an access denied message.

hi guys, this is happening for the second time, CCleaner gets stuck while attempting to clean IE9 history. Last time was a few builds ago and it was taking ages to complete, this time it's worse, there's the spinning animation indefinitely there with no hard disk activity whatsoever, must close CCleaner from the "x" button. If I click cancel CCleaner crashes and freezes. This added to the issue with Chrome (no cleaning by CC if cookies set to be deleted at Chrome closing time)... I guess we need a new build. Thanks

the question has probably been raised before, why does CCleaner (as well as other Piriform products), need to open a web page in a browser to check manually for updates, couldn't you integrate the manual update check in the software, with just a dialog box popping up etc... I mean the program is already able to do that silently for automatic checks, so why not simplify the manual checks? thanks.

okay lastpass issue fixed for me with this version, thanks a lot

okay, thanks for taking care of that

okay I'm not testing this again, as for the second time, on top of impacting lastpass behavior, it does also impact the behavior of another extension that relies on the HTML5 db, i.e. notscript, and even re-installing it does't bring back the normal behavior, first page displayed in a chrome session must be reloaded several times until notscript gets detected, and the only way out is create a new profile. Already happened yesterday; seems like CC 3 is breaking the profile somehow. That's not good. I'll stop using CCleaner until this gets solved.

okay after a reply from LP developer, I could verify and confirm that cleaning Chrome cookies from CCleaner 3.0 modifies the html5 database in such a way that the email address entered in LP dialog to login gets lost. CCleaner shows on top of cookies a supposed to be Okb cookie file...not sure what that is. Anyway I've been also told that the LP guys are ready to work with the ccleaner team to solve the issue: the thread is there: http://forums.lastpass.com/viewtopic.php?f=12&t=46379&start=0