I’ve been using Comodo Firewall with Defense +. I’m not using any other part of the suite. I just downloaded and installed the latest update, 3.10, and my customized command line setup went BOOM!
At least one of the files I ran on going to the command line hung, and when I tried the simpler CMD command to get to the naked command prompt, many other DOS programs that previously worked stalled or gave error messages that the program could not run. This suggests it’s not just the parameter settings I’m using for AUTOEXEC.NT and CONFIG.NT, which are standard, except for the addition of an ANSI.SYS replacement
Running XP Pro. This happened on both my Athlon desktop and laptop. Turning the program off didn’t solve it. Uninstalling it did.
I’m back on the Windows Firewall until I get this solved. If I have to choose between my legacy DOS apps and Comodo, I’m afraid I’ll have to flush the Comodo.
Thanks so much. I’m glad because I really like Comodo, and I really like and need how I have my command line tricked out to run my legacy DOS apps, which include old electronic product designs in my old DOS printed circuit layout and schematic programs.
Ah, well… I wish Comodo’s updater had notified me that it was a version update, not just an update of files, but it reminds me why I tend not to be an early adopter. If I had known, I would have followed my usual practice of Ghosting my drive before adopting ANY new version of any program.
Thanks again for the quick reply. :-TU
I’ll be waiting for the update, and I will definitely Ghost my drive before I re-install the program.
I too am still having problems with running programs such as java.exe and lame.exe etc. in the command prompt. The programs won’t exit and consume high CPU levels. I have seen this as a problem detailed on the forums before (https://forums.comodo.com/bug_reports/guard32dll_and_problems_with_javaexe-t23488.0.html).
I am running Comodo 3.10.102363.531 on Windows XP Professional SP3 with latest patches.
Renaming guard32.dll in the system32 folder to something else fixes the problem. My guard32.dll file claims it is version 3.10.36817.531
Please can we have a proper lasting fix for this.
Incidentally, javaw.exe runs fine in a command prompt when guard32.dll is enabled, presumably because javaw.exe does not try to write to Standard Output or Standard Error unlike java.exe.