Update Hangs for 2 minutes during "installing updates"

Comodo Internet Security - CIS AntiVirus Help - CIS
#1

I am running Windows XP SP3 with all updates, clean re-installed last month to a new hard drive. I have 2 gigs of memory, and an AthlonXP mobo, and my system is to all appearances and testing working flawlessly in every way EXCEPT

When I haven’t used my computer for a couple of days, on bootup, the COMODO CIS icon is orange with exclamation point, indicating the database needs to be updated. So I open CIS and click on updates, and CIS downloads the virus signature update in a reasonable amount of time (I have a high speed internet connection over cable modem), then the “installing update” phase proceeds at a reasonable speed up to the 90% point, and THEN it hangs at 90% for TWO MINUTES straight. It does finally complete seemingly normally, but I have never had an antivirus, including Comodo past products, that took SO incredibly long to install the database.

This is CIS version 7.0.317799.4142

It otherwise seems to be functioning completely normally. What gives?

mr coffee

#2

Is it normal.
It is process of initialization AV bases.

P.S. In old versions in time process of initialization appeared the file of bases$ $ $. - then to disappeared.
In the folder with a name - \scsnners
Also: A caching builder - tune off in the AV settings.

Run cache builder - Tune off
I think process of initialization will be quicker.

#3

There are three times during when updates hesitate. After download of segments, i.e., 50%, then it merges the segments into a copy of the then existing AV def DB. At 90%, its copying the existing AV def DB on disk to backup, writes out the memory copy of the updated AV def DB to disk, stops AV service, unloads the old AV def DB from memory. At 95% it begins activating the new updated AV def version in memory and then cleans up after itself, e.g., it poofs the downloaded segments (among other things).

#4

Two minutes is not bad on older or otherwise underpowered hardware. It takes longer on my now aging Asus EEE netbook. That being said it is resource intensive as you noticed.

#5

Thanks for replies and explanations of the update process. I’m not sure if all who replied really got the amount of time it hangs at 90% when you say that is “normal.”

As WxMan said:
At 90%, its copying the existing AV def DB on disk to backup, writes out the memory copy of the updated AV def DB to disk, stops AV service, unloads the old AV def DB from memory.

This is the point at which the update hangs for over TWO FULL MINUTES. This is not a hyperbole - this is measured with a stopwatch. I’m not talking about the time for any other aspect of the update - just the time from when the “installing update” bar first says “90%” - not the overall update bar, just the “installing update” bar - to finally unfreeze, after which the process goes back to moving along briskly.

The 95% to finish flies by so fast I’ve never seen the “95%” mark.

Here’s what I figure (please correct me if I’m wrong)

  1. “copying the existing AV def DB on disk to backup” should take 10 seconds tops
  2. “writes out the memory copy of the updated AV def DB to disk” should take another 10 seconds tops
  3. “stops AV service” should take maybe 15 seconds tops
  4. “unloads the old AV def DB from memory” should take maybe 10 seconds tops

I wouldn’t begrudge it taking (10 + 10 + 15 + 10) 45 seconds - it’s the 120 to 150 seconds that makes me think something is hanging the program at that (particular) “90%” mark on the “installing updates” progress bar.

I can move sizeable files manually in less than 10 seconds with select-drag-drop. I could not test the time to stop the CIS service manually as this is grayed out in Admin Services panel. Is there some complex rigamarole the update has to execute in order to turn off CIS temporarily to install the update (like to make it harder for a virus to turn it off or something) that is eating up all that time? I can manually stop other services in 10-15 seconds.

Jenny said:
Run cache builder - Tune off
I think process of initialization will be quicker.

I’m not sure what I would be turning off by turning off the “cache builder” because I don’t really understand what it is. Can you explain further what this would do? I read the link, but didn’t get what that had to do with the installing-updates process.

I’ll check back for responses to this thread on my laptop over the weekend, and leave this computer off all weekend so I can test the length of hanging at 90% with a manually-initiated update on Monday, with the “cache builder” turned off and see what difference that makes.

Thanks again for replies and efforts to make sense out of this program behavior, which seems abnormal to me anyway.

#6

That I quickly found.
https://forums.comodo.com/antivirus-help-cis/cache-builder-t90735.0.html;msg654291#msg654291

#7

FWIW: my comments are 100% SWAG opinions 88)

My opinion are void of any warranty - express, implied explicit, implicit or otherwise - exists, and as such shall be held indemnity harmless for any and all claims made resultant my comments pertaining to any and all losses, physical, ethereal or otherwise imaginary (and not exclusive that which I’ve not mentioned). No angel from on high has ever come down and blown the celestial trumpets after my commentary. Use at your own risk. Your mileage may vary. Last long time works good. Void where prohibited. All claims shall be adjudicated by arbitration with Cylon model 7 as arbitrar.

#8

What you’re complaining about is indeed ‘normal’. Where’ve you been; its been doing that for years; it was a lot worse before they implemented the segmented AV def DB update technology. No longer does the update pull down 150MB each and every update.

Until v6.x the process I described is accurate in so far as a copy of the pre-update AV dev DB was written to the %COMODO_root%\repair folder. What everybody did on the rare occasion that the AV update failed, was to ■■■■ away the /scanners bases.cav in safe mode and then reboot. As far as I know everybody did that ‘cause everybody knew that at boot-time, when CIS couldn’t find /scanners/bases.cav, it copied the /repair one into its place. That’s my story and I’m stickin’ to it.

Now, things are different. The Comodo gnomes utilize /scanners/bases.cav as a catalyst and react all the signature files with other stuff. Then the gnomes implement phase II. Once Phase II is complete, the Comodo gnomes implement phase III, i.e., make two files - one slightly bigger than the other - having the form ‘b#######.cav’ and the original bases.cav remains unchanged.

So there’s obviously some stuff that’s going on there; it takes two minutes for that on your machine. On my machine it takes somewhat longer; I’m very happy when it says ‘successful’.

What bothers me: it takes 20 seconds for CIS to finish all its gyrations and the happy dance the Gnomes gnomes have to do each and every stinkin’ time an alert pops up and allow ‘remember this’ is ticked.

If all you’re complaining 'bout is a two minute wait at AV update, you’re getting off light.

What if I just answered 10 alerts in a row - with ‘remember’ ticked - and suddenly the auto AV def DB update kicks in with that 2 minute wait [at] 90%. But I just launched newly installed app (or just removed something), and the system comes to a creachsing halt.

Its froze, its locked up, I can’t do nothing: the mouse moves, the CAP LOCK / NUM LOCK lights will toggle, don’t do nothing. Oh, wait, yes it does, no it doesn’t, oh, wait…

You come over here NOW. GET this ■■■■ off of my computer NOW.

You’re getting off light.

#9

I have 4 different OS’s and I must say that the biggest hangs during updates occurs on the XP system.
Admittedly my XP is also on the my oldest hardware.

#10

YOU can NOT be older than me, i.e., socket 370 Tualatin 1400 O/C

I’m not going to sweat two minutes for AV def DB update.

What I sweat is a client w/ P4 3.2 w/ 3GB of DDR400 dual-channel that can’t handle Comodo and makin’ demands with their XP SP3.

I’m thinkin’ ‘bout pullin’ the shingle in; I don’t know what I’m talking anymore.

Brother can you spare a dime?

#11

Couldn’t wait.