Update slowed system to a crawl due to constant HDD access...

Had not updated for a while, and after doing so, the system became useless, as “system.exe” hogged the HDDs with constant enough access to get the HDD light to shine at halfstrength constantly.

Hardkilling the comodofiles(which now for some reason were many) did not help, but the second the uninstall was done, the constant HDD access causing the severe slowdown was gone. But getting to that point took over 2 agonising hours that was NOT in my plans for tonight.

Due to also previous annoyances over unneeded HDD r/w and slowdowns from cmdagent, for the time being i´m back with ZA again after almost a decade using CIS.
And the one time with CIS that i know i got hit with something nasty, hacked website doing code injection through .pdf file, CIS failed to prevent it from deleting and altering files in the “documents and settings” directory and messing with the registry.

So bye for now and hope you can get rid of the bugs.

System.exe does not belong to CIS.

This type of name has me suspicious. Please upload it to Virus Total to have it analysed. It could be a malware.

I´m well aware that it´s a basic part of Windows. And it´s just “System” in task manager, i´m just too used to core files using .exe that i wrote that out of habit.

Simple fact, it started low level constant use of HDDs when CIS was updated using the integrated updater, and the instant i managed to get CIS uninstalled, it stopped (it did not stop from using process explorer to kill all comodo files running). The kind of constant use that makes the HDD use light only shine at halfbright level(which i´ve never found out why as it does not normally happen).
HDD Sentinel was an easy way to confirm that there was HDD access and at what level.

I can also add to this now that the memory leak that caused one of the svchost.exe running to constantly increase in memory usage, no longer does so after CIS is gone. Or if it does, the rate of increase is drastically down since it´s still at just 21MB after a full days system ontime. Before switching firewall, it would have been somewhere 40-60MB by this time.

I was wondering about that.

Simple fact, it started low level constant use of HDDs when CIS was updated using the integrated updater, and the instant i managed to get CIS uninstalled,
Was the HD usage by CIS constant or only when updating? Your sentence is ambiguous.
it stopped (it did not stop from using process explorer to kill all comodo files running). The kind of constant use that makes the HDD use light only shine at halfbright level(which i´ve never found out why as it does not normally happen). HDD Sentinel was an easy way to confirm that there was HDD access and at what level.
Could you see what process was making System (stuff that runs in the kernel) was making the HD go crazy?
I can also add to this now that the memory leak that caused one of the svchost.exe running to constantly increase in memory usage, no longer does so after CIS is gone. Or if it does, the rate of increase is drastically down since it´s still at just 21MB after a full days system ontime. Before switching firewall, it would have been somewhere 40-60MB by this time.
CIS does not use svchost.exe nor are there processes running under svchost.exe for as far as I know. Only when running something in the sandbox or running Virtual Kiosk you will see two (or more) instances of svchost.exe run virtualised under cmdvirth.exe. Unless you're talking about virtualised svchost processes I am not inclined to believe CIS is involved in elevated memory usage by one of multiple svchost processes.

That being said. Sometimes left overs of previously installed security programs can cause all sorts of strange effects. Could you try running clean up tools for security programs you had installed in the past? Just to see if there is an influence of them or not. A list with such tools can be found here: ESET Knowledgebase .

The System process - as shown in CIS D+ Active Process List - is intimated to be PID 4. The thing called Windows Operating System is PID 0. In WinXP there are essentially three main processes: Windows Operating System, System & Explorer. The former spawns nothing - it is the gatekeeper for all resource access name items - and anything running is a spawn by the latter two. ANY other process that is not a decendent / spawn of the latter two processes, i.e., a parent, is highly suspect. I’ve found these usually to be orphan processes that descended from a parent that got killed, maybe died, or somebody maligned their repute in a nefarious fashion. If that process can’t be killed and restarted gracefully, i.e., w/ out repercussion to functionality, the system should be.

What I’ve seen on my WinXP SP3 system is that System process frequently consumes in excess of 50% CPU cycles with massive HDD activity after answering alerts ‘allow’ w/ ‘remember this’ checked for periods in excess of 10 - 15 seconds. That’s a deal breaker in its own right. There are other issues, e.g., moving rules around is nightmare. In v5.12 rules can be dragged lickety split. In v7.0 dragging rules is like dragging an engine block up 3 flights of stairs.

However, That being said, the issue is extant on a WinXP SP3 32-bit machine upgrading from v5.12 to v7.0 I wonder what happen if I do a clean install of v7.0.xxxxx If the HDD issue not resolve, then I’m going to attempt to clean install v6.3.xxxxxxx.last. And if that’s a no-dice go, then I’m back to v5.12.

Sincerely,

WxMan1
(Comodo Fanboi Extrordinair)
Don’t you be bad-mouthing my Comodo

Was the HD usage by CIS constant or only when updating? Your sentence is ambiguous.
After update was done, after windows reboot. After 2nd reboot with setting changes. After 3rd reboot with some more advanced fiddling.

At first i thought it was the scan initiated on update that was causing it and stopped that, but that merely reduced the slowdown a bit.

And my initial post said “after doing so” in regards to updating.

Could you see what process was making System (stuff that runs in the kernel) was making the HD go crazy?

The CIS files were the only ones with noticeable activity (by tracking I/O and cpu usage in task manager and by checking through process explorer).

explorer.exe had activity but beyond being slowed down by the overall system crawl it did not seem to do anything unusual.

CIS does not use svchost.exe nor are there processes running under svchost.exe for as far as I know. Only when running something in the sandbox or running Virtual Kiosk you will see two (or more) instances of svchost.exe run virtualised under cmdvirth.exe. Unless you're talking about virtualised svchost processes I am not inclined to believe CIS is involved in elevated memory usage by one of multiple svchost processes.

It´s a longtime infamous memory leak issue in XP that Microsoft in their almighty wisdom refused to fix properly. Try googling it, common problem, with no obvious or simple single fix. Worst case, the svchost will use up a cpu/core all by itself and/or increase memory usage up to what´s available in minutes.

In original installation of Win XP SP2, i managed to fix it well enough, then i was forced to update to SP3 however and the fix no longer works and the leak became annoying. Removal of CIS however made a drastic difference.

Since my opening post, that specific svchost.exe has gone from 21.9MB to 22.9MB. Before removing CIS it increased in size tens of MBs per day and would by now probably have been somewhere in the 100-200MB range.

So no, it´s not CIS by itself. But CIS was most certainly doing something that made the svchost leak turn itself up to “too much”.

That being said. Sometimes left overs of previously installed security programs can cause all sorts of strange effects. Could you try running clean up tools for security programs you had installed in the past?

This system did not have another security program installed before CIS.
Clean install together with Win XP installation on clean HDD.

Right now it has ZoneAlarm, but that will soon change again as someone there seems to have gone utterly incompetent and made it impossible to run Torrent software properly without the Pro version and even then it doesn´t seem to work well with anything like it(like Steams distributed download system).

Update.

Using “Private Firewall”, my system has now reached an on-time without reboot of 21 days, and there is still ZERO memory leakage.

Having tested the older version of Comodo as well as (shortly) ZoneAlarm again, i can now state that Comodo does have some sort of issue with memory leakage, ZA also has it but much less so, while PF does not.

(ZA of course is disqualified for any kind of real usage due to its sucktastic inability to handle a number of games and apps with the free version, and is ridiculously complex to manage them with even when you can)

As i would prefer using Comodo (PF interface has more than a little to improve), i wish/hope that you can do something about it.