Comodo doesnt block executable process EVEN WITH HIPS block rule [M1007]

A. THE BUG/ISSUE (Varies from issue to issue)

  • Summary - Give a clear summary in the topic subject, NOT here.
  • Can U reproduce the problem & if so how reliably?:
    Every time.
  • If U can, exact steps to reproduce. If not, exactly what U did & what happened:
    1:Disable autosandbox so that only the HIPS is running under Defense+
    2:Create a custom ruleset, called “Blocked Application”, which has all possible actions set to Blocked.
    3:Apply this “Blocked Application” rule to mediaplayer exe + mediaplayer setup
    4:Double click a movie file which is associated with mediaplayer.
    5:Check task manager, next to cavwp.exe you will see mediaplayer exe running.
    6:If you check the Defense+ logs you will see some blocked events regarding mediaplayer, although the process was allowed to run
  • If not obvious, what U expected to happen:
    I expected that if a rule is made to block it that it will not even be able to have a process running.
  • If a software compatibility problem have U tried the conflict FAQ?:
  • Any software except CIS/OS involved? If so - name, & exact version:
    Windows 7 64 bit mediaplayer
  • Any other information, eg your guess at the cause, how U tried to fix it etc:
    I noticed that this process runs under the same svchost as comodo av does. This seems very unusual to me.
    In older versions of CIS creating a block rule like this for the HIPS prevented the process from running.
    Backpack process ignores block rules


  • Exact CIS version & configuration:
    CIS version 7.0.317799.4142
  • Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:
    Firewall=custom mode, Defense+=proactive, save mode, autosandbox disabled
  • Have U made any other changes to the default config? (egs here.):
    All on high and secure
  • Have U updated (without uninstall) from CIS 5 or CIS6?:
    No, this was a clean install
    [list type=lower-alpha][li]if so, have U tried a a clean reinstall - if not please do?:
    [/li]- Have U imported a config from a previous version of CIS:
    [li]if so, have U tried a standard config - if not please do:
    [/li]- OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
    Windows 7 64bit, not a virtual machine
  • Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:
    a=none b=?none

[attachment deleted by admin]

Can you please provide step-by-step numbered instructions which can be used to replicate this (including links)?


Okay, I’m not sure why it is able to run. I assume it is not able to actually start any files, but I’m not sure why it would be allowed to run at all.

In order to forward this to the devs please edit your first post so that it is in the format required here.
Also, please attach a diagnostics report, a KillSwitch process list, and your current configuration to your first post.

Please let me know if you have any questions.


Can you reproduce it?

I have not tried as I do not currently have the time for testing.

However, I’m wondering whether this is a bug or intended behavior. Is it normal for a process to be allowed to run itself if there is a block rule? If it is then I would expect that the process would not be able to do anything, meaning perform any of the actions defined on this page. Does it seem that the process is able to do this?

If you think it is, or are not sure, then I think it’s best to format the first page and I can submit this to the devs for consideration. The worst they can say is that this is intended behavior.


Intended that a totally blocked thing is able to run?

Well, comodo is default allow then.
This looks like a backpack process problem.

I will put the 8 steps in my first post.
Thats how you can reproduce it.

I just meant that I wasn’t sure what was intended. I do not use the HIPS component anymore.

Please edit your first post so that it is in the required format and I will forward this issue to the devs for consideration. Let me know if you have any questions.


Thank you for providing this. I edited the first post to include this information, and made some small changes. Please look over the first post and let me know if everything seems okay.

If it does then please create and attach a diagnostics report to your first post. In addition to this please attach an exported configuration.

Let me know if you have any questions.


Thanks a lot for your post on this “eventual” issue with comodo 7 …422,

I’m wondering about updating for a long time now,
and you said that older versions are able to block files as you set the rule for it…

I’ll wait to know more about this and if it’s confirmed or not.

thank’s a lot again.

I’m sorry I can’t help by testing it also, my comodo FW are 5.12 on all my machines and i got no more HDDs with enough space to run a virtual machine.

All there.

Thanks. In that case please attach the configuration file and the diagnostics report to your first post. Once those are attached I can forward this to the devs for consideration.

Thank you.

You can reproduce it with all the infos i gave.
I dont send my config or diagnostics.

Please send it to me via PM and I will post it in the tracker where forum members cannot see it. The reason for this is that if it turns out to be more complicated than it currently seems (which I have seen happen many times) I would rather not introduce any unnecessary delays.

Thank you.

I am using comodo since version 3.
With paranoid mode or with safe mode. So i know what i am doing.

I can reproduce it with the steps i gave.

In that case I will forward this to the devs as-is, acting under the assumption that this is likely replicable without that information (which I believe is likely for this issue). However, I have mentioned in the tracker that if the config file or the diagnostics report does turn out to be needed for replication that you would be able to supply it to them upon request.

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Many thanks again.

Could you add one
to the first post?

I cant modify the post anymore.

NOTE: If the default predefined rule “isolated application” doesnt show this effect,
create a predefined rule with the name “blocked application”. And set all as blocked.
(I create this rule, because the name “isolated” doesnt fit.)

Do you mean that if the devs try to replicate this by using the predefined rule “isolated application” and it does not replicate that they should manually create a new rule called “blocked application” (which has every possible action has been chosen to be blocked) and apply that to the application?

If so, do you mean that this does not replicate on your computer if you use isolated?


I triple checked that the created rule has all on blocked.
So its equal to the isolated rule.

Just to add an additional point to look at. To have all possibilities mentioned.
“Creating a block predefined rule”.

The rule set MUST block everything. As all markers are set to block.
And as it actually did in the past.

I have edited the steps for reproduction in the first post. Please look them over and let me know if they now adequately reflect how to replicate this issue.

Better say custom predefined rule.

But as this rule is the same as isolated application, it should be tested with the default predefined rule isolated application as well.

As both should block.