Thank you for your action, now you are my Hero also ! !
Alan
I’m not going to claim SOLVED yet for fear of having the bug ticket closed, but I seem to have gotten Comodo to stop messing with Opera and throwing dberr.txt errors. I still have some more testing to do, such as relaunching Opera and rebooting. Other people, with some experimenting, may be able to find the application that is causing Comodo to generate their errors.
I tried including various likely Opera files in D+ Computer Security Policy to no avail. Then, to try and narrow down the problem I tried setting some of their Access Rights to Ask. Nothing ever “asked” for anything. However, the last one I tried was the Opera main program itself which didn’t ask for anything either, but did produce a ‘Defense+ is Learning’ pop-up. Why Comodo would have forgot something I have been using all along, I don’t know, except for what we were able to narrow down to some Comodo change toward the very end of August.
The Access Right box I changed to Ask that worked was DNS Client Service. When I went back to see what would happen if I changed it back, it had already reverted to Allow.
I would like to know how this works out for others, if they care to try, and I will report back with how this is working out for me.
I’m all for experimenting, but since I am unaware of any applications having issues, I don’t even know where to start.
I would start with anything that might be querying the internet, since it seems to be DNS permissions related.
Hmmm… Well, with the exceptions of my system files, I’ve gone through my computer security policy list and put “Ask” as the default behavior for every action on every application I have installed.
So far only a single application has asked me if it was OK to do anything. This has made no change to the dberr.txt getting spammed by CIS.
I really don’t know why this would make a difference anyway. If the default action was “allow” previously, I don’t know how changing it to “ask” and having to manually allow a process is any different than the prior behavior.
I have never used Opera, and do not believe it was ever present before I received this P.C.
I have stopped messing around with Catrot\wbem etc., and eventually start-up delays have settled to a fairly consistent 70 seconds - it was random between 75 and 90 seconds when I think Windows was messing around with boot file positions and prefetch etc.
The security event log shows I logged on yesterday at 15:09:50
My special purpose log shows that following boot-up, pagefile.sys was initialised at 15:09:19,
Start-up was complete at 15:10:29 - i.e. everything that was launched had finished loading / initialising etc.
dberr.txt then captured this :-
CatalogDB: 15:10:29 25/09/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 15:10:44 25/09/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 15:15:14 25/09/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 15:45:24 25/09/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 16:15:35 25/09/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 16:45:46 25/09/2009: File #2 at line #1236 encountered error 0x00000057
The above is typical.
As soon as possible dberr.txt gets an error, and at the same time as edb.log and tmp.edb are modified.
Then something causes another error after 10 to 30 seconds later, and another error a further 4 to 5 minutes later, and there-after at precisely 1810 second intervals there are more errors.
The errors at 15:10:29 to 15:15:14 are before I use the P.C. when the only application running is xplorer2 which I launch at start-up, and the only Internet activities are what the XP system and Comodo are doing in the background. I also excluded xplorer2 from start-up and the errors happened just the same.
The errors definitely happen without using a browser- excepting of course the diabolical malware vulnerability which is I.E. that is inflicted upon all Windows users.
Due to posts above,
I have unchecked the DNS/RPC Client Service in Defence+ Monitor Settings,
and then changed the Defence+ security level from Safe to Disabled,
and rebooted - and the errors were just the same.
I have also changed from Automatic to Manual the services
AUTOMATIC UPDATES, DHCP CLIENT, DNS CLIENT, WEBCLIENT
and rebooted and the errors continue the same, and those services remained UN-started.
I have suffered far more frequent errors in the past when I was more “busy” with computer activities,
and I fear things will get worse again unless the cause can be identified and fixed.
Regards
Alan
I tried the fix on my previous version of Opera (9.64) and it worked there, too. I thought that maybe with the Opera problem, the 30 min. errors, and the DNS Client Service all being related to the internet, the dberr.txt errors might be connected in that way. However, I am still getting the dberr.txt errors after a boot.
I had previously tried looking at various sysinternals tools, and I finally broke down and thought I’d try looking at the laborious Process Monitor. The coincidence of two of us having the Hitchhiker’s Guide number 42 in errors I hoped would lead me to something. PM did have the correct number of writes to dberr.txt, but to my limited-experience eye with PM I didn’t see anything right before the writes that seemed as though it should have caused Comodo to place an error in the log.
I am out of ideas for the time being. It would be nice to get even a quick simple response from Comodo. I’d be happy with any one of following:
- Not a bug
- Cannot replicate
- Looking into it
Btw, the dberr.txt log reset itself at 100k.
Agreed! Unfortunately, I think if they haven’t responded yet, it isn’t going to happen… 
Good to know that at least it isn’t going to just keep growing!
I do not know how to use the information that is placed in dberr.txt,
and greatly fear that Windows may insist upon accessing that information when I undo a hotfix etc.
I also assume it can be used by those with skill and training to investigate difficult problems,
BUT NOT NO MORE ! ! !
At 24/08/2009 Catroot2 was last updated and dberr.txt retained last modified at 26/07/2009.
dberr.txt was 18 kb in size and held nothing but mystical “proper” update messages
starting “CatalogDB: 14:32:06 19/08/2008: Adding Catalog File: KB951978.cat”
then a few hundred more messages, then
ending “CatalogDB: 21:57:29 26/07/2009: DONE Adding Catalog File: KB973346.cat”
Around Summer of 2008 whilst I enjoyed a mid-afternoon siesta my son risked my wrath by installing SP3.
When I awoke and discovered it I was happy that working in I.T. he knew what he was doing,
and even happier that before his visit I created an Acronis backup image so I could undo anything that was too brave for me ! !
Fortunately nothing bad happened so SP3 became permanent.
I believe there is no going back before SP3.
All the patch updates that had hotfixes that could be individually and independently cancelled become permanent features of the O.S. landscape, and can no longer be un-fixed.
I suspect that may be the reason for dberr.txt being purged of useless information,
and the earliest data then present came from the Patch Tuesday security patch for KB951978,
which I accepted at 14:32:06 19/08/2008 ( I wait to see “early adopters” experiences first).
dberr.txt retained ALL the information since SP3 until this last month.
Ever since upgrading from Comodo 3.5 to 3.10 on 01/08/2009, dberr.txt has been getting
CatalogDB: ??:??:?? ??/??/2009: File #2 at line #1236 encountered error 0x00000057
and eventually it got too large and started again.
A few weeks ago I allowed a security patch, and Catroot system appended the usual
“Adding Catalog File: …” " DONE Adding Catalog File: …" stuff to a sea of “… error 0x00000057”,
and for a few days the “DONE Adding” stuff was available had I tried to un-install that patch.
After that dberr.txt got reset and that information is now lost.
Absolutely none of the security patches can now be undone should Windows insist upon first accessing the relevant information in dberr.txt. Windows has this terrible habit of insisting upon knowing the order in which things were installed so it can un-install in the correct sequence, and if records are lost/damaged it refuses to un-install.
I have Acronis backup images that allows me to force the entire operating system back to my choice of “when things were good”.
I face the future with peace and calm - I am not worried.
How about you ! ! !
SUMMARY OF ABOVE :-
CatalogDB information is being lost ; I do not know the consequences; they could be bad.
We need this problem fixing.
Reagrds
Alan
I think I have a pretty good idea now where the errors are coming from. Unfortunately, there’s not much that can be done to stop them. Fortunately, they’re not significant.
The three clues I found are:
- An older app I have always creates 2 errors when launched.
- For some reason Brother is not on the Trusted Vendors list, and when I turn off the Windows
Service for my Brother laser printer I have fewer errors after boot. - Whenever I try to add an executable to the Trusted Vendors list that is unsigned, Comodo
throws an error.
Not even all Microsoft drivers are signed, and the older they get the fewer there are that are signed.
I wish I could find a way to set up a POLL.
Please reply to say whether you ran a previous version of Comodo before these errors struck.
If you used one of the uninstal/cleanup batch files that can be downloaded as *.zip files from these forums you may be suffering from a similar cause to myself.
I used Comodo Firewall 3.5 plus NOD32 until the end of July,
when I un-installed both and immediately saw 4 off Winmgnt errors concerning .NET Framework *.MOF files.
After multiple reboots without further errors I decided it was one of those peculiar moments in Windows, and whatever it was that went wrong it had now recovered.
I proceeded to install C.I.S. 3.10.
Some days later I noticed a normally quiet dberr.txt file was frequently increasing in size, and I also realised that the wbem\repository had grown 50 extra *.MOF files at the same time as the 4 of Winmgnt errors I first saw.
I was told all my problems were due to a damaged repository and I had to delete it and allow it to rebuild itself. I tried and the dberr.txt errors continued. Later this topic was started and I realised I was no alone,
and I assumed I did not have one big problem, but two separate problems that started together by coincidence - damage to .NET framework *.MOF files and a recent Comodo thing that will hopefully get fixed.
I am now preparing to restore an archive image of C:\ with the old NOD32 and Comodo 3.5,
and then remove the old protection, trying very carefully to avoid further Winmgnt errors, and to then install C.I.S. 3.12.
Back in July the user forum cleanup tool said “All remains of CFP 3 should now be gone!”,
but I immediately recognised that as a lie because I saw several “inaccessible” errors flash up the command window. I removed multiple redundant “echo off” commands to see exactly what was inaccessible and eventually identified a registry key which I purged with regedit. I ran the cleanup tool again and this time believed it had completed the job.
I am now correcting multiple defects in that script so manual intervention should not be needed again,
and have found it worse than I realised and MAY be the cause of all our errors and problems.
THE STING IN THE TAIL.
The big killer I have just noticed is in the last 4 lines of code, i.e.
NET STOP WINMGMT /Y
cd "%windir%\system32\wbem"
RD /S /Q “Repository”
NET START WINMGMT /Y
That is stopping the WINMGMT service and deleting the Repository and restarting WINMGMT so the repository will be rebuilt.
It is WINMGMT that gave me the 4 off .NET Framework *.MOF errors. Not necessarily a coincidence ! !
In my particular case I probably ran the script a dozen times in fairly quick succession as I homed in on what registry keys needed manual attention.
I now believe that rebuilding takes some time, and many of these repository rebuilds were therefore aborted before they started, and possibly even in the middle of a rebuild.
This is the stuff of nightmares - even the simplest of Patch Tuesday security updates can kill Windows.
I have reasonable hopes that avoiding aborted repository rebuilds should avoid a repetition of .NET Framwork *.MOF errors. I have a glimmer of hope that the dberr.txt errors will also be fixed.
Regards
Alan
Only the topic starter can do this.
For what it’s worth, I’ve run every version since 3.5 and I did run the .bat file at some point. Not even sure why now.