CIS doesn’t seem to play well with CryptSvc, creating 40+ errors in the dberr.txt file in C:\WINDOWS\system32\CatRoot2 daily.
The majority of them are at boot, (caused by the Scan Memory on Start function of the AV) but in some cases, regular errors occur every 30 minutes. (Automatic Update?) However, errors have also been reported by users without the AV installed.
If your catalog database is corrupt, Windows often thinks the cryptographic service isn’t running. This can cause fallout such as digital signatures not being recognized and Windows updates to fail. No big deal, right?
The dberr.txt file ordinarily lists things like all of the Windows hotfixes you’ve installed. Unfortunately, all of this data gets flushed regularly because CIS is continually spamming the file with errors and the file resets at 100KB.
It took me a while to figure out what you meant by ‘symptoms’ (besides being away at a conference for a few days). CIS seems to be operating properly and exhibits no other symptoms other than the errors that appear in the log.
While error number 0x00000057 is used in different circumstances and means different things, it is most often associated with an Invalid Parameter. I guess that means that either CIS has an incorrect parameter or, CIS is expecting a particular parameter in the catalog database file, catdb, but is mistaken in that assumption.
This is the fourth topic related to this problem I have seen scattered around the forum.
At the moment “Bug Report - CIS” has only 5 off “Child Boards”.
Is it possible to create Child board no. 6 to focus specifically upon these issues ?
QUESTION. Now that dberr.txt has had all the patch catalogue infomtaion flushed out, is it still possible to un-instal or superceed those patches ?
Recently there were very urgent security patches that were defective and had to be superceeded a few days later.
I ask that because it was not possible to un-install a broken .NET Framework 2 when the O.S. did not know the order in which it installed components
because it had lost some catalgue information ! ! !
Yes. This showcases one of Comodo’s biggest faults as far as I’m concerned.
The developers are supposed to read the fora, yet why are they so quiet about the issues raised? It does very little to instill confidence… Apparent lack of interest in support issues even though it’s a free application for most people can cause users to look elsewhere.
Even a simple, “We’re aware of the problem and we’re looking into it” goes a long way in my book.
You mean other than CIS spamming your dberr.txt file?
A log file is just that, a log - something to let the user know what happened. It is not used by the OS for any operations.
Like Heffe said, if they haven’t responded by now, it ain’t gonna happen. I had some hope with OmeletGuy being a “Usability Study Member”, but nothing came of that, either.
The devs do read the fora, especially the bugs boards. However, bugs get prioritised, some bugs are harder to reproduce, some bugs are harder fix… not all bugs are equal nor are they necessarily treated equal.
As a consequence it is hard to tell when a but gets fixed. We can basically just wait and suffer in silence… I won’t win a popularity price with this… 88)
Absolutely, and we wouldn’t expect it to be otherwise. As I said in previous posts, it’s not a high priority issue for me and I don’t think it’s a major problem for CIS. However, with the considerable time & effort we have put forth on this end, we were hoping for just a simple acknowledgement along the lines of what’s already been suggested or something like: will be looked at in the future or, will get back to you at some time in the future.
With silence, we don’t know that Comodo may have already looked at this in the past and determined that the log entry errors can be ignored, as MS said about the errors in the wbem logs. Although, they didn’t say why the errors were occurring. It took someone with no little technical expertise in the WMI area to figure that out.
My dberr.txt file has nothing but the errors in it–File #2 at line #1236 encountered error 0x00000057–I haven’t had any problems but then I also have never tried to remove a Windows update. I have never had a Windows update cause any problems in my over 10 years of using the various flavors but I’m wondering if I did, would this error spamming cause a problem of any kind?
May be I spent too much time in the past at the Opera forums. So as a consequence I am used to no feedback from devs and the fact there is not a public bug tracker… just wait and suffer in silence… 88)
I, too, have spent a lot of time at the Opera forums, but they make no bones about the set-up. The forums are for peer-to-peer support and, if you want a response, you have to submit a ticket. I did once, a long time ago, and did get a reply.
At least we have your reassurance that the posts are being read. I just wish I knew whether they consider this an issue or non-issue.
Separately, I read thru the bad AV signature update thread last night, and now I’m not so sure it isn’t likely that the problem has a connection to an AV update around the end of August (see: first link in first post above). Fortunately I dodged the bad AV signature bullet, but I did get burned badly by the guard.dll 16-bit programs problem in the 530 update. Comodo was lucky that, from the posts, no one seemed to get hit by both. It really is strange that just an AV signature update could wreak such havoc.
I wonder if trying a pre-August bases.cav would show something, hmmm…
There is (or was) a public bug reporting system. I used it for a problem I was having with another Comodo product and received emails concerning the problem (including a test code file that I used to verify my problem was fixed).
With Opera bugs when the devs need additional information you will be contacted. That happened to me twice I think. With Opera these days you will get an automated email notification that your bug was submitted.
