Following all the tips in this thread, I’m still not able to update, stops at 30 %. I’m reluctant to go back to Avira but I guess I have to unless someone solves this problem soon.
I had a simular issue. Opening Internet Explorer first then doing the update (as a one off) worked for me, eventually. Also check for updates in Miscellaneous as .509 is now out!
E
Nope, didn’t work, first this:
then this:
Never getting past 30%.
Did CIS detect your network after you rebooted?
Ended up reinstalling CIS from scratch, all is good now. 
3.9 (509) don’t want to update more.
the AV database number is 1154.
The problem is there from three days ago.
I install 508, then update to 509.
In an effort to resolve the problem of CIS 509 AV updates not working, can somebody that currently has AV updates working under 509 please supply me with the value of Version for the following 2 paths…
HKEY_LOCAL_MACHINE\SYSTEM\Software\Comodo\Firewall Pro\Configurations\0
HKEY_LOCAL_MACHINE\SYSTEM\Software\Comodo\Firewall Pro\Configurations\1
Thanks.
0 = 0x03016295 (50422421)
1 = 0x03016295 (50422421)
Yep, in all my 4 configs is the same version
[attachment deleted by admin]
And you guys have AV updates working under 509? If so, then this isn’t the problem (unfortunately).
One thing that I have confirmed is that when CIS says check your internet connection (implying that it’s not working), there have been communications between your system & Comodo’s servers. Thus the message generated by CIS isn’t correct in this implication. Something else is wrong.
Mine is working, I just update to 1170 half an hour ago.
And I have update CIS from beta to beta till 509, is not a clean install of 509.
I don’t know if this is relevant, but a while back there was problems updating Avira. In that case users had their host files hacked and were being redirected away from the real update servers.
I don’t have HOSTS file hacked.
CIS 509 stop updating from may 14.
Is possible to create a “CIS Registry Cleaner” for this problem? (erase ALL CIS orphan registry entries)
KAV has one.
NOD32 has one.
This can solve the f*** update problem for users that installed Beta/RC before 3.9 final.
I also check the HOSTS (which I don’t use) & just contains the default 127.0.0.1 - localhost entry.
I believe CIS updates were halted for CIS 3.9 RC’s on purpose by Comodo after some users experienced problems with the AV updates. For me, they’ve never worked since.
I don’t believe so. Well, not in my case anyway. I’ve not run CRC on my system that has this issue.
Looking at CAP (Packet Sniffer Captures) that I’ve generated during an AV update attempts, it seems very confusing. There are 404’s, 302’s (Moved Temporarily) & all sorts of responses as it attempts to find & download the CAV files. I don’t think these are a problem, it’s just the way Comodo distribute the AV updates for different geographical locations. It’s just very confusing to follow. But, it seems to encounter a problem downloading/finding BASE_UPD_END_USER_v1155.cav (ie. where it stops)… which is odd, since CIS seems to find & download 1158 to 1164 without issue. My network connection might be just too slow… but, I’m not sure. Still looking.
then… This problem can be a file name problem with BASE_UPD_END_USER_v1155.cav ?
Can any Comodo Staff member check this ?
After many tests CIS’s AV database update fails in exactly the same place every time.
GET /av/updates39/sigs/updates/BASE_UPD_END_USER_v1155.cav HTTP/1.0 Accept: */* User-Agent: COMODO Host: download.comodo.com Connection: Keep-Alive Pragma: no-cacheHTTP/1.1 404 Not Found
Server: nginx
Date: Mon, 18 May 2009 02:12:22 GMT
Content-Type: text/html
Content-Length: 162
Connection: Keep-Alive
This is what it should have done (based on the previous GET)…
GET /av/updates39/sigs/updates/BASE_UPD_END_USER_v1170.cav HTTP/1.0 Accept: */* User-Agent: COMODO Host: download.comodo.com Connection: Keep-Alive Pragma: no-cacheHTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Mon, 18 May 2009 02:12:22 GMT
Content-Type: text/html
Location: http://eu1.download.comodo.com/av/updates39/sigs/updates/BASE_UPD_END_USER_v1170.cav
Content-Length: 154
Connection: Keep-Alive
I’ve done all I can, it’s up to Comodo now.
edit: PM sent asking for assistance.
Hi all! I also have this problem. I tried to install local HTTP proxy server (HandyCache in my case) and change set it up in Comodo settings (Miscellanious\Settings, Proxy). After this the update is working. If turn the proxy setting off in Comodo, the update fails.
Hi Kail,
« Reply by Kail #35 on: Yesterday at 09:31:20 PM » Reply with quote Modify message Remove message Split Topic After many tests CIS's AV database update fails in exactly the same place every time.Quote
GET /av/updates39/sigs/updates/BASE_UPD_END_USER_v1155.cav HTTP/1.0
Accept: /
User-Agent: COMODO
Host: download.comodo.com
Connection: Keep-Alive
Pragma: no-cacheHTTP/1.1 404 Not Found
Server: nginx
Date: Mon, 18 May 2009 02:12:22 GMT
Content-Type: text/html
Content-Length: 162
Connection: Keep-AliveThis is what it should have done (based on the previous GET)…
Quote
GET /av/updates39/sigs/updates/BASE_UPD_END_USER_v1170.cav HTTP/1.0
Accept: /
User-Agent: COMODO
Host: download.comodo.com
Connection: Keep-Alive
Pragma: no-cacheHTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Mon, 18 May 2009 02:12:22 GMT
Content-Type: text/html
Location: http://eu1.download.comodo.com/av/updates39/sigs/updates/BASE_UPD_END_USER_v1170.cav
Content-Length: 154
Connection: Keep-AliveI’ve done all I can, it’s up to Comodo now.
edit: PM sent asking for assistance.
URL:
http://download.comodo.com/av/updates39/sigs/updates/BASE_UPD_END_USER_v1155.cav
is not expected to be hit by version CIS 3.8 or CIS 3.9
Let me give you a bit of explanation and then possibility of your copy hitting it:
- When you update from CIS 3.8 to CIS 3.9, you are expected to get base >=1157 and therefore URL 1155 should not be hit in this case.
- When you install CIS 3.9, you get version >=1157 and again you should not be hitting 1155
Only possibility i can see is that you had CIS 3.8 installed and it was on lower than 1155 version and you manually changed registry path to “av/updates39” and tried to update it, which should not be done.
Can you please help us understanding as:
- What version you have installed?
- Did you modify registry for “av/updates39”?
Thanks
-umesh
Hi umesh, thanks for your response.
All CIS updates were performed by CIS’s own update process.
My starting point was the 3.9 RC’s. During the RC-BETA testing, the AV updates were frozen/locked by Comodo due to BSOD issues relating AV updates. I was not impacted by this issue personally, but the AV was frozen at 1154 (any AV update attempt at this point, merely changed the update date).
Following the final 3.9 release, the AV database remained at 1154 & any AV update attempt failed as reported in this topic. Subsequently, due to a problem, there was a 2 phase 3.9 update (requiring a reboot in between each update). After this 2 phase update my CIS version was (and is) 3.9.95478.509 and the AV remained at 1154. At this point any AV update attempt failed (as reported above).
After a few days of AV update failures & following the creation of this topic, I started looking for a reason/solution. At this point the value of UpdatePath was “av/beta39” for all profiles. Yes, I did change UpdatePath to “av/updates39”… however, this had no impact & didn’t seem to alter what CIS’s AV update was doing. After checking with other Mods, I was informed that CIS no longer uses the UpdatePath & that it was now hardcoded into cmdagent.exe (?) - Egemen said this apparently. A quick bit of testing confirmed this, CIS does indeed seem to ignore UpdatePath… obviously invalid entries do not appear alter what CIS AV update does.
Based on what you’ve said about 1155… I think this could be the problem (excluding the proxy report above): Perhaps when CIS’s AV updates were intentionally frozen during RC testing, it was not taken into account what AV database version the user had at the time of the AV update freeze. The result being that some users, like myself, were left stranded on versions prior to 1155.
Yes Kail,
This explains. Although if you have RC version of CIS installed and you update now, it should update to latest CIS 3.9 with base >= 1157. For a short period of time, there could be possibility like you observed.
So this issue could be a possibility with RC/BETA users and not with end users. So this error can not be seen in general by end user who has upgraded from CIS 3.8 to CIS 3.9 or installed CIS 3.9.
Thanks
-umesh