Jump to content

RunAmok

Experienced Members
  • Posts

    59
  • Joined

  • Last visited

Everything posted by RunAmok

  1. 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
  2. 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.
  3. CCleaner 412 portable starts a process but never displays a screen under XP x32 SP3.
  4. 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".
  5. 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".
  6. 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?
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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....
  14. 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.
  15. 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.
  16. Shodan, On my XP system, the "Send To" folder really does have both the read only and hidden attributes set and when I copy it to some other location those attributes copy too. So I can see that CCleaner might be cautious about deleting a folder with either (or both) attributes set - although it does delete files set as RO as expected. And in fact, in a command window under XP here, if you try to delete a folder with the RO attribute set, it warns that it's read-only and asks if you want to continue - but still doesn't delete it if you answer Y. If you try that with a file set as read only, it simply refuses although Windows Explorer will warn and then move it to the recycle bin. Obviously, Windows (and a cmd window) does handle that RO attribute differently and the cmd window won't let you delete read only folders - or files. In Windows Explorer, if you try to delete a folder with the RO attbibute set, it again warns and asks for confirmaton, but will move it to the recycle bin if you say Y. But... having been warned and given the choice to continue, even though that folder is in the recycle bin with the RO attribute set, a manual empty of the recycle bin does remove anything you put there - including that folder with the RO attribute set. CCleaner may be tripping over the fact that even in the recycle bin, it's still a folder with the RO attribute set. I guess it depends on how CC is programmed to do the deletes on what's in the recycle bin or whether it fails to make an exception for bypassing deletes of RO folders when they're in the recycle bin. And that obvously changed between release 3.10 and 3.11. What I still don't understand is why the portable version works and the downloaded/installed version doesn't - since I'm told they're the same executables although the portable version doesn't look at the registry..
  17. Alan_B, W.E. not reflecting changes would appear to explain some of the strange things I mentioned. But in this case where it seems to show the RO attribute set and DIR shows it's not - with no changes made for months - I think it's trying to tell me something (which CC evidently 'sees' as well) that I can't figure out - yet. DIR tells me that it's not really the RO attribute, and it's not an inherited NTFS permission since it allows me to change it without warning me that it's inherited and I can't change it at that level. I've learned, for example, that W.E.will 'help' us by displaying what it thinks we want to see. For example, it displays the contents of the recycle bins on all hard drives as if they were one recycle bin - no matter which one you're looking at with W.E.. if you use W.E. to look at the subdirectories of RECYCLER on either of two hard drives C: and F:, it shows the interpreted contents of the RECYCLER folders from BOTH drives - but not the actual files and folder names as they exist in each RECYCLER. If I delete a file called test.jpg from some location in the file structure, what's actually in the username folder under RECYCLER is a file named DC4.jpg and detailed info about that file's original path and informaton/attributes contained in a hidden file called info2. W.E. won't show that, (or that info2 exists for that matter - even though I can see hidden and system files elsewhere) but shows you the original path/filename which it obviously pulls from the contents of info2. It shows me what it knows I want/need to see, but not what's really there. And one other wierd thing I found in my testing.... I deleted a file from my desktop - C:\Documents and Settings\username\Desktop - but using cmd.exe and DIR, I found that file ended up in the recycler on the F: drive with all the correct path and details in that info2 so that it could be restored if necessary. Go figure.... Everything works as expected since Windows handles all recycle bins as one big recycle bin, but... that sure wasn't what I expected to see.
  18. Rather than wear my fingers down another sixteenth of an inch repeating everything I just typed, check out my last entry here... http://forum.piriform.com/index.php?showtopic=35491&pid=216430&st=20entry216430 It explains why trying to empty the recycle bin on my system fails when it contains a folder. Doesn't explain the latest symptom where the recycle bin icon doesn't change from populated to empty when CC emptys it correctly if it only contains deleted files though. But progress is progress... right?.
  19. OK, after some testing, I can confirm that CC version 3.10 will delete a folder that's marked as read only (but see test results below) and any release from 3.11 on will not. I could buy that. Kinda. It does strke me as a shotgun approach to fix some specific problem where CC deleted some special folder which caused a problem though. CC doesn't seem to care about read only files, but it sure does care about read only folders. And I can't explain why the portable version doesn't care if a folder is set to read only and works as expected, but the normal install does care and won't delete them. Nor can I explain why, on this XP Pro x32 SP3 system ALL folders show as read only when I check the properties using Windows Explorer (and can't be reset) but the same folders do NOT show as read only when checked from a cmd/DOS window. Viewing properties on a newly created test folder on the desktop (or any folder anywhere else for that matter) from Windows Explorer, the read only check box is totally green. I can click on it (it's then empty), click on Apply (it stays empty), but if I move to somewhere else and come back to check properties again, it's all green again. If, while I'm still looking at a folder's properties from Windows Explorer, I click on the read only box again when it's empty, I get a green check mark. And if I click Apply, I then see that it really is marked as read only when tested from a cmd/DOS window. But again, if I go somewhere else and come back to check properties from Windows Explorer, the read only box is all green again. And that's true even if I've reset the RO attribute from the cmd/DOS window. For some reason, even though I can see that a folder does NOT have the read only attribute set (from a cmd/DOS test), there's something here that CC - and Windows Explorer - still sees and handles as if read only was set. Add one more entry in the Windows Wierdness list... Sometimes Windows makes my head hurt.... But at least I know now what changed in CC between 3.10 and 3.11, and why I started this chain with the symptoms I see on this system.
  20. Shodan, I'd guess that CCleaner is written to function by following the old "Above All, Do No Harm" directive. If it 'knows' that a folder can safely be deleted, like in the recycle bin or in other known and designated places like %temp%, for example, I expect it to clean up the junk. In other places however, it may not know for sure if a folder with special attributes is safe to delete or not (and it's not unlikely to find Windows or Application software creating such things in unexpected places). And there may be specific names which is 'knows' should be exempt, But I'd rather it took the safe path and bypassed the delete if there was any question. Although everything else here seems to work as expected, there appears to be something unique in my system causing what I see here, so I can't test combinations of special attributes here since CC doesn't appear to delete any folders - whether or not they have special attributes like system, hidden, read only, or some other NTFS attribute I'm not aware of. The problem began with release 3.11, and has continued up through 3.19, but CC still works normally with version 3.10. It only fails with the normal downloaded package and works with the portable version - and version 3.10 or the portable version of the current release are options you might try. That difference between normal and portable suggests my problem is due to something in the registry , but... I haven't been able to find anything that looks suspicious other than two 'legacy' entries which are set to :"WIN95" even though I'm running XP SP3 32bit.
  21. Once again, the latest downloaded and installed version (3.19.1721) still fails to correctly empty the recycle bin if it contains a folder - as detailed above. In an interesting twist that's new with 3.19, if I run CCleaner from the "Run CCleaner" recycle bin link or from a cmd window with the /auto option - or even from the app itself using analyze and clean, and there's only files (and no folder) in the recycle bin, it correctly deletes the files, but the recycle bin icon on the desktop still shows that it contains files. It doesn't. The only thing in either recycle in is the info2 file which appears to be correctly reset to the 'empty' content. And the "Empty" link from right-clicking on the recycle bin is greyed out. The only way to change the icon from 'populated' to 'empty' is to delete a file and use the 'empty' from the recycle bin options - which of course works as expected.
  22. I tend to forget that some of the details in the original recycle bin post weren't duplicated here.... Yes, the 24 hour boxes are unticked for both the recycle bin and Windows temp folders.
  23. As on old troubleshooter, I'm certainly aware that trying to find and fix a problem reported by the field is very difficult when you can't reproduce it locally. The first question I always tried to answer was "What changed?" There are usually a pot-load of possibilities, but I think we've narrowed down the possibilities - both here and In the original post describing problems deleting a folder in the recycle bin. The latest test described here http://forum.piriform.com/index.php?showtopic=34160&st=40, a should be another clue and might help. To summarize that entry here, CCleaner releases from 3.11 through 3.18, downloaded and installed, fail to delete folders in my environment. 3.10 and the portable versions of the last two releases work as expected, and the .ini files for the failing version and the portable version of 3.18 were identical in the test. The recycle bin problem can easiy be overcome by simply emptying the recycle bin using the recycle bin "Empty". But for all the other places that folders need to be deleted, the solution is not nearly as obvious. For all those other places, there's simply no quick and easy way to get around what the installled versions of CCleaner isn't doing - beyond sticking with the portable version.
  24. Thanks Alan, That's a very logical next step and one I should have tried when I found that the portable version worked. I ran 3.18 as received, after creating a folder, copying a file into it, and deleting it. Got the symptoms I've described all along. Manually emptied the Recycle Bin to start from scratch. I created and deleted another folder, (and brought up a browser to at least create a few things which needed to be cleaned), and then unzipped the portable version in a folder on the desktop. I opened CCleaner, made sure that all the tick boxes were identical, including options/settings and the registry options, reset the save/delete cookies to what they had been, and then ran the portable version. It worked exactly as it should have, correctly emptying the Recycle Bin and deleting all the folders which had been left in %temp%. The ini files are identcal - except for one line which only existed in the original version and which for some reason still says "NewVersion=3.17.1689" even though the screen itself confirms the revision is 3.18.1707. That may have been the last time I changed a tick box. There were some minor differences in the window size numbers, but everything else matched perfectly although they were in different order. I did try swapping the ini files, and both ran as they had before with the full version failing and the portable version working. From what I've read in the information provided as this chain progressed, that suggests to me that the problem lies somewhere in the registry (or how CCleaner began to interpret the registry beginning with release 3.11) since installing 3.10 works, the latest two portable versions work, and every installled release after 3.10 fails.
  25. @SuperFast, it's not that anything in the recycle bin can't be deleted. Everything deletes as you'd expect using the Recycle Bin icon's 'Delete" link. The only problem is with CCleaner after release 310 (and is still happening in 318) which won't delete folders. I'd noticed that the latest release notes mentioned something about folders, but... it's still not deleting folders in either %temp% or in the recycle bin. Or, as I've just found, in places like C:\Documents and Settings\username\Local Settings\Temporary Internet Files\Content.IE5 which currently has over 40 folders - but no files in any of the folders now that I've run CCleaner. That's also true in Local Settings\History\History.IE5 (where Windows Explorer 'translates' what you see) but a DOS dir shows 8 directories dated back to the last time I ran 3.10. There's just something about folders on this system that CCleaner (beyond version 3.10) doesn't want to delete. There are, of course, some which are 'hidden', some 'read only', some both 'hidden' and 'read only', etc, but... most are just plan ordinary directories with no special attributes. In most cases, the high level folder (like %temp%, or recycler) needs to remain, but any folder under that should be deleted. And here at least, that's not happening.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.