TechHarmony Posted October 25, 2011 Share Posted October 25, 2011 I've been exploring issues surrounding the Windows Log files and realized that I should make a formal suggestion request for this: Please have CCleaner default to NOT Remove ("clean") the Windows Log Files. This is one of the settings that I always turn OFF/Un-tick on every CCleaner setup, both for my own machines and for the machines that I work on. (and have been un-selecting/un-tickmarking this option for years.) (ref another post, I agree with 'taxshack' that CCleaner should not, by default, ever remove Windows Log files.) With relatively few exceptions these files take very little space (one exception being Datastore.edb, which is 100 MB in my machine, and which I seems to be already excluded by CCleaner). And, in my opinion as an independent tech support worker, these Windows log files should be retained in order to know what Windows components have been updated on the machine. I WISH WISH WISH that the default was to LEAVE THEM ALONE. FYI, on my machine, where I have manually removed some of the more ancient windows updates and their corresponding log files, the CCleaner Analyze results shows: System - Windows Log Files 24,366 KB 111 files These are 24 MB that I am glad to have on the machine. I also un-tick the cleaning/removal of the Memory Dumps, as i use them to help track down causes of Blue Screens. I think they should default to un-tick as well, but some may see this as a more specialized case. Thank you for considering. The Universe is intelligent and friendly 8-) Link to comment Share on other sites More sharing options...
Winapp2.ini Posted October 25, 2011 Share Posted October 25, 2011 I have yet to see the developers change a default, but they do read the threads, so perhaps you'll see this happen winapp2.ini additions thread winapp2.ini github Link to comment Share on other sites More sharing options...
Moderators Nergal Posted October 25, 2011 Moderators Share Posted October 25, 2011 +1 that certain logs should not be touched. However I didn't find any of the important logs being removed EVERY single event viewer log was untouched by the entry (this is windows 7, I'll check XP tomorrow when I've access to a box I can test on) what in the following detail are you unhappy for the removal of C:\Windows\system32\wbem\Logs\wbemess.log 1 KBC:\Windows\system32\wbem\Logs\wmiprov.log 4 KB C:\Windows\DPINST.LOG 18 KB C:\Windows\KB893803v2.log 1 KB C:\Windows\PFRO.log 2 KB C:\Windows\setupact.log 3 KB C:\Windows\setuperr.log 0 KB C:\Windows\CleanMem Setup Log.txt 25 KB C:\Windows\Debug\mrteng.log 1 KB C:\Windows\security\logs\diagnosis.log 6 KB C:\Windows\security\logs\winlogon.log 53 KB C:\Windows\security\logs\diagnosis.old 7 KB C:\Windows\security\logs\scecomp.old 1 KB C:\Windows\Logs\CBS\CBS.log 372 KB C:\Windows\Logs\DPX\setupact.log 3 KB C:\Windows\Logs\DPX\setuperr.log 0 KB C:\Windows\ServiceProfiles\LocalService\AppData\Roaming\PeerNetworking\3ce899c34f5a5e01abf2da555d9ff1796b1f13d8.HomeGroupClassifier\e85835cdec46b8df4116a9e25ecf1abc\grouping\edb00011.log 256 KB C:\Users\*********\AppData\Local\Microsoft\Windows\WindowsUpdate.log 6 KB C:\Windows\inf\setupapi.app.log 947 KB C:\Windows\inf\setupapi.dev.log 356 KB Also as always when you first install ccleaner (or even when you update it) it's best to look and see the options to make sure you want them checked off, so it's actually helping you in your installs to have it default because it makes you look. users also should analyze and look over that log before hitting clean and one or more logs could always be excluded letting the others be cleaned. I guess what I'm saying is what exactly are you afraid of losing? I don't even see Datastore.edb as being listed in the log cleanup. The following is everything cleaned by the log entry [Windows Log Files] ID=1017 LangSecRef=3003 LangRef=3145 Default=True FileKey1=%SystemDirectory%\wbem\Logs|*.log FileKey2=%SystemDirectory%\wbem\Logs|*.lo_ FileKey3=%windir%|*.log FileKey4=%windir%|*.bak FileKey5=%windir%|*log.txt FileKey6=%commonappdata%\Microsoft\Dr Watson|*.log FileKey7=%commonappdata%\Microsoft\Dr Watson|*.dmp FileKey8=%windir%\Debug|*.log FileKey9=%windir%\Debug\UserMode|*.log FileKey10=%windir%\Debug\UserMode|*.bak FileKey11=%windir%|SchedLgU.txt FileKey12=%windir%\security\logs|*.log FileKey13=%windir%\security\logs|*.old FileKey14=%windir%\SoftwareDistribution|*.log FileKey15=%windir%\Logs|*.log|RECURSE FileKey16=%windir%\ServiceProfiles\LocalService\AppData|*.Log|RECURSE FileKey17=%windir%\ServiceProfiles\NetworkService\AppData|*.Log|RECURSE FileKey18=%LocalAppData%\Microsoft\Windows|*.log|RECURSE FileKey19=%AppData%\Microsoft\Windows|*.log|RECURSE FileKey20=%windir%\Microsoft.NET|*.log|RECURSE FileKey21=%LocalAppData%\MigWiz|*.log FileKey22=%LocalAppData%\MigWiz|*.xml FileKey23=%windir%\inf|setupapi.app.log FileKey24=%windir%\inf|setupapi.dev.log FileKey25=%windir%\Panther\UnattendGC|setupact.log FileKey26=%windir%\Panther\UnattendGC|setuperr.log FileKey27=%windir%\Panther|setupact.log FileKey28=%windir%\Panther|setuperr.log Again I don't see Datastore.edb listed anywhere; nor is .edb in any of the default cleaning rules (system or applications) which can be obtained by running "c:\program files\ccleaner\ccleaner.exe" /export (with the quote marks replace c:\program files\ccleaner with the location of your ccleaner) ADVICE FOR USING CCleaner'S REGISTRY INTEGRITY SECTION DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF. Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark) ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T. Support at https://support.ccleaner.com/s/?language=en_US Pro users file a PRIORITY SUPPORT via email support@ccleaner.com Link to comment Share on other sites More sharing options...
Moderators Andavari Posted October 25, 2011 Moderators Share Posted October 25, 2011 Perhaps create a default ccleaner.ini, with all your pre-saved preferred settings in it with those boxes unticked you never want cleaned. Link to comment Share on other sites More sharing options...
Moderators Nergal Posted October 25, 2011 Moderators Share Posted October 25, 2011 I like that idea ADVICE FOR USING CCleaner'S REGISTRY INTEGRITY SECTION DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF. Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark) ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T. Support at https://support.ccleaner.com/s/?language=en_US Pro users file a PRIORITY SUPPORT via email support@ccleaner.com Link to comment Share on other sites More sharing options...
Winapp2.ini Posted October 26, 2011 Share Posted October 26, 2011 I also support it winapp2.ini additions thread winapp2.ini github Link to comment Share on other sites More sharing options...
Alan_B Posted October 26, 2011 Share Posted October 26, 2011 Two years ago I noticed that CCleaner suddenly had a new group of windows log files to clean so I peeked inside to see what was going wrong. It scared me - Windows .NET Framework and Catroot Repository were corrupt. Looking through event logs I found my woes began with :- 01/08/2009 16:48:10 Reboot Pagefile.sys initialisation 01/08/2009 16:49:12 4 off WinMgmt failures to load MOF Event ID: 4 (while recovering repository file) :- C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\V1.1.4322\ASPNET.MOF C:\AC30D119A40F2C8C8708A20576\I386\LICWMI.MOF C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\V3.0\WINDOWS COMMUNICATION FOUNDATION\SERVICEMODEL.MOF C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\V2.0.50727\ASPNET.MOF Windows log *.MOF files would have saved me from wasting weeks of my life trying to restore my XP Home Laptop from corruption. I still clean Windows log files but learnt from that experience and added this exclusion to CCleaner.ini Exclude1=PATH|C:\WINDOWS\system32\wbem\Logs\|*.* Link to comment Share on other sites More sharing options...
Moderators Nergal Posted October 26, 2011 Moderators Share Posted October 26, 2011 But the MOF files aren't cleaned FileKey1=%SystemDirectory%\wbem\Logs|*.log FileKey2=%SystemDirectory%\wbem\Logs|*.lo_ I just can't understand why you aren't loooking at the code I supplied ;-/ ADVICE FOR USING CCleaner'S REGISTRY INTEGRITY SECTION DON'T JUST CLEAN EVERYTHING THAT'S CHECKED OFF. Do your Registry Cleaning in small bits (at the very least Check-mark by Check-mark) ALWAYS BACKUP THE ENTRY, YOU NEVER KNOW WHAT YOU'LL BREAK IF YOU DON'T. Support at https://support.ccleaner.com/s/?language=en_US Pro users file a PRIORITY SUPPORT via email support@ccleaner.com Link to comment Share on other sites More sharing options...
Alan_B Posted October 27, 2011 Share Posted October 27, 2011 But the MOF files aren't cleaned FileKey1=%SystemDirectory%\wbem\Logs|*.log FileKey2=%SystemDirectory%\wbem\Logs|*.lo_ I just can't understand why you aren't loooking at the code I supplied ;-/ The System Event Logs are not purged by CCleaner and they showed reported "WinMgmt failures to load MOF Event ID: 4 (while recovering repository file)" The consequence of the "WinMgmt failures" was a never before seen occurrence of a never ending sequence of error logs somewhere. This was a new problem that I was never able to resolve, even though I posted for help on 5 or 6 forums including this one. I found several well qualified sources of information that advised me that the WinMgmt failure could be resolved by re-compiling certain items that were identified within certain log files created at that time in the above %SystemDirectory%\wbem\Logs|*.log Fearing an imminent disaster with an unanticipated WinMgmt catastrophe, I fixed the system by restoring the partition from an image backup created the day before the original WinMgmt failure. After that I had to repeat all the upgrades and installations that had occurred since that WinMgmt failure for the long periods when Firstly I had not seen any evidence of a repeatable problem, and Secondly, I was searching for a cure to WinMgnt failures. The source of the problem was the reason I made the backup the previous day I had to do a "Clean Install" to upgrade Comodo Firewall so I took precautions against disaster. The first attempt failed because removal of residues was incomplete, as I feared, so I followed up with a second attempt that included the use of RevoUninstall to help mop-up, followed by a "User Forum Script" that knew specific files and registry keys that might need special zapping. That was successful but the new firewall needed a reboot for completion of installation. Then I inspected the event log to see what issues might have occurred and was horrified by failure to recover repository. I rebooted and there was no further failure so I assumed a second recovery attempt had succeeded. Only much later did I recognise a new crop of error logs every day was evidence that all was not well. When I repeated the Comodo Upgrade I was careful this time round to avoid the User Script precautionary measure of deleting the Repository. The motivation for deleting the Repository is to ensure a rebuild such that Windows Security Centre recognises that Security has been uninstalled. Apparently if the Security Centre thinks Firewall/A.V. etc is installed it may prevent the installation of a replacement, leaving Windows in the undignified position of having its trousers round its ankles Link to comment Share on other sites More sharing options...
Moderators Andavari Posted October 27, 2011 Moderators Share Posted October 27, 2011 Apparently if the Security Centre thinks Firewall/A.V. etc is installed it may prevent the installation of a replacement, leaving Windows in the undignified position of having its trousers round its ankles I use what's in the code below on my XP SP3 system, but do note do not use it while you're connected to the Internet as it disables Windows Firewall, and do not use it if you have any third party firewall or antivirus installed as it may or will cause Security Center to constantly think none are installed such is the case with Panda Cloud Antivirus and perhaps others. Also it resets some of the Windows Firewall settings back to the default settings, so if you have for example logging of dropped packets enabled you'll need to re-enable it, etc. NET STOP WINMGMT /Y RMDIR /S /Q "%windir%\system32\wbem\Repository" SHUTDOWN -r -t 3 -c "Required restart" Link to comment Share on other sites More sharing options...
Alan_B Posted October 27, 2011 Share Posted October 27, 2011 I use what's in the code below on my XP SP3 system, but do note do not use it while you're connected to the Internet as it disables Windows Firewall, and do not use it if you have any third party firewall or antivirus installed as it may or will cause Security Center to constantly think none are installed such is the case with Panda Cloud Antivirus and perhaps others. Also it resets some of the Windows Firewall settings back to the default settings, so if you have for example logging of dropped packets enabled you'll need to re-enable it, etc. NET STOP WINMGMT /Y RMDIR /S /Q "%windir%\system32\wbem\Repository" SHUTDOWN -r -t 3 -c "Required restart" At that time I used XP The "User Forum Code" differed only by the use of RD instead of RMDIR, but I think there may have been some additional code such as regsvr32 /s %systemroot%\system32\scecli.dll regsvr32 /s %systemroot%\system32\userenv.dll mofcomp cimwin32.mof mofcomp cimwin32.mfl mofcomp rsop.mof mofcomp rsop.mfl for /f %%s in ('dir /b /s *.dll') do regsvr32 /s %%s for /f %%s in ('dir /b *.mof') do mofcomp %%s for /f %%s in ('dir /b *.mfl') do mofcomp %%s echo DONE reboot pause whooo hooo - code box supports blank lines again I have just searched rebuild repository and copied the above from a result at http://msmvps.com/bl...ages/20217.aspx Another Google result with extreme relevance is http://windowsxp.mvp...g/repairwmi.htm Subsequent to the problem, whilst searching for s solution, I found several experts that advised :- 1. Repository should be rebuilt after the Reboot; 2. Rebuild may fail if the computer has certain defects (defects were specified but I cannot remember them now.) 3. It is safer to retain a backup of the repository so restoration is possible when things go pear shaped. At that time my interpretation was that instead of removing the Repository it should be renamed. I now wonder if that might fail if the Distributed Link Tracking service is running. So far as I am concerned it was a bad decision for the User Forum Script to NEEDLESSLY trash the Repository. That default action will only help the small percentage of users with a defective Security System that fails to see that Comodo is removed, and is disastrous for others who have a system that is fully functional apart from lacking the ability to rebuild what need not have been deleted. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now