Blocks its own Secure Shopping csssrv64.exe

I’ve noticed it occasionally.

Latest Comodo. Windows 7 x64.

You need to be more specific by what you mean by blocking and you have to check the logs.

It was blocked by the Firewall module. Sorry, forgot to include that imperative bit of information. It happens every week or so. Since the upgrade to v12. If you need any more information, please state what additional information is required, specifically.

Hi Bucic,

Could you please check your Inbox for private message and provide the requested logs.

Did you look at and click at Blocked Applications in the main screen of CIS? That is not the most informative function. Could you look at the HIPS and/or Containment logs? They precisely report the event. That is the information we need. Could you post a screenshot of the logs here?

I find the Blocked Applications function useless. It is not precise enough sending users on a wild goose chase.

I’ve PM-ed an auto-generated log pack (from cisreporttool.exe) to Mathi R.

I would also like to add that CIS started to block all kinds of valid stuff on my system. Steam, nVidia updater, multiple own CIS modules (blocked by firewall), ArmA3.exe. It got bad since the spring and it’s getting worse.

Probably legitimate blocking of interprocess memory access of CIS processes, you can ignore it as it is part of self protection of HIPS blocking applications trying to access memory of CIS. The firewall blocking can be caused by rules set to block, so you need to make sure your rules are set correctly. Again without seeing the actual blocked events in the log it can’t be determined the cause of the blocking.

Bucic, could you post a screenshot of the HIPS logs showing what was blocked? It is most likely what futuretech thinks it is. Only the HIPS logs show the exact nature of what was blocked. Without knowing what is in the HIPS logs there is no way of knowing if we are looking at a legitimate action or not.

Blocked Applications will also log when CIS is blocking interprocess memory access to its processes. This is a regular act and part of the self protection of CIS. Blocked Applications will log this. This will create confusion because users may think something is wrong where CIS is simply doing what it is supposed to do.

Please post a screenshot of the HIPS logs.

I’m a bit confused here. I’ve uploaded a 15 MB worth of diagnostics data generated by the official tool and you still need screenshots? :smiley: OK, OK. I’m going to upload some shots in 8 to 24 hours.

Hi Bucic,

Thanks for providing the log, our developers are working on it.

We are usually not in contact with Comodo Staff only on an incidental basis hence why we ask for HIPS logs to learn more about what is happening. That way you and other users may learn what is going on. Blocked Applications as a concept is not thought through enough and tends to create confusion or make users think CIS is at fault.

Staff people do a wonderful job acquiring information for Comodo but their interventions disrupt the course of topics.

It is important that topics related to Blocked Applications reflect the discrepancies between the HIPS logs which log extensively and the logs created by Blocked Applications which informative value is limited. People will then understand the limited value of using Blocked Applications and how it can confuse them.

I am looking forward to see the logs.

I see. I wasn’t being grumpy or anything, it was a genuine question.

Here are the screenshots.
https://1drv.ms/f/s!AvyUQyNGJs9mkdt-WNIQcs-tg92NIg
Yes, in the last 24 hours or so I used Silent Mode extensively plus lots of disabled modules but believe me - I’ve witnessed what I’m reporting in a clean comodo configuration, no Silent Mode, no modules disabled.

EDIT:
More shots added. There should be 15 in total as of now. I’ve included some shots from settings. Rules, other areas of interest. I barely customized anything and I believe close to 100% of my rules were created via answering the default popups that CIS generates.

Thank you for the logs. The HIPS logs show interprocess memory access to CIS files getting blocked. That is normal, it is CIS protecting its self. Not getting interprocess memory does not influence functionality of programs; only in very rare cases it breaks the functionality of a program.

In this case there is not a problem with the blocking. Blocked Applications however shows the blocks and offer the possibility to unblock. First of all users may get worried because a legit program apparently gets blocked. Then Blocked Applications offers to unblock but in the case of interprocess memory access it is not capable of providing that. That can only be done manually and deeper in the UI.

So basically it’s a usability issue… OK. Speaking of which. Is there an active thread somewhere on moving away from the main philosophy of COMOD user experience, i.e. “let’s expose every single module to the user, separately, and force him to play a tag game”?

Could you elaborate on what you mean with “let’s expose every single module to the user, separately, and force him to play a tag game”?

It all boils down to lack of “app X needs to do its thing” option. Or “it’s like you had 4 secuirity software suits and COMOD is a provider of a common GUI”.
In a popup scenario:
Each CIS module may issue its own questionaire in the form of a set of popups.
In a “I need to make sure CIS knows not to block app X” scenario:
The user often has to go over several CIS modules creating rules in each and every one of them, then go on a testing venture.

Again, I’m not being grumpy here. I use Comod products since it was solely a firewall-only solution (2007?). While I welcome CIS no longer issues an avalanche of popup questions no sane non-professional computer user would be able to answer, I think CIS usability still suffer from the “each CIS module is a separate entity” philosophy.

The firewall blocking is already submitted as a bug which happens at system startup the firewall blocks outgoing connections even of trusted applications. As for the HIPS blocking, those are normal as CIS does not allow other applications except a few selected applications to access its memory. If you want to give access to other applications so you don’t get the constant blocking in the log then you need to edit the HIPS rule for the Comodo Internet Security file group as described in this post.

The user often has to go over several CIS modules creating rules in each and every one of them, then go on a testing venture.
Or just edit the file rating in the file list by changing it to trusted, all modules depend on the file rating, if it is trusted it won't be blocked under normal circumstances, the only other time special rules are need is when that application wants to access a CIS process in memory.

I see. It’s good I can just ignore those. I’m fine with that. No need for rules fiddling. It’s just that I though CIS is actually impairing operation of its own components.

A rating of a file? Do you mean a rating of an application executable, e.g. Steam.exe?

I changed my mind… CIS changed my mind. I am sick and tired of the false blocked applications counters every #% time I run any selfupdating program. I’d like to supress those but the post you linked is not helpful at all. Even if we assume it’s in English, I don’t think it contains the information on how to get rid of {the inrerprocess memory acces to comodo} alerts altogether i.e. for any application. Without it the “Blocked applications” section is useless and it’s dearly needed given how triggerhappy CIS is.

You don’t want to get rid off the interprocess memory access alerts to Comodo. You’re witnessing the self protection of CIS at work. We don’t advice to allow memory access by application to CIS unless a program does not function without it (it would be a case of a badly coded application though). The Blocked Applications dialogue as has been stated multiple times before is poorly thought through and is not something to rely upon.