I develop Windows Open Source programs on my PC with CIS installed. Obviously, every time I make a change and recompile a program, it looks different to CIS and it isolates it and I have to quickly click on “Do not isolate next time” - but as soon as I recompile it - it does it again!
Is there any way I can tell it to ignore all particular programs (e.g. ‘xyz.exe’) in a particular directory (e.g. “D:\Development\VC”) and its subdirectories (as I may have multiple versions under development at any time)?
Yes, CIS drops the ball in situations like this… :-\
Trusted status becomes moot if the application has changed, and creating a path based exclusion in the AV doesn’t do the trick either.
Currently, the roundabout solution to get CIS to leave files that are frequently updated alone is to change the applications security policy to Installer or Updater.
This might not be the right place to ask this but when I scan with malwarebytes and superantispyware defense + says it has blocked 2 intrusions. What do I need to do to not get them blocked ?
You should always disable your realtime AV scanner when running scans from another product. Otherwise the realtime scanner is trying to scan every file the other product is trying to scan, which can cause problems.
To continue my original post, I now find that my latest project won’t even build with Visual Studio because of Comodo! This project has assembler code as well as C code and the way VS2010 seems to cope with this is to create a temporary command file to run the assembler. This temporary command file has a different randomly generated name each time and always fails - until I turn off Defense+. Similarly, the VS project has pre and post build scripts that AV takes exception to.
So now - I have to turn off AV to run my programs that I am developing/supporting and I have to turn off AV and Defense+ in order to build them!!!
I am not happy >:(
Whilst I really like Comodo Internet Security for normal usage - it is a real pain for anyone developing applications!
I wish that they would provide some way to solve this without compromising the protection it provides - like allowing the user to designate secure directories to ignore checking each program being run from there (that would probably solve the pre & post-build scripts and often changing executables each time they are re-built to test). I am not sure how to solve the VS2010 approach to assembler code (I don’t think I can force the generated temporary command file to be in the same directory structure).
Thank you re: comment about compilers - except that it didn’t work. I have set the Installer/Updater policy for the VS2010 assemblers (ml.exe and ml64.exe) but I do not know which executable generates the randomly named command file by the IDE that then executes it and fails (sandboxed). So no luck there. The standard C compiler does work - just not if the project has assembler modules too.
Unfortunately, the number of possible executables, DLLs and scripts in the VS2010 directory and sub-directories make it too onerous to follow the workarounds described in your link and may not apply anyway as Comodo says that the command file has been sandboxed (the link refers to items that seem not to be sandboxed). I tried adding the whole VS2010 directory to Trusted files as per this link but, as it seemed to be adding every single file [even non-executables] I aborted it.
Thanks for continuing coming up with ideas but, unfortunately, VS2010 seems to create them in my temporary directory (C:\Users<username>\AppData\Local\Temp) and I really don’t think that this is a good candidate to be made Trusted!
After much discussion with the MS Visual Studio Team (and raising two bug reports in related areas!), by changing the assembling of these source members from “MS Assembler” to “Custom Build”, I have managed to bypass the use of the temporary directory completely and so bypassed this issue.
