cmdagent hogged 2700 kbps Internet Bandwidth - I only had 0.5 kbps left

Comodo Internet Security - CIS Install / Setup / Configuration Help - CIS
1

After deciding my P.C. was busted so bad it would never work again
( I knew cmdagent was stealing 100 % CPU but could not use Google to find out why )
I restored C:\ from an Acronis backup image and was relieved that the 100% CPU bug was removed.
(I had feared that a hardware defect might need repairing.)

I found the Internet was terribly slow and intermittent, and was unable to access any information about Internet problems.
I viewed the Firewall Internet Connections, and saw a few things listening, but nothing much happening.
I again feared that a hardware defect might need repairing.

I launched DigiGuide and it only knew the T.V. programmes scheduled one month ago. I told it to update and it bombed several times. Eventually it retrieved data and told me there was 2.3 MB to download, and then the progress bar showed spasmodic activity at around 500 bps on a 2.7 Mbps connection.

After half a day trying to recover from the 100% CPU overload, I then had a flaky Internet,
and suspected that perhaps the 100% CPU was due to damage caused by failure of “something” to safely roll-back a transaction that had been disrupted.

I had another look at Firewall Internet Connections and immediately saw that cmdagent was now hogging the entire Internet, and after about 1 hour it had downloaded 100 + MBytes, and then it was finished and the whole Internet was available, and the DigiGuide download jumped from 500 bps to 1 Mbps.
I then found that cmdagent had been downloading bases.cav.

I was happy with the expected installation delay when full download of bases.cav was followed by a system scan.
I am happy with the negligible delays that I have never noticed when a partial update occurs.
I am NOT happy with a totally unexpected full download delay using the entire Internet bandwidth for a full download when only a partial update is appropriate.

Will similar aggravation occur whenever the computer starts after a few weeks powered down ?

Was that aggravation due to the aftermath of the 100% CPU fiasco upon the Comodo servers.
Please note that my P.C. knew nothing of that fiasco after a BOOT CD restored on C:\ the previous Acronis image, though I suppose pagefile.sys and hiberfil.sys might have retained some “ancestral knowledge”.

Was that aggravation a consequence of Comodo disrupting CryptSvc and corrupting CatRoot2 etc. ?
I am also a victim of https://forums.comodo.com/empty-t45568.0.html;new;topicseen#new

Immediately after the Acronis image was restored to C:\ the event logs started at
07/10/2009 20:47:22 Event Source: EventLog Event ID: 6009
07/10/2009 20:47:22 Event Source: Security Event ID: 514
07/10/2009 21:02:24 Event Source: crypt32 Event ID: 7

There were 50 off crypt32 error events, each preceded by a crypt32 information event.
The first two were 20 seconds apart, but thereafter the information and error events were in the same second.
There were about 50 events in 25 pairs from 21:02:24 to 21:03:37
and another 50 events from 21:46:19 to 21:46:51.
I guess the sequence number needed less than one Internet packet and came quickly enough,
but the root list cab needed a lot more and horrendous internet delays caused a time-out and error and multiple retries.
I guess that may have been because Comodo wanted to validate the signature database it hoped to download.

The complete information for the first two crypt32 events is below.

Regards
Alan

Event Type: Information
Event Source: crypt32
Event Category: None
Event ID: 7
Date: 07/10/2009
Time: 21:02:24
User: N/A
Computer: ACER-311VPBCEH0
Description:
Successful auto update retrieval of third-party root list sequence number from: http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt

Event Type: Error
Event Source: crypt32
Event Category: None
Event ID: 3
Date: 07/10/2009
Time: 21:02:44
User: N/A
Computer: ACER-311VPBCEH0
Description:
Failed auto update retrieval of third-party root list cab from: http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab with error: This operation returned because the timeout period expired.

p.s. dberr.txt errors for 07/10/2009 were :-
CatalogDB: 20:48:17 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:48:20 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:48:31 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:48:32 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:57:48 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:58:01 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:58:03 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:02:19 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:03:19 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:03:23 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:03:37 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:42:45 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:47 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:48 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:49 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:50 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:51 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:51 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:51 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:51 07/10/2009: File #2 at line #1236 encountered error 0x00000057

2

It sounds like you put back an image that was made when CIS was freshly installed and had not updated the AV yet. Can you confirm that to me.

Will similar aggravation occur whenever the computer starts after a few weeks powered down ?
It has been noticed that CIS prior to v3.12 could take quite some resources when it has not been updated for more than a couple of days. However v 3.12 is much better behaved with regards to this
Was that aggravation due to the aftermath of the 100% CPU fiasco upon the Comodo servers. Please note that my P.C. knew nothing of that fiasco after a BOOT CD restored on C:\ the previous Acronis image, [color=orange]though I suppose pagefile.sys and hiberfil.sys might have retained some "ancestral knowledge".[/orange]

Was that aggravation a consequence of Comodo disrupting CryptSvc and corrupting CatRoot2 etc. ?
I am also a victim of https://forums.comodo.com/empty-t45568.0.html;new;topicseen#new

Immediately after the Acronis image was restored to C:\ the event logs started at
07/10/2009 20:47:22 Event Source: EventLog Event ID: 6009
07/10/2009 20:47:22 Event Source: Security Event ID: 514
07/10/2009 21:02:24 Event Source: crypt32 Event ID: 7

There were 50 off crypt32 error events, each preceded by a crypt32 information event.
The first two were 20 seconds apart, but thereafter the information and error events were in the same second.
There were about 50 events in 25 pairs from 21:02:24 to 21:03:37
and another 50 events from 21:46:19 to 21:46:51.
I guess the sequence number needed less than one Internet packet and came quickly enough,
but the root list cab needed a lot more and horrendous internet delays caused a time-out and error and multiple retries.
I guess that may have been because Comodo wanted to validate the signature database it hoped to download.

The complete information for the first two crypt32 events is below.

Regards
Alan

Event Type: Information
Event Source: crypt32
Event Category: None
Event ID: 7
Date: 07/10/2009
Time: 21:02:24
User: N/A
Computer: ACER-311VPBCEH0
Description:
Successful auto update retrieval of third-party root list sequence number from: http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt

Event Type: Error
Event Source: crypt32
Event Category: None
Event ID: 3
Date: 07/10/2009
Time: 21:02:44
User: N/A
Computer: ACER-311VPBCEH0
Description:
Failed auto update retrieval of third-party root list cab from: http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab with error: This operation returned because the timeout period expired.

p.s. dberr.txt errors for 07/10/2009 were :-
CatalogDB: 20:48:17 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:48:20 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:48:31 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:48:32 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:57:48 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:58:01 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 20:58:03 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:02:19 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:03:19 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:03:23 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:03:37 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:42:45 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:47 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:48 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:49 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:50 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:51 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:51 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:51 07/10/2009: File #2 at line #1236 encountered error 0x00000057
CatalogDB: 21:46:51 07/10/2009: File #2 at line #1236 encountered error 0x00000057

Like you already suggested there could be ancestral heritage from pagefile.sys and
hiberfile.sys that may have caused the CatalogDB errors. You could have checked that by disabling both paging and hibernation and rebooting and see what happens next.

For a bug report I see no attempt to present a reproducible bug or problem and also there are too many variables so I will move this to the help boards for now.

3

Actually, I’m experiencing quite the opposite! I never had the huge disk I/O issues or update lags until the 3.12 update… And it’s not just after long periods either. Just overnight.

4

No, the image was created 2 weeks after installation.

I used RevoUninstaller to remove ESET NOD32 and Comdo 3.5,
and then installed Comodo 3.10 on 1/8/2009, and updated to 3.11 on 29/08/2009
The Acronis image was captured on 14/09/2009
Almost all Comodo files are last modified on 29/08/2009, excepting for
C:\Program Files\COMODO\COMODO Internet Security\scanners\bases.cav 103,951KB at 14/09/2009
NB C:\Program Files\COMODO\COMODO Internet Security\repair\bases.cav 104,640 KB at 29/08/2009

My original draft stated :-
“Please note that my P.C. knew nothing of that fiasco after a BOOT CD restored on C:\ the previous Acronis image.”
That was and has been my attitude, but for the sake of pedantic accuracy before posting I appended
“, though I suppose pagefile.sys and hiberfil.sys might have retained some “ancestral knowledge”.”
I have always known that pagefil.sys and hiberfil.sys are NOT imaged by Acronis,
but I thought this was only of interest to forensic investigators.
I assumed that if the system hibernates then when woken up the O.S. would use hiberfil.sys to restore the contents of REAL RAM. and pagefile.sys would still have the contents of VIRTUAL RAM.
I assumed that after a proper shut-down and then reboot the O.S. would never read/use the stale contents of those files, but only read/use the locations it has written to AFTER the reboot.

Some time after 01/08/2009 I found 55 off *.MOF files had been added along with a few "Failed to Restore .NET Framework errors. I discovered all that after noticing the errors being appended to dberr.txt,
and I originally thought different symptoms of the same catalogDB problem when Comodo 3.5 was removed and purged. I have posted on various forums and had almost no answers. I can wait for Comodo’s dberr.txt error to be fixed, but I do not know if the 55 off *.MOF files are a ticking time bomb,
so I intend very soon to restore my old system as at 30/07/2009 and try to be more careful as I remove the old ESET and Comodo 3.5.
Is it actually possible that “ancestral knowledge” of the recent global disaster could affect the O.S. and catalogDB after I have reverted and updated my protection ?

I agree that it is not possible to reproduce my exact problem, but that is entirely the fault of Diagnostics.
Diagnostics should do more than say things are bad, it should say WHAT things are bad.

When I use CCleaner to clean the registry, it shows me what it would like to fix, and then I can let it fix it.
Some registry keys were not fixed because they were in use / related to other registry keys,
so now these other keys are removed those that were “in use” are no longer active and I clean the registry again - and again and again until there are no more to fix.
If however a key that has been “fixed” still needs fixing again, I immediately know it is no good repeating ineffective actions, and then I investigate further and consider altering permissions and taking ownership.
CCleaner would be far less useful if it was as non-informative as Comodo Diagnostics.

I propose to file a separate concise Bug Report on the need for Diagnostics to identify what it is fixing for the benefit of the user, and also so the developers can receive a detailed technical report upon anything which Diagnostics would like to fix.

I think it is unacceptable and worth a bug report if what is expected to be an un-noticeable signature update should instead hog 99.98% of the Internet bandwidth for most of 1 hour. I had lost the computer for most of the day to a 99% CPU load for no known reason, and having reverted and removed the 99% CPU burden I then had 0.02% of the Internet, which dropped out so bad I could not find out anything, and I had to phone my son to ask him to check upon any problems with my I.S.P. and the B.T. Internet infrastructure, and consider resetting my modem/router/Firewall interface back to default settings.
I think any fellow victim with only dial-up internet connection would have lost the internet for most of a week - perhaps we will hear from them next Wednesday ! ! !

Regards
Alan

5

And here I am, as if on cue. I’m not having exactly the same problems as Alan, even though my problems are concerning the same problematic process (cmdagent). By the way, congratulations on uninstalling NOD32 Alan, that’s a pretty bogus antivirus and I’ve tried almost all of them.
I came to the forums today, not because I have a slow dialup, I have a 3MPS cable connection, but alot of times it seems like it’s dialup, and when I look to see why it’s so S-L-O-W, cmdagent has 8 to 12 connections, all to different IP addresses, and all outbound. Let me interject here, I trust NO program that accesses the internet without my OK, completely. Microsoft, Panda Internet Security, and Zone alarm Pro are the reasons for my insecurity of my security. I was one of the first hit with the notorious ZA Trojan, the one that opened a window, informing you that an update was available for your zone alarm firewall, then downloaded the Trojan that shut down your antivirus and firewalls, and cut off online access to their sites. I called both Panda and Zone Alarm for help. Neither admitted there was a bug alive that would cause that. Both said re-install. I called Microsoft’s virus hotline. A Windows XP Specialist named Sandy told me, ““Nobody can access your computer unless you give them explicit permission to do so, re-install your Windows application””.
So, I have to ask, why does cmdagent access the internet without my permission, and use njumerous connections to various websites to do so, and even more important, why does it do so, when I have my firewall set to “block all connections”? Because I was looking for a secure connection when I put my money down for this one. Do I need to add Comodo to my growing list of untrustworthy security providers, which includes Panda, Zone Alarm, Eset NOD32, F-Secure, Kaspersky, Trend, Norton(of course), McAfee(of course), CA, and preceding my move to Comodo, A-Squared? And, let’s not forget my $1000 investment in a useless hardware firewal by Juniper, named Netscreen. If I forgot any names, I apologize, after 5 or 6 years of security failures, the names get lost.
So, how about a straight answer Comodo, you know your program, I guarantee that you know why my computer is acccessing the internet while I have it set to block all. Or, should I re-install Windows?

6

I have never had any problems like this with my comodo installs and I have run it for years. Something has to be corrupt (think driver), this is what I would do.

First download a fresh copy of Comodo 3.12 form here https://forums.comodo.com/feedbackcommentsannouncementsnews_cis/comodo_internet_security_312111745560_released-t45362.0.html;msg327510#msg327510

now download these programs and install them:

Revo uninstaller - Download Revo Uninstaller Freeware - Free and Full Download

CCleaner - Download

Eusing Registry cleaner - Eusing Free Registry Cleaner: Safely scan and repair registry problems - Spyware FREE.

First off start revo, select comodo and hit uninstall at the top, when prompted select Moderate for the uninstall mode. Once it has created a restore point and comodo’s uninstaller has run, DON’T RESTART WHEN PROMPTED.

Instead, hit next in the revo window, it will then scan for any leftover registry entries, once found hit select all and hit delete, then hit next.

Revo will now look for left over files, once again hit select and delete ot anything it finds. Hit finish and close revo. Now you can restart.

Once restarted start up CCleaner, using the software scan (analyze) for junk files and delete anything it finds. Once done, use the registry cleaner in CCleaner to scan for issues and remove anything it finds.

Close CCleaner and open Eusing (hit skip in the registration box).

Using the drop down menu at the top, select action → scan registry issue

Once done scanning hit action → Repair Registry Issue. Once repaired close eusing and restart the computer once more. You are now ready to reinstall comodo.

By doing it this way I have installed and reinstalled comodo a dozen times and have not had one problem with it.

7

OK. Can we please have the following facts;

  1. Are the addresses consistent?
  2. What are the addresses?
  3. Are there any relevant entries in the D+ logs for the outbound connections?

Cheers,
Ewen :slight_smile: