Please default to NOT clean Windows Log Files

[TechHarmony]

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.

[Winapp2.ini]

I have yet to see the developers change a default, but they do read the threads, so perhaps you'll see this happen

[Nergal]

+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 KB

C:\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)

[Andavari]

Perhaps create a default ccleaner.ini, with all your pre-saved preferred settings in it with those boxes unticked you never want cleaned.

[Nergal]

I like that idea

[Winapp2.ini]

I also support it

[Alan_B]

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\|*.*

[Nergal]

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 ;-/

[Alan_B]

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

[Andavari]

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"

[Alan_B]

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.