I agree with and/or already knew about everything you posted above with the exception of this ! I’ve never actually bothered to look in “quarantine” when the system isn’t running normally (there’s no access normally of course) so I hadn’t spotted that it was the hiding place for the cached data I just knew was hanging around somewhere. Every time I’ve manually updated the database it’s just been a quick copy of the file and back to normal again. I’ll be doing some poking around shortly to see what else (if anything) may be hiding in there that could help get to the bottom of this problem. Many thanks for the info 
I’ve been using comodo continually since V3 was released and although many users have reported similar update problems many times over the years, the very first time I saw it was in January this year. Once manually fixed, the problem didn’t recur for me for quite some time despite other users still reporting having the problem. However, just recently it’s been getting silly and I’ve been regularly seeing comodo unable to update the database for lengthy periods of time and several occasions when I’ve had to do 1 or more manual updates to fix the problem.
Whilst there has almost certainly been some relatively minor problem with comodo and database updates for donkey’s years it’s definitely getting worse and happening much more frequently. Something must have changed and my guess is that a major change happened sometime early January 2014 and just recently something has made matters even worse !
Some other thoughts and finding just for the record and in case anyone else is interested:
DNS ISSUES
cmdagent appears to only perform a DNS lookup when it first loads and then seems to cache the results forever. At the very least it does not appear to take any notice of the TTL that’s for sure. I have evidence to show that cmdagent obtained the server addresses initially and then repeatedly used the same server addresses for all subsequent new connections to the servers over a period more than a hour DESPITE the DNS data actually having changed several minutes after the initial lookup when the TTL expired and continuing to do so at frequent relatively short intervals thereafter.
Although the cached address is most likely going to remain a valid address in all but the most unusual of circumstances, it still makes a complete mockery of using DNS to effectively load balance several servers sharing the same name. For instance, cdn.download.comodo.com has 5 associated IPs and the TTL seems to be typically just a few minutes. cmdagent performed a lookup and cached the first IP when it initially loaded. Subsequent manual DNS look-ups over the next hour or so resulted in the order of the server IPs changing several times yet cmdagent continued to use the initial cached IP indefinitely.
When there was (presumably) only a single IP with any load balancing being performed by hardware there was no problem but now comodo have changed the way data is being served, it’s not really acceptable practice to apparently cache a DNS look-up indefinitely. Apart from anything else, DNS records can (and do) change - that’s why they have a TTL ! At best it’s bad practice and at worst it’s a significant source of server problems.
RESOURCE HOGGING
Once comodo has encountered an update problem it continues to retry updating the database every ~10 minutes. This means cmdagent needs to do 3 to 5 minutes of intensive processing every 10 minutes until such time as an update is successful. End result: cmdagent consuming at least 30% of CPU time on average (with a significant period of time closer to 100%) continually for several days if not weeks. No wonder my poor old system feels like it’s ground to complete halt whenever this problem shows up ! A huge portion of all available resources are being hogged by cmdagent for processing the same old ‘bad’ incremental update data over and over and over again despite the fact that it will almost certainly never result in a successful update.
Generally speaking, only a manual install of an updated and valid full database together with all subsequent incremental updates being ‘good’ can resolve the problem. Only then will cmdagent return to updating the database once every hour or so. The caching of DNS and downloaded data does nothing to help the situation either. If there were a genuine problem with some of the data, it had been changed or there was a server problem then cmdagent will never attempt to download data again until such time you either reboot or kill and restart cmdagent.
PHONING HOME
There are (were !) and almost always have been multiple and very regular attempts made by comodo to connect to no-dns-yet.ccanet.co.uk [199.66.201.22] and [91.209.196.27] for instance along with numerous other IPs on port 4447/8. This has been going on ever since some time way back in 2010 if not earlier. It was the simple fact that I suddenly found my access logs were packed full of these completely unauthorised connection attempts after installing comodo that led me to deal with the problem and they’ve been blocked ever since. There is even some historic evidence of port scanning coming from these IPs. My sensible guess is that comodo is (was !) probably attempting to test the firewall and report or upload vast amounts of stuff that it had encountered some problem with such as files that failed AV check and so on. However, Mr.Paranoia reckons comodo is simply attempting to spy on me and report back on absolutely everything I do no matter what or why on a 24/7 basis :lol:
Much like the database update issues, there is absolutely no shortage of other users reporting these unauthorised connection attempts and similar strange things going on after installing various versions of comodo. A simple investigation on any of the fairly lengthy list of IPs I’ve logged over the last 4/5 years for making unauthorised remote connections and/or being suspected of other strange activity usually shows them all relating to “Comodo CA” in some way. There are plenty of threads on these forums (and elsewhere) reporting similar findings and at no time has anyone apparently given any sort of reasonable explanation needless to say ! Any so-called security application making unauthorised connections and suchlike is just wrong in every way possible no matter what the specific circumstances may be or how innocent it might be.
‘DUBIOUS’ INCREMENTAL UPDATE FILES
I can’t really explain why I think some files look ‘dubious’ as it’s just a feeling I get when I look at the data but there does appear to be a pattern. Some files tend to look somewhat different and it’s these files that tend to result in comodo ending up with the update failure problem. However it’s not a simple case of a “when this happens then the end result is always that” kinda thing. Both of the 2 systems I have comodo on behave similarly but somewhat differently. They don’t always fail at exactly the same time on the same file but that’s primarily because 1 is powered and being used almost 24/7 whilst the other is only powered and in use intermittently. Frequently updating the database definitely appears to minimise the risk of a problem showing up. However, once there is a ‘bad’ incremental update to download then the problem will almost certainly show up eventually on both systems because it will totally prevent comodo from updating the database even if there are several earlier ‘good’ incremental updates also available. The only strange and unexplained situation is when the problem has been seen to exist for a period of time, often several hours, but then it suddenly resolves itself without any manual intervention being necessary. The only plausible explanations I can think of are genuine server or connection problems and incremental update files being changed after they’ve been released.
BYPASSING COMODO
I’m not going to say anything more on this other than it sure seems too easy to me. I know nothing about how to implement dubious things on remote systems or indeed about any other dodgy activities for that matter and I have absolutely no desire to find out either … but if I did then I’d certainly know where to start and what I’d be trying to do first !
EDIT: To minimise the issue of cmdagent hogging all the resources it can get it’s grubby hands on while there is an update problem but an appropriate full database download isn’t yet available to manually fix it, add a temporary firewall rule to block access to download.comodo.com and downloads.comodo.com This doesn’t appear to have any obvious side-effects but it does prevent comodo from continually attempting to compile a new database with incremental update data that it’s never going to able to use successfully. Disabling updates and removing the server addresses in comodo settings didn’t appear to have the desired effect unfortunately. Don’t forget to remove the firewall rule when you manually update the database in due course though or you’ll never get any subsequent updates !
:P0l