AV Update a resource hog

When the antivirus updates on windows XP, my computer is largely frozen for about 10 minutes. The attached screenshot shows that it uses between 90% and 100% of system resources to do the update.

For one, it should not use up all the system resources to do this. I have no issues with this PC in terms of speed or performance and have owned the PC long enough to know that this behaviour is anomalous. I only noticed it doing this recently, so I am wondering if there has been a change to the program. Secondly, if it only did it for, say, 1 minute, it might be OK, but what exactly is causing this to take place for 10 minutes??

[attachment deleted by admin]

It’s true that AV updater is very heavy.

I’ve had the same issue on Windows 7 lately but thought I just made an error installing windows. After reading your post I looked closer and determined it’s CIS doing it. EVERYTHING freezes. I have a 3.4 GHZ quad core, there’s NO REASON a simple update tool should choke that. I’ve had to disable automatic updates, as there’s no way to remove this new “feature”

I’ve used comodo for several years and recently I’m becoming increasingly dissapointed. If another free AV had a full-featured integrated firewall like CIS does I’d probably be downloading it right now.

Why it takes so long time to apply & finalize updates? Till the update is completed the system runs sluggish.


It is true that COMODO CIS used to be a joy to work with; but in the last nine months it became increasingly high maintenance with it hogging of resource.

To that end, it [CIS] had to go, but not before painfully trying over a period of nine months to overcome the latency CIS, firewal and AV was evidently causing; Notwithstanding the DigiNotar escapade.

Oh, and before the doubting Thomas’s crawl out of the woodwork to flame the notional idea CIS, not least COMODO was or is at ‘fault’ for not maintaining standards, it’s [CIS] failures when in the form of losing performance, causing the OS to lag, and contributing to system lock up and failures in part to ‘secure’, and are all verifiable; that those symptoms don’t appear at all or to the same or similar degree on other machines, does not mean the problem/s with COMODO and CIS do not or cannot occur or exist.

It was a shame, because COMODO CIS had served me very well; I even purchased the solution with the thought the purchased product may somehow have a better all-rounded engine than the free version, but unfortunately there was no difference… none.

So to the alternative; I’ve since taken a punt on Emsisoft Online Armor et al. It’s early days, but it too appears symptomatic of the paradoxical needs of security providers’ software to do a ‘good’ job, and the ‘users’ drive to have seamless, unwavering and uninterrupted computing performance from the machines users run; will we ever get a balance without something needing to be hit or compromised? Probably not. It’s unlikely we’ll ever ‘have it all’.

It is more than possible a return to COMODO will happen in the future; after-all, security product life-cycles are short, particularly when ‘reputable’ reviewers change the top ten spots by regularity. [Rhetorical - Who to believe? - What to try? - Why?]

I hope you realize that DigiNotar has nothing to do with Comodo…

cavtvs: “Notwithstanding the DigiNotar escapade”.

Indeed, the inference of my comment should be as intended; I cannot account for how the reader contextualises it but for the fact, and in context, that problems were being experienced, ‘notwithstanding’… I made no direct ‘connectoid’ to that of COMODO, just a run-on.

HeffeD: “I hope you realize that DigiNotar has nothing to do with Comodo…”

The above should answer that for you. In any event, under all, and any circumstances, such occurrences should not scratch a CA, let alone penetrate it, but that’s old dirt.

Suffice it to say, if I forget to close the front door to my home, I can expect to find things missing on my return, for obvious reasons.

I appreciate your concern, as you’ll appreciate that my comments’ thrust was not of the DigiNotar escapade or reference, nor a relationship between DigiNotar and COMODO, but that of the incessant energy consumption COMODO CIS was causing my machines to suck [sic].

It is interesting to note that Emsisoft Online Armor and its offering do not offer a ‘better’ position, simply a different experience, and again, not necessarily better.

Perhaps the problems experienced with high CPU [cfp.exe] usage using various *wares, is more to do with inadequate processing capacity [even quad core], to that of necessary software processing demand, by ratio. Most updater’s provoke CPU’s to a greater or lesser extent, as do backup utilities, and that’s probably why it’s more convenient to run either or both at times more convenient to the user. Sometimes though, for inexplicable reasons, cfpupdat would still prod the CPU to excess even when manual updates were set or disabled, as the preference.

HeffeD: Bet you wish you hadn’t asked now ;->

Not at all.

I was just scratching my head as to why such an irrelevant comment was made in your post about the AV taking too many CPU cycles.

The only conclusion I could jump to was that you felt that it somehow had something to do with your problem, so I was only trying to clarify that there is no connection.

“I was just scratching my head as to why such an irrelevant comment… […]”

I can understand why you would be doing that ;-> …

… Though the DigiNotar issue was no different to the COMODO exposure that is perhaps where any connection stops, but that both issues were so very far from ‘irrelevant’ - the irrelevance to which you now refer only appears to be your persistence in COMODO’s defence, which, in and of itself is unnecessary.

Incidentally, ‘I’ did not have a ‘problem’ per se, it was COMODO CIS whach had the problem.

Allow me to spell out to you why I made any mention of ‘it’… COMODO CIS was the pivitol cause of machines lagging to almost standstill. Additionally, it was unhelpful and decidedly inconvenient such problems were being caused by COMODO CIS at a time where there were considerable issues with DigiNotar and the fallout from its exposure.

CA’s like COMODO and Diginotar should exercise greater diligence… no, wait, scratch that… no, not ‘more’ diligence. Not ‘more’ of anything, but secure; more suggest something isn’t as secure as it could be.

Selling security certificates is one thing, running a shop which stores the certificates but with the front door left open, is quite another… it certainly doesn’t demonstrate or exude confidence of a company’s reputation, does it now? But that wasn’t the thrust of my original post, it was moreover that in order to establish and subsequently resolve the true source of the problem it’s unhelpful to have other external problems arise at the same time, ‘notwithstanding’… Had CIS not been a problem to begin with I would not have needed to post, nor would I have aligned the timings of CIS problems with that of DigiNotar, but I did, and so have done.

It is regrettable that the only way to eliminate the excessive, unpredictable and unacceptable COMODO CIS resource hogging was to remove COMODO CIS from the machines effected directly by COMODO CIS.

Granted, DigiNotar is not COMODO, but the problems, similar, associated or otherwise, I could have done without - I know I wasn’t on my own where machines were effected and the downtime experienced.

I hope that puts to rest your concerns and sensitivities regarding my mention of COMODO and DigiNotar in the same run-on sentence, it wasn’t intentional, other than the thrust of the pertinent point and its meaning.

I discern that there have been changes to COMODO CIS since I last used it - would you, HeffeD, recommend I try it again, or is it too early to say?

Thanks for your help.

I agree that CA’s definitely need to take greater steps to ensure the security of certificate issuance. Otherwise, what is the point of said certificates if they cannot be trusted?

Unfortunately, the issue of excessive CPU usage is a tricky one. The majority of users don’t have this problem. Since it’s impossible in the field of software development to account for every possible iteration of hardware/software that a user may decide to assemble, there are very real bugs that could surface that affect only a very small percentage of users. Unless these users report the issue giving as many system specifics as possible, there is no hope for the developers to reproduce the symptoms, thus squashing the bug.

I have read some users saying that 5.8 (the latest version of CIS) is better resource-wise, while others are saying the issue still exists. Is it fixed for you? Only you can say. I’m not going to tell you that you should give it a try and see if CIS still has an issue on your machine, but you’re more than welcome to do so. :slight_smile:

Personally I have seen this in 5.8 . The system hangs at 90% of the update (the stage of merging all the downloads and the current file and re-compressing it). Older systems with singe core and Atom like processors suffer the most under this load. The first series of duel core Cpu does get affected also. I make this statement because I oversee ±120 computers at work with different configs and cpu. Then memory plays a roll in this also , systems with 1024M and lower is prone to get stuck longer.

Trust is indeed, key… without it, doing business, at any level, can be difficult.

HeffeD: “I have read some users saying that 5.8 (the latest version of CIS) is better resource-wise,[…]”

Well, it certainly appears to be… and that is a fact, so far at least. A very welcome change and a pleasant surprise. ‘Well done COMODO?’

HeffeD: “[… while others are saying the issue still exists…”

The only logical recommendation I could make to others who continue to experience such CPU anomoly, would be to clean out previous versions of CIS completely, registry values et al, and… install as you [HeffeD] ‘suggested’ [5.8] or later, but with one very important, yet overlooked, or taken for granted ‘advice’ from all software vendors, and that is to ensure, as best you can, that little to nothing is running which might impinge upon a successful COMODO CIS install. That, followed by an AV update [80ish MB], and finally a full scan [~2-4 hours uninterrupted - a variety of machines].

Do that, and the ‘chances’ are, it could be the one! Where have I heard that before?

Heffed: “Is it fixed for you? Only you can say.”

You appear to ‘know’ there was a real problem with ‘previous versions’ of CIS, specifically the AV and high CPU; Perhaps COMODO declared that they knew there to be a problem, but I don’t remember seeing any such declaration.

So yes, I can say with some obvious certainty that CIS certainly appears to have been [tamed] ‘fixed’ for my machines, all of them, without fail.

An additional, yet useful program for number crunching machines, is one used by SETI users, entitled ‘Threadmaster’ [a quota management tool] which could help some users with high or unmanageable CPU usage, which addresses possible problematic programs. For none techy users Timwells.net provides a very useful GUI entitled ThreadMasterGUI for the otherwise ‘registry based Threadmaster ‘tweaker’’.


I appreciate your input, HeffeD, thank you… ‘see’ you around. ;->

No, all I ‘know’ is that some users who have reported the issue previously have said that 5.8 solved the problem.

The developers did say that 5.8 is the lightest and fastest release yet. It appears as though some of their optimizations might have fixed a bug that was causing this problem for some users.