Comodo AV Version 5.12.256249.2599 Won't Update

Comodo Internet Security - CIS AntiVirus Help - CIS
61

EricJH, after a system shut down and startup, cmdagent.exe is again an up and running process. The system (so far) is running as well as one can expect… considering… (the ol work horse).

I have monitored all processes and activities closely since, and have noticed cmdagent.exe not to be a total consistent resource hog as before (99% cpu usage). I have noticed, however, on a few occasions today, cmdagent.exe would use between 40 - 65 % CPU, during these times the system would sound as if it were downloading and installing updates. Once the guts of the system quieted down to an idle sound, the cmdagent.exe CPU usage would fall back to 00 range.

I also noticed, when the cmdagent.exe was using the 40 - 65% CPU and the system was sounding as if downloading and installing updates, that the IP 91.199.212.149 port 80 was present in the active connections firewall interface {TCP /out _ source ip /me _ destination ip / 91.199.212.149:80}… and, at this same time, looking over at the task manager, I noticed cfp.exe to be disappearing and reappearing quickly, each time it would reappear, it would reposition itself to another tier of the process tree (example, appear halfway down the process tree, disappear, then reappear at the bottom of the process tree… etc…)

As for tonight, I have manually checked to update the virus database via the antivirus interface, and it appeared to have checked successfully (I say that meaning it hung for a brief moment before completing the check, as opposed to the behavior it presented the other day, performing this check too quickly and stating it was up to date, enough to alert me that something didn’t seem right). During the virus database update check, the IP 91.199.212.171:80 (different from the above) is present in the active connections of the firewall interface.

I would be happy to assist in any way I can for the betterment of the community.

I removed empty space at the end of the post. Eric

62

Thank you for your willingness to cooperate but reading what you reported going back to a system state before the most recent Windows update will not be necessary.

63

I followed your suggestion and it worked perfectly. Thank you very much.

64

Hi Guys,

I also encountered the “Failure to Update Virus d/b” problem (for the first time) about 16th Feb. It was failing at the “Finalize” stage and no amount of Windows reboots and/or CIS restarts would fix it. I was just getting to the stage of tearing my hair out, so decided to abandon it overnight. The following moring CIS started up normally, updated the failing d/b with no error messages and since then has behaved as if nothing ever happened !!! I have left reporting it till now to make sure it wasn’t going to recur.

This episode lasted less than 24 hrs and seems to support the “corrupt incremental update” theory, which apparently got fixed (by Comodo ?). I would be interested to know if this problem is still happening (and the recent entries on this thread relate to historical problems) or whether Comodo has applied some coding fix to stop it happening permanently.

(I am on XP Home Edition SP3)

65

[at]Luizf: Good to hear that finally fixed your problem :slight_smile:

[at]ianf: Interesting that it’s still happening sometimes … but fixes itself !

[at]EddyHaskel: Are you still seeing your strange things happening ?

I think it’s pretty clear that Comodo have been having (and may well still be having) problems with the server and/or the quality of the incremental updates being released. Despite no hard evidence I’m entirely convinced that a ‘bad’ incremental update made it into my database and ■■■■■■■ it up completely thus preventing any further updates being installed. There also appears to be a significant number of other users who had exactly the same problem at or around the same time. However, there also appears to be several other very similar problems with incremental updates that may or may not be directly related and these are affecting other versions of CIS on different OSs as well.

It’s all very strange but I’d certainly put my money on it being a fundamental problem with the updates that Comodo knows all about and has been tinkering around behind the scenes trying to fix or prevent it from screwing things up anyway. Whether they have found and permanently fixed the problem this time or just hidden it again for a while remains to be seen but there certainly doesn’t appear to have been quite so many posts reporting issues recently. There quite obviously hasn’t been any changes or updates to CIS itself of course, only potentially to the update system, the individual updates themselves or the way that they’re being served.

I’ve had some background monitoring running on my main system continually since the beginning of Feb and I haven’t seen any indication of there being any update issues at all. I had a false alarm on 23rd Feb because I’d shutdown the system the previous day whilst an update was in progress which had left working files lying around but that’s all. The first automatic update of the day cleared things up without any issues.

The other very similar but less well used system that I put a clean install of CIS on for test purposes hasn’t seen any further problems to date either so I’m going to uninstall it now and try to remove all traces. Unfortunately, I can’t remember exactly how I managed to work around all the various bugs and annoyances in CIS on my main system and this new installation has been driving me absolutely nuts by intermittently screwing some things up and generally doing things that it’s been configured NOT to do ! Every version of CIS (or whatever) I’ve ever used going back to at least V3.8 has had similar although often subtly different issues but it’s so long since I gave up updating CIS and found a way to resolve the problems I was finding at the time that I can’t remember what I actually did. I really like what CIS offers but TBH it’s a real good job that it’s a free product because I’d be mighty unimpressed with the considerable length of time that some bugs and annoyances have been hanging around otherwise that’s for sure 88)

66

Hello again, everyone with virus definitions update issues!

I’m just checking in to see if anything new has happened or been uncovered. Seems to be status quo. Same here: Every few days my virus definitions will hang on “finalizing.” I kill the cmdagent.exe process, then immediately restart it, then try again to update my virus definitions and, like magic, it works every time.

I intend to keep Win XP sp3 running on this machine for a long time as it is not capable of handling the latest bloated mess of an OS from Microsoft, so it’s important for me that the CIS 5.12xxxx virus definitions continue to update.

Cheers,
Eddy

67

Hi Guys,

Please see this post to see if this helps:

https://forums.comodo.com/install-setup-configuration-help-cis/cis-6-unable-to-update-from-malaysia-merged-topic-t101617.30.html

You can from there try to disable other servers to see what’s working and what’s not.

Hope this helps.

Josh

68

All my CIS5 has stoped at 17948 and fails after that. uninstalling and installing CIS7 helps and updates. But lot of time on 123 Pc’s

69

Just update CIS 5.12 to latest virus database 17963 no problems.

Dennis

70

Just a heads up for those still having issues with the (thread subject) updater.

This afternoon, I again noticed issues with CIS virus database updater after not noticing any problems since my last post about it previously in this thread. I attempted to replicate the same patterns I did last time in hopes to fix it, which was, (find cmdagent.exe in CIS active process list tree and terminate it / restart system / then manually update the virus database and patiently wait for it to finish) which it did successfully. No such luck this time.

Today, I noticed cmdagent.exe again using excessive CPU (from 40 - 99% consistently). Bells rung in my head, and I pulled up the CIS interface and tried what I did last time, but this time, it would download the files, apply them, then proceeded to 90% complete / finalizing, but could not complete the process and gave me an error message accordingly. I tired and retried this several times throughout the afternoon to no avail.

I then went to comodo’s website and found the latest virus database .cav download, and during this time I then noticed that my current database was quite a few updates from where it should be, showing me that even though I had noticed no issues, the database was not being updated for some time.

My fix today, I downloaded the latest virus definitions from the Comodo site, restarted my system in safe mode, copied the bases.cav file to my //program files / Comodo / Comodo Internet Security / Scanners File, restarted, and noticed cmdagent.exe was now within it’s normal CPU usage range. I then opened the CIS interface and checked which virus database was listed in the (about CIS screen) and it indeed showed the latest virus database.

I then manually checked for virus database updates again, and to my surprise, it began downloading, applying, and finalizing updates. However, this time it successfully surpassed the finalization process after a short time (a couple minutes maybe) of hanging at 90% complete. And we now have a up to date virus database and an acceptable cmdagent.exe CPU range.

Note to Josh TM and others: I did check this thread after a few unsuccessful tries of my own this morning, and I did see and attempt your mentioned fix which was adding the us4.download update host in the preferences section, and it did not help my situation. The update process using the added download host also froze at 90% finalization, would not complete, and give me the error message.

71

I just knew it was likely to be tempting fate by commenting on the apparent lack of update problem reports ! Rather more than you can shake a Varanus komodoensis’ tail at since then it would seem :stuck_out_tongue:

Sorry for those with problems but I have to say that all is still looking good here. I’ve been running background monitoring to check for possible problems every 15 minutes since the beginning of February and everything appears to have been working just fine for me. I’ve seen a couple of false alarms now after I just happened to shutdown the system when an update was in progress but that’s all. Both times it sorted itself out on the first automatic update of the day a few minutes after the system was next powered up.

I think by far the best thing to try if you’ve got a problem that isn’t resolved with a reboot or killing cmdagent is to just manually update the database. Whilst upgrading often seems to fix things initially at least it’s perhaps only because it downloads the latest database rather than anything too much more than that. If there was a fundamental and permanent problem with the old version of CIS and/or Windoze updates then I really ought to have seen some problems again myself by now … and here’s hoping saying that’s not tempting fate as well mind you ! Have to say that I think it’s a pretty poor show from Comodo that these update problems still appear to be cropping up though.

If you’ve got the problem then I suppose it might be worth running a tracert to “download.comodo.com” and “downloads.comodo.com” from the command prompt a few times just to see if that shows up any difficulties in reaching the server or indicates dns issues. After that go for the manual update just to remind it who’s the boss ;D

Has anyone seen an update problem recur at any time after fixing it by manually updating the database to the latest available version ?

72

Yes. After manually installing the database update while using {Administrator Account} which was successful (as I described a couple of posts above), the database would no longer be recognized after logging off and logging back in as a {Limited User Account}.

73

This update issue is really strange and definitely still happening here as well. My main system appears to have suffered multiple intermittent problems with updates on several occasions recently. Mostly for short periods of time or just false alarms with the most notable significant periods being all evening on 29th March and virtually all day on 7th April. My other less well used system had problems starting on 6th April that didn’t get resolved until 9th April. In both cases the problem eventually sorted itself out although there was up to 3 days of no updates so Windoze whined about it. I was just about to do a manual database update on the second system but auto update suddenly started working again while I was copying over a later database to replace the several day old version. It’s also weird that 2 near identical systems on the same network were behaving somewhat differently as well. The only real difference between them is the length of time they’re powered up and therefore the frequency of auto updates.

Still no official comment from Comodo ?

74

Have been suffering from this problem for some time now. I today went back to v5.10 from v5.12
because of this problem (had not previously had any problems with v5.10 some time ago).
Still same thing, even after manual copy of bases.cav dated about 2 weeks ago, it initially worked OK
for v5.12, but failed today to update, hence the switch to v5.10.
I’m getting close to abandoning Comodo AV, will I think keep Firewall but need a reliable AV,
cannot for the life of me understand why updater does not seem to know the cause of the failure,
constantly blaming the internet connection. Downloads the updates OK, fails at 90% ‘Finalizing’.
I even tried FixeBase.exe on bases.cav (although not sure what that is supposed to be for).
Download Finalize usually produces a bases.$$$ file of 34.6MB in scanner dir.

Gonna try manual download of full db again today, if further problems will probably be looking for an alternative
(V7 will not be it).

EDIT: WXP SP3 with updates to final support update.

75

I had the same stinkin’ prollem (as did several of my clients) and all over the course of several weeks since end of March. The solution ultimately proved to be clean reinstall of v5.12, import pre-existing v5.12 configuration, activate it. It starts updating AV def DB immediately after initial installation reboot; that can’t be stopped. However, after importing your pre-existing v5.12 config, you turn off the AV defs update in the AV config screen and reboot (that stops the initial AV def update in its tracks). Once CIS is re-initialized after rebooting, then update AV def DB manually; it should say updated NEVER because of the clean install - and it should download the whole stinkin’ file from the beginning, and then successfully activate it. Once the initial file is installed and activated, the incremental updates should work also.

If the initial - clean - install AF defs doesn’t install and activate, obviously there’s still a prollem. But I’ve not seen the initial post-install reboot manual AV def DB update fail on multiple machines. I believe that if v5.12 installations are stuck recently not updating, that blowing away BOTH copies, i.e., in /scanners & /repair, and then manually installing the full sized-file in safe mode should rectify the matter.

Me thinks an incremental file was horked, and that borked the AV def DB somehow. When the subsequent AV def DB update occurred, the backup copy in /repairs was already ■■■■■■■ up so no go from there.

If one is going to update to v7, then forget v5.12 and install v6.3 clean from standalone installer. Import the pre-existing v5.12 configuration and configure all the bells & whistles in v6.3. v6.3 will inform program updates are available: download updates and it’ll upgrade just fine to v7.0.xxxx I had a prollem with v7.0.xxxx clean in that I believe it just doesn’t like v5.12 config w/out migrating through v6.3 upgrade.

Works good last long time.

76

Gotta say I’m getting a pit p****d off with this issue now TBH. There have been more than a few intermittent periods of the database not updating automatically just recently and I’ve had to manually update both systems several times due to these continuing and long-standing unexplained issues with incremental updates. Everything was OK for weeks after the first time the problem showed up but now update issues seem to be becoming a quite regular thing unfortunately :frowning: I can’t help feeling that if something as simple as updating the database isn’t working properly and reliably then what else isn’t working properly ? I have no reason to believe that it is but in the continuing total absence of any official comment from Comodo it could even be that this version of Comodo has been compromised and updates are effectively being remotely disabled by a 3rd party. It’s no good anyone suggesting installing a later version of Comodo is the solution because that isn’t likely to be a realistic option for most people still running XP on older hardware.

However, contrary to the previous post, reinstalling V5.12 isn’t the solution per se. It’s not the program that’s apparently getting ■■■■■■■ up here or the registry just the database. The only reason reinstalling generally appears to work is simply because it removes the existing database and downloads the latest version. Doing the same thing manually has exactly the same effect and is generally speaking quicker and less prone to introducing other problems that reinstalling stuff can create.

Perhaps not exactly surprising but a manual download and install only appears to work PROVIDING that the latest available database includes the incremental update that seems to be causing the problem. Manually installing an earlier version of the database does not in my experience fix the problem. This can on some occasions mean waiting around a week for an appropriate download to appear on the Comodo site.

It is possible to check the database version using a hex editor but I would suggest always downloading the zipped version of the full database so you can easily see which version it is. When you unzip the download, the file name will be “BASE_END_USER_v######.cav” rather than “bases.cav” so you know which version you’ve got. You can check which database version you currently have installed by clicking “about” on the “more” tab in Comodo. You need to manually install a later version of database than the one currently being used. Once you have an appropriate download all you need to do is rename the unzipped file to “bases.cav” when you copy it to the “scanners” and “repair” directories.

It’s all a bit of PITA really but at least it does apparently fix the problem … albeit only until it turns up again at some point in the future 88)

77

What you describe is congruent with what I’m compelled to believe, i.e., there’s an issue with at least one (and perhaps more), incremental update segment(s). Inherent to CIS AV is some exquisitely finicky integrity checking that implements some form of hashing, e.g, CRC, MD5, SHA1 (very susceptible to memory corruption). If AV def updates failure is a good indication that Prime95, Memtest86, etc. will reveal memory sub-system errors, e.g. overclocks, system-board and/or RAM failure.

Since I’ve experienced this issue in two different O/S, and have numerous clients intimating the same thing: I’m dismissing hardware failure outright.

Bases.cav must be functional at some fundamental level, otherwise CIS goes completely wonky; D+ goes completely bonkers. Since that’s not happening, the integrity of the AV def DB must be sound. Post update the computed hash must be invalid. That means the hashing of the old file must be bad too; if an update fails, the original is restored from /repair/bases.cav. Since updates fail again, that means the /repair/bases.cav is not outright corrupt - otherwise CIS operational failure - but the hash is invalid.

Dunno 'bout the gizzards guts about all that and whatnot - Comodo prolly plays all that very close totheir vest for very good reason: keeping the NSA in the dark about their secret sauce - but that’s just my two cents on all that.

78

Bl**dy update problems … AGAIN, grrrrrrrrrrrrrrr :frowning:

The last satisfactory incremental update was #18230 and having wasted several hours tonight working out exactly where the incremental data is currently coming from then obtaining it all manually, I think I may have found something interesting. I have also 100% confirmed that all the data is being downloaded and there are no obvious transmission or other similar errors. There is no timing issue either as all of the required data is downloaded almost instantly.

However, it does appear to me that incremental updates #18232 to #18245 (the most recently incremental update available) are all subtly different to incremental updates #18220 to #18231 that do install correctly. The downloads can come from various different places and there is often a redirect from the expected servers to “cloudflare” for instance but no matter where I try to obtain the data from, all of the servers appear to be providing the same dubious looking data. I don’t think this is always the case mind you because I have a suspicion that different servers have sometimes been supplying different data (or no data at all) in the past. I think that’s the main reason why rebooting and/or killing cmdagent sometimes resolves the problem. The server addresses appear to be selected once only when cmdagent loads (or can only potentially change every several minutes/hours when the DNS TTL expires and/or if the authoritative DNS data is updated) and are not dynamically assigned each time the update process runs. If a duff server is selected when you boot then it seems as though you’re stuck with it until you reboot or kill cmdagent. The incremental data is also cached if/when it is downloaded. I still haven’t established exactly where but it is definitely cached somewhere (in addition to potentially in bases.$$$) because generally speaking no data is downloaded on subsequent update attempts following a failure. Again, another good reason why rebooting or killing cmdagent sometimes works because it clears the cached data in addition to potentially trying to download from a different server.

When the current problem was flagged up by Windoze whining after 2 days with no updates, the latest available full database download was #18219 which was obviously no good for a manual update as it was older than the existing database. Having waited several days for a later full database to be made available, it’s still no good because although it’s #18240, the apparent problem with dubious looking incremental update data is still present on updates up to and including #18245. Whilst a manual update to #18240 is obviously of some benefit, incremental updates are still broken of course. The problem cannot be resolved manually until whatever is wrong with the incremental data files is fixed AND an appropriate full database download incorporating the correct version of all of the dubious incremental updates is also available.

I can’t be entirely sure about any of this TBH as I obviously do not know the intimate details of the database or how the files should look anyway … BUT there most certainly appears to be a good correlation between dubious looking incremental update files and the problem of update failures ! Looking at the incremental updates around the time the previous update failure occurred, there is also a similar batch of dubious looking incremental updates - #18147 to #18153. I can’t check back any further into history as the relevant incremental updates are no longer available on the server. I did think that perhaps someone was uploading the older format files (i.e. for CIS V5.5 or V5.1 etc) to the server but this does not appear to be the case. The earlier CIS version database files appear to be significantly different.

So the big question here is: Why are Comodo apparently releasing batches of corrupt, badly formatted or otherwise dubious looking incremental updates on an intermittent basis ?

79

To take a different angle on what seems a persistent problem across versions for ambrougham. Could you run checkdisk with repair option on your hard drive by executing chkdsk /r from the command prompt?

Can you also check the Windows logs (Control Panel → Administrative Tools → Event Viewer → Windows Logs → System) and see if error regarding your hard drive are being reported?

80

I run chkdsk regularly as a matter of routine and I’ve never seen any problems since I first set the system up donkey’s years ago despite various unexpected power failures and so on occasionally happening. I’ve just run it again now though and all is well as expected. Similarly on checking the event log. There are loads of messages in there as would be expected but nothing of any significance and certainly no relevant disk errors. I would be regularly seeing no end of other issues if there was a disk problem as I’ve got a whole load of absolutely massive databases (each being several GBs) that are updated every few minutes almost 24/7. In any case, the likelihood of there being a random error in the existing database and also a similar random error in the manually installed database that replaced it is extremely remote to say the very least.

I’ve got 2 similar systems here but they’re fundamentally different systems … and BOTH of them are having the SAME problems with the SAME incremental update files ! I only installed comodo on the other system for test and monitoring purposes after I had the first update failure on my main system. They’re not always both on at the same time but since I’ve had the 2 systems with comodo on, both have been failing at similar times with similar update files being the root cause of the problem. Both have been fixed several times by manually updating the database when a suitable version was available for download. Other users have also previously reported a large number of machines all experiencing exactly the same problem at the exactly same time as well. In at least 1 case, all of their machines failed at much the same time as mine did ! This is almost without doubt a comodo problem and most likely to be some problem with some of the incremental updates. This isn’t just a problem for me. There are a number of users who have been experiencing similar issues with database updates failing that can usually only be resolved manually. Up until fairly recently I’d not been seeing any problems at all despite the numerous reports from other users over the years. Then it happened once and I found this thread while investigating. I fixed the problem eventually with a manual database update after a lot of detailed investigation just to make absolutely sure that there really wasn’t a more serious problem. Everything was then fine for quite a long time although other users were still reporting similar issues on a regular basis. Just recently however it’s been happening quite often although mostly just intermittent periods lasting several hours resulting in update failures but followed eventually by a successful attempt from a different server hence my suspicion that different data has been available from different servers on some occasions. There have been several occasions where manual intervention was the only solution though. Both of my machines with comodo on stopped updating following incremental update #18230 and both of them continue failing to update after full database #18240 was manually installed. Both will no doubt start updating again in due course as they have done several times before.

This problem has been happening intermittently to many users on just about every version of Comodo from V3 right up to the most recent version. It also perhaps explains reports of high CPU activity and so on with various versions as well because when the failure occurs it generally remains until it’s manually resolved or different data is obtained from a different server at a later date. This means that comodo keeps on attempting to update the database at very regular intervals and it uses loads of resources trying and failing to do so. Every attempt means obtaining all the incremental updates and going through the motions of generating the new database, it always fails right at the very end after taking several minutes doing all the hard work.

The error message given when requesting a manual update implies a problem obtaining data i.e. “Failed to update the database - please check your internet connection and try again” but there is quite clearly NOT a problem with the connection at all or indeed with obtaining all of the update data. All of the required data is available on all of the available servers and all of it gets downloaded without any apparent problems whatsoever. I’ve manually downloaded every single incremental update for the past month or so from more than 1 server without any issues whatsoever and I’ve monitored everything on a network analyser so I can see everything on a packet by packet basis including checking for CRC and other errors. The data comes in exactly as it should do based on the contents of the file “versioninfo.ini” which is the very first thing to be downloaded and it’s always the same data no matter which server it comes from. However, some of the incremental data files just look somewhat ‘different’ to the way that the bulk of them usually do.

The problem here is that this version of comodo (and possibly others as well) is either not accepting some of the incremental update files as being valid or the end result of using the incremental data to generate a new database results in some fundamental error. There is something very strange intermittently going on with the incremental updates because whilst most work just fine, some cause problems. BUT it’s not a connection or data transmission error, it’s generally speaking a more permanent error and it generally seems to be a problem with the incremental update files themselves. The files comodo seems not to like very much are also those which tend to look somewhat ‘different’ to the files that do not give rise to any problems ! This would seem to indicate that there is either a compatibility issue or some of the updates are quite simply fundamentally wrong. Whatever the reason, the end result is a stuffed database that usually requires manually updating with a much later version once the incremental update file problems have gone away.

EDIT: Typically, initial contact recently has been with download.comodo.com [178.255.82.5] and requests are usually redirected to cdn.download.comodo.com [198.41.209.107], [198.41.208.108], [198.41.209.108], [198.41.209.106] or [198.41.208.107] cloudflare servers. On some occasions downloads.comodo.com [178.255.82.1] has been automatically selected by comodo though and in this case there has been no redirect. I think there may have been different redirects in the past. However, it makes no difference at the moment which servers are being used as all appear to have the same data but there is some evidence to suggest that this may not always be the case. In addition to this, comodo also continues to ‘phone home’ to other servers on a regular basis of course DESPITE all cloud-based options being disabled and me declining to accept comodo sending reports when it was first installed. There is only 1 way to apparently prevent comodo from effectively doing what is generally considered as being “spyware” and that’s by configuring a firewall to block comodo’s ‘phone home’ attempts !!! I’ve known about if for years and it’s always been blocked but comodo really ought to be ashamed of themselves TBH if it’s intentional because if a user has selected no reporting and no cloud-based scanning then this means that there is absolutely no excuse for any unexpected remote accesses to unexpected servers.

However unlikely it probably is, I must admit that every time I think about any of this strange activity and the regular unexplained problems with database updates … the very first thing that immediately springs to mind every time is that comodo and/or my system(s) have been compromised so perhaps someone would care to explain the seemingly unusual activity of redirects and other unauthorised connection attempts to remote servers ? I really don’t think there’s a serious problem (just a bug) but comodo does seem to be ridiculously easy to bypass completely so I wouldn’t be all that surprised to find out malware with the ability to do just that has been around for years.