Comodo AV Version 5.12.256249.2599 Won't Update

Comodo Internet Security - CIS AntiVirus Help - CIS
41

@ambrougham,

I agree that the virus definitions updates should work as they did before and that they stopped working rather suddenly. For me this happened this past November, for you it seems to have happened only very recently. I disagree that this is an isolated problem affecting only a few users… the forum is rife with people reporting the very same or similar issues across various versions of the software and for many of them it started a long time ago.

Re: being “up to date:” My system (XP sp3, Comodo AV Version 5.12.256249.2599) seems to be the same as yours. Also, like yours, when I click Comodo’s “check for (new software) updates” button it replies that my system is current and up to date. Apparently that is kind of true, for Windows XP systems using version 5.12+. Quite some time ago, Comodo released a whole new version (v. 6) that was created mainly for users of newer Windows operating systems (Vista, then Windows 7, then Windows 8 and now 8.1). I remember reading (somewhere in these forums… can’t remember where, and can’t find it now) that the changes made in version 6 and beyond were not particularly relevant for XP systems so it was optional to switch to the new version. Also, in this very thread, one of the experienced volunteers mentioned that since Comodo released version 6 there have been no new program updates for versions 5+ since Comodo AV Version 5.12.256249.2599. So – I am guessing here – the reports we get when we hit the “update” button are relevant only for version 5; i.e., it’s as up to date as version 5 will ever get and there apparently is no “automatic” update to version 6 and beyond using that method, at least not for XP systems. Meanwhile, as I recall, it also was stated that subsequent virus definitions updates would continue to be supported and work for version 5 even as the older software was no longer otherwise being supported.

I suppose all of us XP/v.5+ users could uninstall and wipe out all the traces of version 5 then reinstall the very latest Comodo CIS, but it is my understanding that this doesn’t add any utility or safety for XP that we don’t already have. Perhaps one of the forum heavyweights could elucidate further on this point?

In re: whether my (or your) system has been compromised by some outside forces, that does not appear to be the case, at least for mine. I have tested and retested my system numerous times using most of the more reputable tools – from Spybot to Kaspersky to Malawarebytes and several others – and it always comes up clean. I also log and monitor any outside internet traffic to my network (and each machine on it) and have not found any evidence of unauthorized incursions from incoming or outgoing IP traffic. Short of worrying about the NSA monitoring my every keystroke, the only glitch on my system seems to be this occasional inability to update virus definitions until cmdagent.exe is stopped and restarted.

On this last point, if rebooting does not work for you then my little “shortcut” workaround surely should not work either, which is too bad as I thought I was onto something that could help many/most users who are experiencing the definitions update failures. Obviously, cmdagent.exe is stopped and restarted when you reboot, so if that doesn’t work for you then merely doing it manually “on the fly” will not likely have any effect either, although I look forward to hearing about your results with it to confirm that point. If/when that fails, it would appear that your problem with definitions updates, while similar in to mine in that it hangs on the “finalizing” portion of the update, has a different cause than mine and I’m interested in hearing more as you learn more about it. Thanks.

Cheers,
Eddy

42

FWIW, my memory of the move from V5 to V6 is slightly different to yours. I thought I’d read that V5.10 was the last significant update and V5.12 was just a compatibility update for (I think) Win7 users. V5.10 users would therefore not be automatically updated to V5.12 because there was no real benefit and the fully Win7 compatible V6 would be coming along very soon. Any user could obviously download and install V5.12 manually if they wished to or needed to and all V5 users would ultimately be updated to V6 automatically when it was available. Obviously didn’t happen quite like that in reality and I can’t remember how I ended up with V5.12 on my WinXP/SP3 system. All I know is that I started off with V3.8 and ended up with V5.12 with most (if not all) of the updates being obtained by clicking on the “check for updates” button. I quite intentionally haven’t updated to V6 because I rather suspect that it will almost certainly result in experiencing problems and/or performance issues if installed on a somewhat antique system and, like you, I don’t believe that there is any significant benefit in any case.

The thing about stopping and restarting cmdagent on-the-fly MAY well be beneficial and it isn’t necessarily the same as rebooting. One problem that I’ve seen several times over the years with various different applications is that the order in which background tasks are loaded and the time taken for each of them to be fully up and running can be very significant. For instance, if Application “A” always loads and is fully up and running before Application “B” then all is well. However, if Application “B” loads and tries to start doing something before Application “A” is fully up and running then it will either fail to work satisfactorily or get terminated due to some system error. The relative startup timing of the applications being loaded can also change subtly over time as other stuff is installed or removed and it’s entirely dependent on how Windoze is feeling on the day in any case I suspect ! I can think of several occasions where I’ve been unable to just let various stuff load as it wants to on startup and have needed to force things to happen in a specific order so as to avoid strange problems with stuff not working quite as it should do.

This may be the case with cmdagent. For example, if it loads and attempts to obtain an update BEFORE the firewall (or network) is up and running then it almost certainly ends up being blocked and this blocking action COULD quite wrongly end up being somewhat permanent. This is exactly the sort of thing that I experienced with another well known (and very reputable at the time) firewall many years ago. As the firewall application became more bloated and very much less efficient as a result of the numerous updates over time, the problem went from being a random and very occasional issue to one that occurred virtually every time I started Windoze. In the end I had to resort to loading various applications using a single .bat file on startup rather than just letting Windoze automatically load each of them individually on startup. Adding suitable delays to ensure that the firewall was guaranteed to be fully up and running before the various other applications were loaded and run in a consistent order solved the problem completely. Booting/rebooting will never result in an entirely consistent startup sequence BUT killing and restarting cmdagent after Windoze and everything else is fully loaded and running will always ensure that everything else is definitely up and running BEFORE cmdagent starts trying to do anything. Something kinda like this MIGHT perhaps explain why cmdagent sometimes fails to work correctly on normal booting, generally works correctly if you reboot and always appears to work correctly if you manually kill it off and restart it. It shouldn’t be too difficult to come up with an appropriate permanent ‘fix’ if startup timing is found to be the root cause of the intermittent problem.

43

You should just update to version 6. Or wait for version 7. Not sure when the stable product will be released but the BETA is already working well. Version 7 will be a nice upgrade.

44

Why ? ? ? ? ? Newer is far from being guaranteed better and apart from anything else, updating to V6 has already been found NOT to fix the problem directly in any case. As stated earlier in this thread (and elsewhere) by other users with a similar problem, virus signature database updates still failed after a considerable amount of time spent messing around and installing a more up-to-date version. With all due respect, without fully understanding what the problem actually is, any suggestion by anyone to simply install a different version is very much on par with the old “have you tried turning it off and back on again ?” It’s not really a sensible and considered solution with a reasonable chance of success at all but rather more a case of no one has the faintest idea what’s going on or why but they can’t think of anything else that will make you go away and stop complaining about something not working … if only for a relatively short period of time !

In principle, the currently installed version of Comodo hasn’t been updated in years and NOTHING else has changed on my system around the time that it suddenly stopped working either. It’s almost implausible that an application that’s worked entirely correctly and reliably for years can suddenly and quite randomly stop working for no good reason given these conditions. Something has without doubt encouraged it to fail and that failure is, in my case at least, apparently a permanent failure rather than being intermittent. Something must have happened or something must have changed somewhere and a reasonable explanation needs to be found before taking appropriate corrective action. Installing a later version is not necessarily a fix and nor is it even a remotely good idea given the fact that if Comodo have absolutely no idea what the problem is, why it’s happened or what might have caused it then there has to be a distinct possibility that the latest version is very likely to contain the same fundamental issue(s) or there has been a security breach somewhere. Making fundamental system changes is therefore not only a very bad idea in general but it may well make matters considerably worse than they already are.

There are only 3 plausible explanations IMHO

(1) A corrupt or otherwise incompatible virus signature database incremental update has been released by Comodo and/or the virus signature database was somehow randomly corrupted when the last update obtained was installed. Attempting to install repeated fresh downloads of the incremental updates does not fix the problem. I have yet to establish whether manually installing a full copy of the latest complete database does or does not fix the problem … but I’m not particularly confident that it will fix the problem TBH as there appears to be some evidence that it hasn’t worked in the past for other users. Having said that, I have already noted that the currently installed database is actually slightly LARGER than the latest version of the complete database available for download. This seems a bit strange at first thought and it might perhaps indicate that the installed database has been partially updated at some point and is therefore now effectively corrupt which is preventing all future updates from completing normally. I think I would expect to be seeing other problems though such as when scanning if that was the case. It could also indicate that the last incremental update installed was in some way dodgy and has now been dropped of course. I definitely need to try a manual full database update but I’m waiting for a newer version to come along as there hasn’t been an updated download since 28th Jan despite the claims of it typically being updated every couple of days.

(2) Comodo have a fundamental problem with their server(s) or have (intentionally or otherwise) disabled the product in a similar way to what would have happened if a paid-for subscription had expired.

(3) The application or system in general has been compromised and someone or something else has disabled the product.

What’s concerning me greatly is that Comodo has claimed for absolutely ages now that my product is “up to date” when manually checking for updates and the only changes that have therefore been made since it was first installed have been due to the very regular installation of incremental updates to the virus signature database. These updates have been obtained every single day, at least once daily and most likely on an hourly basis.

HOWEVER around the time that the problem occurred and update attempts first started failing, other strange changes appear to have been made to the Comodo installation and quite possibly to the Registry as well. How can this possibly be when no product updates were available and only incremental database updates were being obtained ? Something else has apparently been quietly downloaded and installed (or existing files modified) and that something else quite obviously has the potential to cause problems and/or disable the product. What needs to be established here is what exactly has been going on and whether Comodo are or are not responsible for doing it. Maybe stuff still gets updated in some way as a matter of course even if no updates are actually available ? I need to check that out sometime just in case it’s ‘normal’ but not just now as I’m trying to minimise changes until a likely explanation for the problem is found.

If Comodo have done something that they perhaps shouldn’t have done then that’s fair enough, mistakes do sometimes happen and all that. They should also be able to confirm what’s happened and advise how to sensibly fix the problem if it can’t be fixed automatically by another download to reverse the changes. Reinstalling the product, installing an updated product or generally and blindly hacking or tinkering around with stuff is most definitely NOT in any way a sensible fix. However, if Comodo insist that they have done nothing at all unusual, they aren’t responsible for what’s been changed on the installation and they haven’t (intentionally or otherwise) remotely disabled the product … then the only plausible (but hopefully very unlikely) explanation remaining is a security breach.

So Mr.Comodo, some realistic and honest answers please because this is pretty important stuff. There must be a reasonable and perfectly understandable explanation for the sudden problem. Strange things don’t just happen … and it has to be said that there is a certain amount of evidence to suggest that strange things much like this have been going on for a very long time and affecting various different versions of Comodo, albeit fairly infrequently and very inconsistently unfortunately so no doubt a complete nightmare to try and pin the problem down !

45

It’s stupid o’clock in the morning (UK time !) but curiosity finally got the better of me and it’s

… well, definitely looking very promising at least so it’s hopefully good news anyway :slight_smile: A li’l premature for major celebration I think so I’ll wait until a few more incremental updates have been released, downloaded and installed successfully before being completely happy that it is sorted.

It looks very much as though Comodo ■■■■■■■ up the last installed update completely and therefore mangled the database in addition to definitely tinkering around with various other stuff in the installation for no particularly good or indeed valid reason. More later when I know for sure whether everything now seems to be working again reliably … or not as the case may be !

46

[at]Eddy (and anyone else with this problem)

The next time you get the problem, have a look in the “scanners” directory [##] and see if you’ve got a file called “bases.$$$” in there.

bases.$$$ appears to be a working file containing all the downloaded incremental updates which is ultimately merged with the live database and then deleted providing that the update process completes satisfactorily. If the update process fails for any reason then this working file seems to be retained and effectively acts as a cache for previously downloaded incremental updates. The next time an update is attempted, the previously downloaded incremental updates do not appear to be downloaded again, only new incremental updates are downloaded and added to the working file.

Just a theory … But if for any reason there was a ‘bad’ download and this is what is causing the update process to fail then this duff data could possibly be retained in the working file which would then lead to getting repeated failures. Apart from anything else, rebooting or stopping/restarting cmdagent.exe appears to have the effect of forcing Comodo to download all available incremental updates again even if the working file is present. This obviously generates a new working file with entirely fresh data. Assuming that all downloads are ‘good’ this time then the update will also complete satisfactorily this time.

So, if you do find the file “bases.$$$” then rather than rebooting or stopping/restarting cmdagent.exe just try deleting or renaming “bases.$$$” instead to see if that also fixes the problem by forcing a fresh download of all available incremental updates. I don’t know if it’s actually possible to do it or not with your particular problem because the file could be locked and you probably need admin rights as well but it’s something that I could do and it might be worth a try. If it does resolve the problem then it would suggest download errors and a lack of error checking or sensible error handling is what is causing these problems.

[##] typically "Program Files\COMODO\COMODO Internet Security\scanners" on the drive where Windoze is installed

47

@ambrougham,

As far back as I can remember, there has always been a bases.$$$ file in that directory. But, for the sake of the experiment, the next time my virus definitions fail to update properly, I’ll delete that file and try it again BEFORE I kill cmdagent.exe to see what happens, then I’ll report back here. Meanwhile, I just did the cmdagent.exe kill and restart thing yesterday (and updates have been working OK since then, as usual), so it will be 2 to 4 days before I can try the experiment… i.e., my definitions updates likely will work fine for a few more days before they fail again. I manually update at least two or three times per day, so I will catch it soon after it happens again.

Meanwhile, have you tried this (deleting/renaming bases.$$$) and did it work for you? I wasn’t clear from your last post whether or not it had.

Also, I notice yet another thread on this very same topic has been started in this sub-forum. One hopes that user will read through this thread and let us know if any of these workarounds work for him/her.

Cheers,
Eddy

48

My problem appears to be completely sorted :slight_smile: I’ve not seen any errors or any other problems at all so far, everything is back working just as it always used to after replacing the apparently mangled database. I’ll do a full report when I get a chance just in case anyone else is interested and/or someone at Comodo feels like looking at what happened. It might possibly be of help to them in resolving whatever the root cause of this issue is because it could well be a problem even with current versions.

However, along the way I had this feeling that some of the incremental updates weren’t being downloaded every time I tried a manual update. I then proved beyond doubt that they weren’t always being downloaded unless the update attempt was the very first one made after a reboot. What I then found is that “bases.$$$” appeared to contain the downloaded incremental updates or at least every time that a new update was released and downloaded “bases.$$$” got appropriately larger anyway. If I tried to update again then nothing at all was downloaded unless a new incremental update had been released since the last attempt. The only occasions where ALL available incremental updates were actually downloaded was immediately after a reboot, after stopping/restarting cmdagent.exe and also after doing a few other somewhat dubious things as well but they’re not important, what is important is that deleting “bases.$$$” resulted in ALL available incremental updates being downloaded and the file always being regenerated. Since I’ve fixed the problem and updates started working again reliably I have NEVER seen “bases.$$$” again.

I therefore strongly suspect it’s a temporary working file that gets generated during the update process and then deleted at a successful conclusion when all the incremental updates have been merged with the live database. In my case at least, the only time it appeared to be there is when there was a problem and the update was always failing. Now that I don’t have a problem I also don’t have “bases.$$$” hanging around on a permanent basis either but I suspect it’s almost certainly there during the update process. I haven’t found a sensible way of actually proving that as yet but I’m working on it ! I’ve just had a fleeting glimpse ( Mmmmm, Floyd :stuck_out_tongue: ) of the (in)famous “bases.$$$” 8) It mysteriously appeared just as Comodo started an automatic check for virus signature database incremental updates … and then disappeared just as mysteriously as soon as it had finished ! It most definitely is a temporary working file and I would therefore be almost 100% confident in saying that if you’ve got it when an update ISN’T in progress then you’ve got the update failure problem.

My problem was apparently caused by a mangled live database following 1 particular update. Therefore no matter how many times all subsequent incremental updates were downloaded the update process always failed. It was a permanent issue that couldn’t ever be fixed other than by replacing the live database with a working version. Your problem whilst similar appears to be intermittent in that a reboot or suchlike resolves the issue. I think that it’s quite likely that a ‘bad’ incremental update was merged with my live database and caused my problem. My theory is that your problem may also be a result of a obtaining a ‘bad’ incremental update but fortunately it’s not being merged with the live database. However, it is possible that it’s being effectively cached though in “bases.$$$” and therefore the only time the ‘bad’ incremental update is replaced with a ‘good’ version is when you reboot or otherwise force Comodo to download all available incremental updates again. This would suggest that deleting/renaming “bases.$$$” may well have much the same effect as a reboot etc. and also fix the problem. If I’d had the same problem as you’re seeing at any time in the past then I would never have known about it. My updates are always obtained frequently and automatically plus I always reboot at least once a day as a matter of routine. The only reason I found out that I had a problem this time was because it had persisted for more than 48 hours and Windoze whined about it ! Comodo is usually simply sat there doing it’s thing just like it has been constantly and consistently for several years ever since I first spent ages setting it up. I never even think about it now let alone actually go and have look to see whether it’s been grabbing updates successfully or not. The last time I went anywhere near it would have been to tweak the firewall and that’s most likely to have been several months if not years ago.

If I’m (sort of) right here, it would appear that the cause of these problems is ‘bad’ incremental updates occasionally being obtained, cached and sometimes even actually used because Comodo perhaps isn’t doing a very good job of error checking/handling. By ‘bad’ I mean this could be data errors, incomplete data, missing data, transmission errors or any number of other things resulting from server, connection or system issues and so on. If the ‘bad’ data somehow gets merged with the live database then you ultimately end up with a permanent failure but if it’s detected or Comodo is somehow prevented from actually updating the live database with ‘bad’ data then you end up with a temporary failure that generally gets resolved following a reboot or similar when all relevant data is downloaded again.

I may well be completely wrong of course but I certainly don’t think that you should be seeing “bases.$$$” UNLESS an update attempt is actually in progress or the problem with Comodo being unable to complete the database update currently exists. It seems to me as though deleting/renaming “bases.$$$” might just have a positive effect if only by ensuring that fresh data is obtained so I reckon it’s well worth trying a few times just to see what happens anyway :slight_smile: Do make absolutely sure that an update definitely isn’t in progress before you go trying to delete it though.

49

You have Windows XP so that would give a different experience than 7. Hope some of the other members can help you more.

50

[at] AD18

My problem is fortunately now completely fixed ;D and I’m currently just trying to get to the bottom of what exactly has been going on to give so many users such strange problems over such a long period of time. If the problem can be fully understood then hopefully an appropriate, reliable and consistent fix can be found to help those users who are still struggling to get things working properly again.

All I was saying is be very careful when suggesting blindly reinstalling or upgrading stuff :slight_smile: Without knowing what’s going on and without there being a very good reason for making such complex system changes when you have an unexplained problem, it can (and quite often does !) not only make the problem significantly worse than it already was but it also has the potential to trash the entire system meaning a complete reinstall of everything will ultimately be needed. I’m pretty sure that you’d find yourself on the receiving end of a serious amount of abuse if someone just happened to try it thinking it was an easy option … and things went horribly wrong for some reason !

51

Glad to hear your problem is fixed. :slight_smile:

52

@ ambrougham,

Today my virus definitions update failed again so, as per our experiment, I did NOT kill cmdagent.exe and instead found and deleted bases.$$$ in the scanners folder. I then tried to update again and it still failed.

So, as before, I killed cmdagent.exe, then immediately restarted that service and the update concluded successfully, as usual (for me).

I think this shows that a) my problem is different from yours (even though the symptoms seem to be exactly the same); and 2) deleting bases.$$$ may not be the panacea for everyone as you (and I) had hoped.

Eddy

53

[at]Eddy

Exactly the same findings here as well ! Now that I know about this update failure issue and have been actively looking for it, I saw the same problem as you’re getting this morning. The recent fresh install of Comodo on an occasionally and only lightly used system spent several hours trying (and failing) to update the database automatically. It appeared to have all the incremental update data required but subsequently failed at various points and ultimately at the often seen “finalising” stage. Manual update attempts had the same result of course. This problem could quite easily have been randomly happening almost every day for years and I wouldn’t ever have noticed 88)

Deleting “bases.$$$” also didn’t seem to help unfortunately and it didn’t appear to force a complete download of all the incremental updates either which was a bit strange because it certainly seemed to do that on my main system the other day.

Killing/restarting cmdagent.exe did have the desired effect of course as no doubt would the next reboot. Suffice it to say that I now have a shiny new shortcut within very easy clicking distance for the next time I need it … 1 single click and you’re dead mr.cmdagent, although fear not as you will be automatically resurrected shortly after :stuck_out_tongue:

All very strange. I grabbed copies of various stuff to have a good look at later when I get chance. There must be a good reason why this is happening and there ought to be a sensible fix as well. I still suspect that update failure problems various are all somehow related. I’ll keep watching for when the problem turns up and trying to work out what’s going on anyway :slight_smile:

Your system didn’t fail trying to obtain updates up to and including #17734 or #17735 by any chance did it ?

54
Your system didn't fail trying to obtain updates up to and including #17734 or #17735 by any chance did it ?

I don’t know which definitions update or .cav file first failed. This started happening for me in Fall 2013 on a laptop, then later, early December I think, on my main desktop pc.

Did you write a batch file to kill and restart cmdagent.exe? Does the “net stop” command kill the service? I should try that. I know the stop command is grayed out on the microsoft services console gui.

Eddy

55

Running “taskkill /f /im cmdagent.exe” at the command prompt should kill off cmdagent and then running “sc start cmdagent” should restart cmdagent in the normal way it’s started at boot up. I’m reasonably sure that both commands are available as standard in WinXP Pro as I don’t remember installing a Resource Kit or anything special on these systems. There might be an issue with needing admin rights of course so you may have to deal with that appropriately. It ought to be the same for other versions of XP and maybe also for later versions of Windoze as well but good old Billy Gates & Co do like to tinker around and make seemingly random changes between versions unfortunately so stuff sometimes gets added, removed or changed without there being any particular reason let alone a valid one ! Try it manually first just to make sure the commands do exactly what they should do without complaining and/or resulting in some error message.

Then you can either set up a couple of shortcuts to easily run the commands independently or a single shortcut to a batch file that does both. Running Windoze commands in a batch file can sometimes be problematic in that just because the next command is being run doesn’t necessarily mean that the previous one has actually completed. I therefore included a check to make sure cmdagent had definitely been killed off before attempting to restart it. There are no doubt far better ways of doing it as this could potentially hang under unexpected conditions but as a 10 second job it’s good enough for me at the mo and ought to work satisfactorily for you:


[at]echo off

taskkill /f /im cmdagent.exe

:wait:
tasklist | find /i "cmdagent.exe" > nul
if %ERRORLEVEL% equ 0 goto :wait:

sc start cmdagent

Killing stuff off isn’t something you want to be doing too often as it can lead to resources getting hogged until you next reboot but occasionally is fine. In my case I can also easily add a check for “bases.$$$” hanging around for much too long thus indicating that the failure has occurred during an automatic update. If I ran the batch file in the background at startup or schedule it to run every so often then it would automatically kill/restart cmdagent whenever the problem shows up.

Not exactly sufficient evidence to prove anything at all but it is beginning to look like the less frequently you obtain updates the more likely the problem is to happen. I say this simply because the problem has shown up twice now on a system that’s only powered up every few days so always has several updates to download but not at all on the system that’s running almost constantly and therefore generally downloads them one at a time as they become available. There is absolutely no evidence so far to suggest that often using sleep/hibernate and wakeup rather than shutdown and reboot is in any way significant which was another of my theories for what might be encouraging the problem to occur.

NOTE: that the “[at]” in the batch file code is of course the “at” symbol as in e-mail addresses, it’s just that the msg board software tweaks it even in a code box !

56

Thanks! I’d forgotten about the good ol’ TASKKILL" command.
Eddy

57

I have Comodo installed in my Windows XP old netbook for years running flawlessly, but now I can´t update the virus signature database, exactly as described by many others in this thread. The last sucessful updated is reported to have been done on January, 21.

I tried all workarounds suggested: changed the log on as, removed the bases.$$$ file and killed the cmdagent.exe, but nothing has worked for me.

If anybody has any other suggestion, I thank you very much.

58

It sounds like you might well have the same problem as I had with what appears to be a dodgy incremental update and/or a mangled database :frowning: Something very strange happened for me (and other users) on 26th Jan that somehow appeared to mangle the database and prevent any subsequent updates from ever being installed despite Comodo having been running constantly without any significant problems at all for several years.

If you haven’t already done it, try manually updating the virus signature database to the latest available version. Replacing the database with a ‘good’ version completely solved my problem and everything has been back working just as it always used to ever since. Even if it doesn’t fix your problem, it does at least mean that you will have almost all of the latest updates installed until you can work out what has gone wrong and get it fixed properly.

Be VERY CAREFUL when doing this because mistakes could potentially make your problems worse than they already are !

(1) Download a copy of the latest Virus Signature Database “bases.cav” from Comodo - see info HERE and/or HERE

(2) After unpacking the database where necessary, restart Windoze in safe mode. You cannot make the following changes with Windoze and Comodo running normally.

(3) Rename the file “bases.cav” in the “scanners” and “repair” directories [##] to something else (eg bases-old.cav) just in case you need to restore them later. Delete the file “bases.$$$” if present.

(4) Copy the downloaded latest database “bases.cav” to the “scanners” and “repair” directories.

(5) Reboot Windoze normally and hope for the best … crossing fingers is optional but highly recommended :stuck_out_tongue:

If you find that Windoze wont let you do this even if you have admin rights and are running in safe mode then boot your system with a Linux Live CD/DVD/USB instead but be even more careful that you don’t accidentally do anything silly while making the changes ! Hopefully replacing the database will resolve the problem for you just as it did for me :slight_smile: If it doesn’t then I haven’t got any other suggestions I’m afraid because I still haven’t managed to work out what’s been going on as yet.

[##] Typically "\Program Files\COMODO\COMODO Internet Security\scanners" and "D:\Program Files\COMODO\COMODO Internet Security\repair" on the drive where Windoze is installed.

59

Hello Everyone, I too had this AV database update issue recently on a XP sp3 system with the same CIS version listed in subject. I noticed not long after the most recent microsoft patch tuesday, when I would go to the CIS interface to manually check for updates, the updater seemed to act too fast to be effectively checking for updates.

I had also taken a major browser performance hit, as pages would take a long time to load and sometimes load incompletely. I then checked task manager, and noticed cmdagent.exe using 99% cpu. After selecting cmdagent.exe and terminating the process in the defense plus active process list and a system restart, I again went to CIS interface to manually check for updates, and this time the updater began to function as intended, tho it took a long time to reach 90% complete and once it reached that point, it took twice as long (approximately 15 minutes) to complete the virus definition update.

I’m not for certain, but I think instead of restarting system after the virus definition update, I immediately started a full scan. Upon returning to the system some hours later, I noticed the scan had completed yet the cpu usage was maxed due to cmdagent.exe. I then checked the firewall (active connections) list and noticed multiple connections to an ip address with an address of 99. something loading about 64 bytes each (unfortunately I did not write this exact address down).

I then closed any running processes and put system in standby mode until the next morning. Upon starting the system that day, cpu usage was normal, cmdagent.exe was not running in process list, and my browser speed has returned. System seems to running well as before the issue. I have not tried to manually check for updates since, but I thought I would share this experience in case I overturned a stone that one of us had missed.

60

When cmdagent.exe is not running you won’t be protected. Does cmdagent.exe still hog the CPU when it runs again?

If it hogs the CPU again would you be willing to see what happens when you use system restore to go back before Patch Tuesday and see what happens?