ongoing av update issues

As posted before, the av update on my cis is successful on an infrequent basis. I works about once a month. I recently restored my os from an image, so my definitions are rather old. Not only does the auto update not work, it basically keeps trying to update all day long. If fails, and then starts again which uses up resources. Even when I turn off automatic updates, is still keeps trying to update.

I decided to manually update the database so I used this link,

from this page,

to download the latest database, booted into safemode and replaced the old file. When I booted back into windows, I still see the same old data for the AV definitions and it keeps trying to update.

Why would it have the same date when I manually added in the newest definition database? There really should be a more straightforward method for manuall updates since they are necessary under a variety of circumstance.

I am using CIS 5.12 and the database signature is 20663. The OS is windows xp 32-bit.


Do the solutions in Comodo AV Version 5.12.256249.2599 Won’t Update help you any further?

I have uninstalled, cleaned, and reinstalled this thing until I am tired of it. The only advice I have received here other than endlessly repeating this cycle is to move to a more recent version. There is no good reason for an AV update to not work. It’s hard to imagine a more straightforward process from the programming point of view. There is even less reason for it to work occasionally and not work most of the time.

Since no one has ever given any answer whatsoever to questions about why this failure happens (in on of my threads or in countless others I have read on the topic) I generally believe that the AV update malfunction is intentional on the part of Comodo as a means to push users into using the latest version of CIS. I don’t believe that these questions are ever going to be answered or the issue resolved.

My question is about why manually downloading and installing the latest database in safe mode does not change the update date and why CIS still thinks it’s definitions are out of date. I download an install the latest database, but when I hit the manual update button right after that, CIS still download a database and tries to install it. When it fails, it just keeps trying to download and install over and over again. How does CIS not know that it already has the most recent database?

Did I not download the database from the correct location? That is the only thing that makes sense at this point, although I am convinced that Comodo doesn’t really want this to work.


If I recall correctly one of the ways of to deal with failing av update is to empty the temp folder in the Quarantine folder. You do need to do a take ownership procedure to be able to access the temp folder.

saw that cis av database is 23 hrs old (cis didn’t whine about it) and tried to do manual update but got 4 errors and this Error: 0x80010105 - The server threw an exception. was in logs.

defense+ logs say that werfault.exe is trying to access cmdupd.exe and cis terminates it.

emptying temp files-folder (only 2 folders there) didn’t change anything except gave entry number 21 on d+ logs about werfault got terminated.

Win7 64bit is os.

my problem got fixed after computer reboot, av db got updated and blocked intrusions got emptied.

somehat weird that it happened with admin-account too (normal user was still logged in although).

I cleared the Quarantine temp folder of all contents. This changes nothing. The AV database data is still old, in spite of the database being manually updated a few days ago. Updates still fail when auto update runs or when I select to update now.


The answer is quite simple: Comodo have NOT been updating the full virus signature database in anything remotely close to a timely manner !

Rather than the “approximately every 2 days” that Comodo claim, it has ALWAYS been several days at the very least between updates and more recently several weeks. The most recent update was almost a month overdue when it finally appeared. Given the timing of your problems, that’s why you didn’t see any changes despite downloading and installing the allegedly up-to-date full database.

This ‘lack of full database update’ issue explains why some users have been seeing the full database being downloaded on some occasions when just checking for incremental updates. It also explains why some users have been seeing near continuous or regularly repeated downloads of updates without a successful installation. If there are ‘too many’ incremental updates then this forces the latest full database to be downloaded. If the full database hasn’t been updated often enough and/or any updates fail to install then you’re stuck in a download loop obtaining the same unusable data over and over and over again.

Recent full database updates have been as below:

02/09/2014  06:54       205,548,150      BASE_END_USER_v19393.cav.z
06/09/2014  13:52       207,194,556      BASE_END_USER_v19435.cav.z
10/09/2014  13:21       207,032,063      BASE_END_USER_v19471.cav.z
14/09/2014  12:50       207,425,105      BASE_END_USER_v19509.cav.z
18/09/2014  13:59       208,733,806      BASE_END_USER_v19547.cav.z
22/09/2014  14:11       208,615,920      BASE_END_USER_v19585.cav.z
26/09/2014  15:16       209,969,433      BASE_END_USER_v19623.cav.z
30/09/2014  15:20       210,219,840      BASE_END_USER_v19659.cav.z
04/10/2014  13:04       210,479,430      BASE_END_USER_v19699.cav.z
08/10/2014  11:19       210,674,721      BASE_END_USER_v19739.cav.z
12/10/2014  12:24       210,651,934      BASE_END_USER_v19777.cav.z
16/10/2014  13:34       210,729,692      BASE_END_USER_v19815.cav.z
20/10/2014  13:38       210,941,085      BASE_END_USER_v19854.cav.z
24/10/2014  13:31       211,521,775      BASE_END_USER_v19887.cav.z
28/10/2014  15:01       212,921,671      BASE_END_USER_v19923.cav.z
01/11/2014  11:47       213,112,360      BASE_END_USER_v19960.cav.z
07/11/2014  21:13       214,967,162      BASE_END_USER_v19997.cav.z
13/11/2014  15:03       219,952,173      BASE_END_USER_v20070.cav.z
26/11/2014  05:56       221,560,725      BASE_END_USER_v20197.cav.z
08/12/2014  10:06       224,434,815      BASE_END_USER_v20303.cav.z
22/12/2014  04:41       226,568,301      BASE_END_USER_v20438.cav.z
10/01/2015  10:54       229,528,661      BASE_END_USER_v20663.cav.z 
09/02/2015  06:35       230,172,256      BASE_END_USER_v21015.cav.z

Who knows quite why Comdodo are doing this … but it’s obviously intentional, definitely yet another good way for Comodo to prevent users of older products obtaining updates and no doubt an attempt to force them to upgrade to a significantly more bloated and totally unsuitable product.

You should be able to download and install an updated full database now and all of the subsequent incremental updates might possibly download and install so everything works correctly again. At least for a short while. Give it a try, you might get lucky … but I certainly wouldn’t put any money on it actually working. More often than not it’s simply a case of different database, same problems 88)