Diff. in Comodo HIPS behaviour for Safe Applications with / without HIPS rules

Difference in Comodo HIPS behaviour for Safe Applications with / without HIPS rules

Comodo Free FW
Avast Free AV 18.7.2354

I have used SpywareBlaster ( SpywareBlaster® | Prevent spyware and malware. Free download. ) for many years and it still gets periodic protection updates. Although I guess it may well be that the protection it affords is already covered in other ways these days.

So, a couple of weeks ago I went to temporarily disable (unload) the SpywareBlaster protection and it took an absolute age to complete (around 10 minutes). Likewise re-enabling took ages. I noticed at the time that cavwp.exe was using high CPU.

Yesterday I booted up my laptop and had same issue (and so not a one off on my desktop). As the lappie is less powerful, cavwp.exe was hitting around 50% CPU all the while SpywareBlaster.exe was running (i.e. whilst unloading / loading protection).

I realised straight away that the cause was likely be some interaction between SpywareBlaster and Comodo (and that something had changed in recent weeks to cause the recent change in behaviour– maybe Chrome, IE11, Windows registry protection, Comodo itself ? [very recently I updated the Comodo software to the latest – previous program update was done in Feb 2019]).

As I have Comodo set up to create rules for Safe Applications in the FW and SpywareBlaster.exe was already there with appropriate access allowed, I looked at HIPS.

HIPS was set to not create rules for safe applications. CLARIFICATION: both FW and HIPS set to SAFE MODE

So I set HIPS to create rules for safe applications. Instantly SpywareBlaster.exe zoomed through (both loading and unloading protection) and cavwp.exe CPU was hardly noticeable. On checking, there was then a set of HIPS rules for SpywareBlaster.exe (see two attached images for details).

So I then changed HIPS back to not create rules for safe applications and removed the HIPS rules for the few other extra safe applications that had also been added whilst create rules had been enabled.

So, now all fine (with HIPS rules that had been created for SpywareBlaster.exe)

It is worth noting that (both with and without create HIPS rules enabled), when SpywareBlaster.exe was running, Comodo did not log anything pertinent to it (other than the creation of the HIPS rules themselves).

QUESTION 1: So my main my question is this:- Why would Comodo perform markedly differently (as evidenced by the high cavwp.exe CPU) for a safe application without HIPS rules created versus the same safe application with HIPS rules created?

QUESTION 2: Furthermore, it begs the question as to what other safe applications might benefit from having HIPS rules to minimise cavwp.exe CPU?

Appreciate any input.

Rgds, eBatch

Further investigation has identified that the behaviour I have seen arises from a change in Comodo (since version, which was the previous version that I had installed).

I restored a system image from just before I updated Comodo to The high CPU behaviour of cavwp.exe as reported did not exist then. I then updated Comodo software in a controlled manner (i.e. so that nothing else would have been likely to change whilst Comodo updated). Immediately after Comodo update, cavwp.exe high CPU kicked in.

Whilst I appreciate that the allowing Comodo to create HIPS rules for SpywareBlaster has circumvented the immediate high CPU issue, there is still cause for concern. Given that NOT creating HIPS rules for Safe Applications is the default scenario I have worked under the reasonable assumption that (in the alternative scenario of creating rules for Safe Applications) rules automatically created would reflect the exact same permissions / restrictions that Comodo would apply in the default scenario and that it would therefore follow that the Comodo processing would be the same in both scenarios (other than checking the rules for the software vs whether the software is deemed a Safe Application, which I would have though would be a trivial difference in the overall scheme of things).

So, the question remains as to why cavwp.exe is so highly active when rules do not exist for a safe application, but allowing Comodo to create rules for that very same application knocks the high CPU on the head.

I would also add that I’ve now observed similar cavwp.exe high CPU issues in conjunction with at least one other program (Macrium Reflect). In this case the high CPU is relatively short lived (for example, at the beginning of and at the end of creating a partition image). Once again, allowing Comodo to create rules for safe applications “side-steps” the high CPU.

I have to say that I really don’t wish to end up going down the path of allowing Comodo to create HIPS rules for all safe applications and I do think that this whole issue is something Comodo should look into.

Thank you for reporting, we are checking this issue.