Hello
I noticed that sometimes my Windows 7 running CIS is using the hard disks so much that the computer becomes very unresponsive.
Resource Monitor shows a process from Comodo named cavwp.exe performing heavy disk access:
http://postimg.org/image/3qojcgzl5/
Does someone know what that application does, and whether it can be shut down?
Thank you.
Hi littlebigman,
The cavwp.exe process is for Antivirus scans, one instance of this process is dedicated to real time scanning.
What are all different processes in CIS V6/V7?
High disk activity could be caused by a scheduled scan, try disabling any scheduled scans.
Kind regards.
Thanks. I checked, but it’s not due to scheduled scanning.
It looks like cavwp.exe starts every time a file is accessed, which makes sense when having “Realtime protection” enabled.
It’s just that it makes the computer unresponsive.
Do you have any other real time security programs active?
Is the real time scanning set to ‘Stateful’ (Enable scanning optimizations)?
Real-time Scanner Settings
CAV should not be causing system lag or unresponsiveness without some other factor involved.
If no other factor is evident, maybe you have found a bug that shows with specific systems.
Thanks.
Yes, I left both options checked in “Realtime Scan”.
I’ll check if I can gather more information.
Thank you.
I have the exactly same problem with comodo 7.0.317799 on XP SP3.
cavwp.exe “randomly” appears in the process accessing some cav file in “…\COMODO Internet Security\scanners” even if antivirus is completely disabled. Scanning optimizations is enabled. I tried to disable “Run cache builder when computer is idle” to no avail. No scanning task scheduled. Every time cavwp.exe come up, it freezes my computer due to excessive disk access that “never” ends (I was never be able to wait more than 30 min in this situation). I had to kill it with comodo killswitch. The only workaround I use now is to forbid cavwp.exe to access disk in comodo ISP rule. Now cavwp.exe is blocked and doesn’t get stuck in process and my computer can breathe again.
edit: My bad, a full scan was scheduled twice a week: sunday & thursday at 11:59pm (default) but I think cavwp.exe showed up every single night. Anyway, scheduled tasks are now disabled & I removed the HIPS rule that blocked cavwp.exe. We’ll see what happens.
That’s the problem with closed-source software. No one knows what’s going on under the hood.
Cache builder when running, I assume it still does this, does not throttle back when other programs need foreground. That can interfere with system performance.
Littlebigman. Next time it happens can you see if cache builder is running with the CIS Task Manager? Or check with the log files.
AFAIU ‘cache builder’ is of maximum utility when AV is configured in ‘on access’, otherwise its of margarine value. Moroever, once the cache building thing-majingy starts, it can take quite a while for the thng-majingy cache builder to realize it aint the top nut on the fruit cake anymore.
AV stateful [sic] security level constrains malwre analysis for those files that haven’t been analysed since the last AV defs update and only for those files actually loaded into memory. Files not actually loaded, .e.g, copied, or dir list item, will not incur the AV overhead of scanning.
AV on access security level has not that constraint; files are scanned each and every time they’re accessed for even the slightest purpose, e.g., dir listing. In this case the cache builded by the cache builder is consulted first; if item is in the cache the hash is used as benchmark against a hash computed each time the file is accessed.
From the perspective of hash calculation, stateful [sic] might benefit somewhat; after AV def DB is updated and the builded cache is still extant, the system prolly just calcs a hash and comparisonates it with the entry in the builded cache instead of going all malware check-gonzo on the file.
My feelings on all that are based on a thread I read about complaints by people who claim unrecognized files can’t be submitted to the cloud for scanning cause unrecognized files are prohibited to the interwebs.
I guess it boils down to how often the CPU encounters ‘new’ files in any given session betwixt AV def DB updates.