D+ exclision and trusted files lists do nothing at all

I am trying to install some ruby gems on my system and D+ is being very annoying. The gems installer creates a number of temp apps called conftest.exe These are to test various stages of the installation and make sure they have been successful. This means that the file conftest changes several times durring the installation. Comodo sandboxes these files when they are run and the installation fails, which is more or less what Comodo should be doing. As a workaround, I put the directory where conftest.exe is being created in the exclusions list, but this does nothing, conftest.exe is still sandboxed when it runs. What is the point of having an exclusions list if it does nothing to change the behavior of D+?

I also tried adding conftest.exe and the parent folder to my trusted files using the filename instead of the hash. This also does nothing and conftest.exe is still sandboxed. I just don’t understand why CIS ignores my settings. If I say that a file is trusted and I want it to run, then why won’t CIS let it run. If the software just does what it wants and ignores my settings, it really isn’t very useful. A software application you have to turn off all the time just to perform normal operations is an application that may as well not be installed in the first place.


In moments like these i find it more userfriendly to have no “userfriendly” auto-sandbox.

I dont use the sandbox.
When i want to install something it looks like this:

Explorer exe tries to run gamesetup exe. I press OK.
Gamesetup exe tries to do something. I choose “treat as installer or updater”.


The sandbox`s aim is to avoid questions while having a protection. Each new file will be put in it. If a program generates “new” files each time, the auto-sandbox is a problem.
If you dont have a problem to answer two questions, defense+ alone is the most userfriendly :slight_smile:

The only exclusion list in Defense+ is to exclude an application from Buffer Overflow Protection. This doesn’t mean that D+ will ignore these files.

The Trusted Files list does work, but as you’ve noticed, the temporary files are not trusted. Trusting by file name instead of hash will not work either for the same reason.

As Clockwork mentioned, really your best option is to apply the Installer or Updater predefined policy to the installer. That is after all, its intended purpose.

Exactly what does CIS consider to be a temporary program? None of these programs would be in a temp directory. Running a install bundle in ruby causes ruby to check and make sure that all the necessary dependencies (gems) have been installed. If it finds something that is not there, it installs it. Some of the installed gems are actually compiled an built on your system and then test apps are run to make sure that everything built works properly. Unfortunately, this is not as simple as running a single .exe installer and dealing with resulting CIS messages. The bundle I just ran probably involved 20 different .exe files. All of these files were in,


and it’s sub directories. It seems like adding C:\cygwin\lib\ruby\gems\1.9.1\gems\kgio-2.7.4* to trusted files without the hash should have worked. I’m not sure how CIS would find these to be temp files instead of any other kind of binary.

I really think that an exclusion/ignore list for D+ is essential, as it is for AV. I am an engineer and I program allot of software. Every time I try to compile new software, I have to deal with D+ preventing it from running when I test it. I move it to trusted, make a change, re-compile, and it gets bounced again. I add it to trusted files without the hash, but then I make a new app and have to start all over again. I am not worried about applications I wrote myself preforming malicious actions on my system and I really don’t see why I can’t tell CIS to ignore them. I also know I am not the only programmer who has complained about this. There really should be a way to say, “don’t pay any attention to anything in this directory”, like you can with an ignore list for AV.

Perhaps it would make sense to password protect such a function, or limit the number and location of such directories, but CIS would be much more usable for programmers if this feature was added. Security software is not very useful if you have to turn it off to perform the most common tasks you use your system for. I have D+ disabled more than enabled, which makes the feature rather pointless.

I’m not sure how to configure CIS to get this behavior. I run “bundle install” (from a cygwin bash command line), and many things happen. I get a CIS popup saying that such and such .exe is unrecognized and was run in a sandbox as limited. There is no opportunity to say, run as installer, etc. I am not running these apps by starting them from explorer, they are being called out of scripts and things like that.


Disable the sandbox.
Defense+ in safe mode.
Answer defense+ questions (1 or 2). Understand the question window and its buttons and checkmarks.
Have control, do what you want.

By temporary, I was commenting on the fact that the application builds these components to test other components with. Any .bat files or similar that have a one-time purpose I would consider temporary.

You can more or less exclude an entire directory if you wish. Create a new file group and add that folder. Give this file group the Installer or Updater security policy. Now everything that happens in that particular folder is given the highest level of access possible with D+.

This is what I do for .exe’s that I compile. As you’ve mentioned, I’m definitely not worried about the security of the applications that I compile, so I do my testing/compiling within that folder and D+ doesn’t complain about any of them.

I’m having a similar issue. I’m trying to compile in MPLabX and it generates randomly named batch files for the job. I cannot for the life of me figure out how to either track down the exact EXE that creates the batch files or how to mark all of the compiler files as an “Installer” to let me compile without popups.

You need to give the compiler the Installer/Updater policy not the files it produces. That way all the files it creates will be trusted and you won’t be asked.

That’s what I’m saying. I don’t know how to. I can’t find an up to date/legible explanation anywhere.

EDIT: Sorry, I see I was being unclear. By “Compiler files” I mean all of the EXEs in the BIN folder of the compiler’s install directory.

You can add the rule under Defense + Rules.

When the rule is made see if there is a rule in D+ rules called “All Applications”. The rule for your compiler is probably at a place under the “All Application” rules. When it is there drag and drop it to a place above the “All Applications” rule. Then Apply and Ok your way back to the main screen.

THIS DOES NOT flipping* EXIST! I’ve spent almost a week looking over things and being told to go to D+ Settings. Neither the link you posted nor anything I can find shows such a thing. Apparently Comodo has released a GUI change recently and I’m the only one in the whole ■■■■ world who got it.

I see this http://imgur.com/GIyPT and this http://imgur.com/kMmCg, that is all.

You are on v6. The second image shows the place to be Defense + Rules. Almost at the bottom of the list of rules on the right side there is button with an arrow pointing up. Click on it and options will be shown. Choose Add and go from there.

When done make sure the new rule is somewhere above the “All Applications” rule.