I have recently installed/upgraded to Comodo 3.0 (188.8.131.525), and ma having some issues getting large Visual Studion solutions to build properly. I am now receiving a number of “Access Denied” or “File in use by another process” error messages that cause my builds to fail. I have an extremely large number of files releating to VS.NET in my Pending Files list. These files include my compiled assemblies, compiled assemblies that are dependents of other compiled assemblies (copy local setting is active), assemblies in the ASP.NET Temporary Files folders (from web services in the solution) and sattelite assemblies compiled as part of the process of creating localized resource assemblies. Basically, my solutions will not compile at all, now that I have moved to CFP 3.0. I have considered going through my pending files list, and moving most of these files to My Safe Applications, but this is an extremely large number of files to deal with. I have also consiidered adding some of these folders to the Trusted Applications Protected Files/Folders list, but I do not want to open myself to other intrusions. Also, some of these files are generated with temporary filenames, so the filenames and folder names may be different for every build. What is the best way for me to handle this situation, and configure CFP to allow my builds to work?
The latest version of the firewall is 184.108.40.2069.
Bugs have been fixed with each succeeding version of the firewall.
I would be tempted to uninstall 220.127.116.115 and install the latest version, in the hopes that some of your issues have been addressed.
I guess it is good to upgrade to latest 3.0.21 first of all, like MikeH suggested.
Use train w/safe mode or paranoid mode instead of clean pc mode if you do not want to deal with pending files.
As for your builds, the best way to deal with situation is to use wildcard characters for folders, which contain your builds, e. g. c:\my_builds*, d:\my_builds*. Declare these folders as “windows sys apps” and you will not receive alerts.
User reported recently that it is possible to use wildcard characters in such way: x:\temp*somephrase*.ext (related link).
You can also find out other useful combinations, as CFP supports many of them, thus it is flexible.
Thanks for the tips. I have upgraded to the latest version, and I have tried switching to Train with Safe Mode, and that seems to help. I will run with that setting, until I can start working on the temp files and build location wildcards. I do have another issue, which is caused by the code obfuscator I use (Preemptive Solutions Dotfuscator). This product uses a custom VS.NET project that dissassebles the build output assemblies, modifies the disassembled output and then recompiles the modified output into obfuscated assemblies. It does this by creating temp folder in the “Documents and Settings<CURRENTUSER>\Local Settings\Temp” folder. These folders have random names. I am getting a specific error with ildasm.exe and the files being created in these random temp folders. One thing I am trying to avoid is opening a hole in my defenses by allowing certain “special” situations that may be possible to exploit.
Do they have some phrase in common in title? What are executables from these folders? i. e. do they have something in common in title?
So is Defense+ culprit (i.e. error happens because d+ stops some executable by alert and this executable fails due to this)?
Here is the error message I get in the build output from VS.NET.
START OF ERROR OUTPUT*************
Running C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\bin\ildasm.exe /OUT=“C:_Projects\IS2BE\setup\IS2BE_Dotfuscator\Dotfuscator Debug\Dotfuscator_Temp_Files~IS2BE.L.1\IS2BE.Logger.dll.il” /TEXT /NOBAR /RAWEH /QUOTEALLNAMES /UTF8 /LINENUM C:_Projects\IS2BE_China\IS2BE_Logger\bin\IS2BE.Logger.dll
There was an error starting ildasm: Access is denied
System.ApplicationException: There was an error starting ildasm: Access is denied —> System.ComponentModel.Win32Exception: Access is denied
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at kh.a(b0 A_0, String A_1)
— End of inner exception stack trace —
at kh.a(b0 A_0, String A_1)
at d6.a(b0 A_0, Hashtable A_1, ap A_2, String A_3)
at d6.a(b0 A_0)
IS2BE_Dotfuscator build failed.
END OF ERROR OUTPUT*************
I have C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\bin\ildasm.exe configured as a Windows System Application. I have devenv.exe (VS.NET 2003) configured as a Windosw System Application. The folders have the following common naming (~IS2BE.L.1) where the .L.1 portion is random. I tried adding the following directory to the Windows System Application group using the folowing two paths. Each time the build failed…
The culprit is D+, because I can disable D+, and the build works. Any insight is greatly appreciated. Thanks
It is difficult to tell something for sure at the moment. Anyway i can try to figure out something but i need some output:
Export your current config (miscellaneous tab). Download and import config file from this archive (default 3.0.21 config). Restart CFP, set firewall and d+ to “disabled” immediately. Set d+ to training mode just before you launch your builds. Launch your builds and work like always.
After you finished (and d+ learned some stuff), switch d+ to disabled mode. Download script v0.7201 here and run it with settings as on attached screenshot.
Post .txt output here or PM it to me.
[attachment deleted by admin]