RunAmok

Even though my default browser is FireFox and I seldom use IE, starting with version 5.23 (and both versions of 524) CCt takes 4 or 5 times longer to run. The program appears to be grinding while cleaning something close to (this is from memory, so it could be wrong) C:\Users\username\Windows\History\IE5\somethingmore.... file associated with the current user. Interestingly, after running an Analyze and viewing the details of every top level section that's about to be cleaned, there's no hint about this path. So, it this something that wasn't being cleaned up though 522 but is now, or is it a bug trying to clean something which isn't needed in a FF environment? In any case, it sure takes a long time to do whatever it's doing. W7x32 Pro, FireFox 50, IE-11

Thanks. It must have been some temporary system glitch. After a reboot and another extract, everything works normally as it usually does - even though I'd tried it several times last night.

CCleaner 412 portable starts a process but never displays a screen under XP x32 SP3.

Thanks for the link. I can also confirm that it works right after a boot, that version 1.19 and 1.20 fail the same way, but somewhere during the day something changes and it goes back to populating the Graphics tab info with "marked for deletion" instead of listing the monitor and the fact that the video hardware on the motherboard is Intel based. Just tried again, and was working with a windows explorer window open but fails now with this FF window open. Edited to add: Once I've opened a browser window, speccy fails when I run it - even after I've closed the browser and speccy is the only thing running. The funny thing about that is that I'd had browser windows open off and on all moring and speccy was still working a couple minutes ago when I tried it. Gut feeling is that the error message is trying to tell us that some file or system attribute it wants to read is temporarily locked rather than "marked for deletion".

Dell motherboard, Northwood Pentium HT processor, with Intel 82865G graphics controller on board. Running XP x32, SP3. The summary and Graphics tab both say "The specified serviced is marked for deletion".

For what it's worth, Speccy 119 still shows the correct product key under XP. Of course, you won't find in in the registry since it's encoded/encrypted there. From the above, I'm guessing that they changed the encryption under W7 and W8 and Speccy is not decrypting it correctly?

Nergal, I don't have a clue why that key was there. This system was set up four or five years ago with XP, and it's stayed with XP (plus a service pack and a pot-load of patches) ever since. I don't remember exactly which release of CC I last did the 'full' uninstall (with registry cleanup), but not that long ago - somewhere around the 3.16-3.18 range, it was still regenerating that key when it installed. I'm sure the dev's could explain why that key was added on an XP system 'back when', but the bottom line is that the newer versions should check for the AppCompatFlags\Layer entry (which was the only one there) with the C:\program files\ccleaner\ccleaner.exe REGSZ WIN95 contents, and either delete that key, or the entire AppCompatFlags key if the CC contents is the only thing in the Layer entry - which mine was. The newer versions don't add that key, but they don't delete it on an uninstall - which would have fixed the problem several releases ago.

First the good news.... I've fixed ALL the annoying and persistant problems I've had with CCleaner, starting almost a year ago - the failure to correctly empty the recycle bin if it contained a folder, and failure to delete folders elsewhere, both of which begin in release 3.11, and even the Recycle Bin icon not changing from full to empty problem which begin in release 3.19 (I think - I've lost track along the way). All along I've strongly suspected it was something in the registry ever since I learned that the portable versions worked and the installed versions (both free and Pro) didn't. Multiple times along the way when I'd tried the old 'uninstall/reinstall' trick, (plus a registry scan to delete any left over CC keys) I'd found one 'leftover' registry entry which made me raise an eyebrow as I went through the registry and deleted any CCleaner entries after an uninstall. There was a key in HKCU\Software\Windows NT\CurrentVersion called "AppCompatFlags" which contained a sub-key called "Layers" populated with the full path to CCleaner's exe as a REGSZ set to "WIN95" - which stuck me as strange, but... every time I reinstalled, it was back, so I sorta ignored it as some strange thing that CCleaner's install did under XP for reasons known only to Piriform. This time though, when I discovered that CC worked as it should when logged in as the system's Administrator ID (which I seldom use) and still failed when logged in under my own admin ID, comparing the registry HKCU entries between my ID and the Administrator ID, it reminded me about that key and the suspicious WIN95 value since it wasn't there in the Administrator's HKCU. To make a long story at least a little shorter, CCleaner installed versions, both Free and Pro, up to somewhere between 3.18-3.22 set that key - but only in the HKCU list for the id you're logged in with when installing. And that may even include releases before 3.10 although it only began causing the problems in 3.11. If you delete that "AppCompatFlags" key, CC works as advertised, correctly emptying the recycle bin and deleting folders where expected. From at least 3.23 on (and maybe several releases earlier), that key is no longer set by a fresh install. And though I'd done half a dozen uninstall/reinstall (some with reg scans to remove 'left over' keys, some without) along the way), even when uninstalling 3.25, that key is not removed if it exists.

It's been almost six months, multiple releases, and quick tests to determine that the reported problems were still not fixed. But as occasionally happens, a stroke of luck and a new thought about how to proceed is often is worth the effort. First the good news.... I've fixed ALL the annoying and persistant problems I've had with CCleaner, starting almost a year ago - the failure to correctly empty the recycle bin and failure to delete folders elsewhere problems which begin in release 3.11, and even the Recycle Bin icon not changing from full to empty problem which begin in release 3.19 (I think - I've lost track along the way). All along I've strongly suspected it was something in the registry ever since I learned that the portable versions worked and the installed versions (both free and Pro) didn't. Multiple times along the way when I'd tried the old 'uninstall/reinstall' trick, (plus a registry scan to delete any left over CC keys) I'd found one 'leftover' registry entry which made me raise an eyebrow as I went through the registry and deleted any CCleaner entries after an uninstall. There was a key in HKCU\Software\Windows NT\CurrentVersion called "AppCompatFlags" which contained a sub-key called "Layers" populated with the full path to CCleaner's exe as a REGSZ set to "WIN95" - which stuck me as strange, but... every time I reinstalled, it was back, so I sorta ignored it as some strange thing that CCleaner's install did under XP for reasons known only to Piriform. This time though, when I discovered that CC worked as it should when logged in as the system's Administrator ID (which I seldom use) and still failed when logged in under my own admin ID, comparing the registry HKCU entries between my ID and the Administrator ID, it reminded me about that key and the suspicious WIN95 value since it wasn't there in the Administrator's HKCU. To make a long story at least a little shorter, CCleaner installed versions, both Free and Pro, up to somewhere between 3.18-3.22 set that key - but only in the HKCU list for the id you're logged in with when installing. And that may even include releases before 3.10 although it only began causing the problems in 3.11. If you delete that "AppCompatFlags" key, CC works as advertised, correctly emptying the recycle bin and deleting folders where expected. From at least 3.23 on (and maybe several releases earlier), that key is no longer set by a fresh install. And though I'd done half a dozen uninstall/reinstall (some with reg scans to remove 'left over' keys, some without) along the way, even when uninstalling 3.25, that key is not removed if it exists. Oh, and one more little tidbit... That key existed in both HKEY_Current_User and in HKEY_Users, but when I deleted the key in HKCU, it was no longer there in HKEY_Users. Another little piece of registry functionality and interdependence I was not aware of. It's been a long journey.....almost a year. I could continue, and do a bunch more testing to see what releases set that key, etc, but... I've put all the time into this one (and then some) that I'm going to.

iopl, I've been down that road many times as I try to figure out where the problem is. The bottom line is that removing the current version (and any registry entries left behind by the uninstall) and installing version 3.10 works. Doing the same thing and installing any version after 3.10 does not. But for some reason, the portable versions always work fine.

Weird.... First of all, when I try to select the recycle bin, CC won't let me specify what I want. If I try to use the "folder" option to specify Sxxxxxx, it won't let me browse any farther than Recycler. The Sxxxxxx directory is never shown - even though I'm set to view hidden and system files/folders. If I try to specify a "file", it then lets me see Sxxxxx (and the folders in there), but wont allow any options as far as file types or wildcards. And it won't delete Recycler in the first case, or Sxxxxxx in the second case - which doesn't surprise me since both do have hidden or system attributes.. I also tried it with the folder option using the full path to %temp% and specifying *.* for the file name option, plus setting it to "all files, folders and subfolders". By the way, if I specified "*." (star-dot) for a file name, it came back with an error message box telling me that was not allowed "For system safety reasons". Anyway, a DOS window confirmed there were files and folders there to start with, and the Analyze showed the Temp Files line - with content - but... when I ran it, once again it deleted all files but not folders. A second Analyze didn't show the Temp Files line - which by then contained only folders. Sooooooo... we know that this XP install - which works normally for everything else but is obviously somehow weird, is causing CC to screw up. I'm still digging to figure out what/why - and how CC "does it's thing"' which trips over whatever weirdness I have here. And again, for whatever reason, the portable version works as advertised here. Shodan, In your case, I'm still guessing that CC may be programmed to bypass what it thinks are 'reserved names', but will apparently do so if you've config'd a specific "Include". Still... that doesn't explain why it fails to delete those folders when they're in the recycle bin (where they should be fair game no matter what) and renamed to whatever special naming convention the recycle bin uses - although at that point it could determine what the original directory name was from looking in the INFO2 file.

I tried to duplicate this under XP Pro x32 SP3 using various combinations of file names (up to 52 characters), sizes, paths, etc. I could not duplicate the failure as posted with secure delete enabled, although it did still fail to delete a folder in the recycle bin as described all through this thread. As we've seen from other posts in this thread, there is definitely a problem cleaning the recycle bin in both XP and W7. The symptoms vary, possibly depending on differences between Windows releases or some other installation specific condition not yet nailed down, but in all cases CC appears to have cleaned the recycle bin (and a subsequent run and Analyze sees nothing to delete) but the recycle bin still contains something (in my case, any folder which was in there to start with). Windows Explorer displays a combination of what it finds in the recycle bin and the contents of the INFO2 file which holds the details for each file/folder in the recycle bin, and CC correctly cleans the INFO2 file, resetting it to it's 'empty' state. But the actual folder is still there. Windows Explorer won't display anything at that point since there's no details in INFO2 to display, and the recycle bin 'Open' does the same, but a cmd window using the 'dir' command shows what's still there - and can be deleted with no problem using an rmdir command.

Alan, I can appreciate CCleaner saving me from myself when there's a good chance I'm about to do something stupid, but... I should point out that for an administrator who's chosen to vew hidden and system files, Windows Explorer will happily allow me to send read-only, hidden, and even system files to the recycle bin via the delete key or by the Delete option if you right click. For hidden files, it does the delete with no questions asked. For RO and Hidden files/folder, it simply asks for confirmation first. There's only so much you can do to save me from myself.... With the execption of the recycle bin where whatever's there has already been 'confirmed' if needed and should be fair game, perhaps an "Are you sure?", at least for system files, might be a nice touch....

Shodan, It looks like you're in the same boat I am, and also looking for a paddle. I tried your test, both here on my primary XP Pro system and on my wife's XP Home system. Here, it failed because it was a folder and this system is weird when it comes to folders. On the other system it worked just as you'd expect it to.

Shodan, Since this particular XP Pro system seems to think that all folders are pseudo-read-only - at least according to Windows Explorer, even when the RO attribute is not set - I can't really do a valid test here. All folders do show up in the analyze for the recycle bin (but not those in %temp%), but folders are not deleted, whether or not they're in the recycle bin or in some place like %temp%. In the recycle bin, Info2 contents are set to empty but the folder itself is not deleted. In %temp%, any files are deleted but folders are not. But I did some testing on my wife's XP Home pc (with appropriate caution) and found that CC 3.19 doesn't care if a folder has 'system', 'hidden', 'read-only', or any combination of the three attributes set when it's in the recycle bin. The short answer is that it's Windows XP Pro here not allowing CC to work as it should. But... that doesn't explain why version 3.10 still works, the portable versions work, and all versions downloaded and installed since 3.10 fail. It sounds like you're on a newer Windows release than I am, and your symptoms lead me to wonder if there is a list of 'special' names that CC ignores by design..... Nergal, You're right of course, and that's exactly what I do when I end up with a folder that CC can't remove from the recycle bin. Right-clicking on the recycle bin and clicking on "Empty" works just fine - even if CC has left the recycle in in some weird state. Unfortunately, that's not a workable option here for all those other places which CC attempts to clean but leaves any folder behind. And again, dropping back to 3.10 works as expected. I'm sure it's a full time job changing CC to match where each new version (or patch) in Windows moves things, but it sure would be nice to figure out what changed between 3.10 and all later releases to create the problem this Windows install presents.