Jump to content

Odd behavior from favorite old version of Comodo - SOLVED


Recommended Posts

Is anyone else here using an old version of Comodo? (3.14.130099.587 for me, or possibly some of the v5 series)

I've had this version installed (just FW and Defense+, not the AV, for that I use Avast 6) on this machine and running perfectly for more than 4.5 years. But around 4/29 it started behaving oddly (on just this one system, I have it running perfectly on several others). That's when I noticed that the system tray icon allows calling up the GUI for a little while immediately after booting, but somewhere between 2 and 3 minutes post boot, the tray icon goes unresponsive. When this happens I also cannot call up the GUI from the start menu, nor from desktop shortcut. Then after roughly 90 minutes, suddenly the GUI that would not start earlier finally appears and thereafter works as if nothing were ever wrong. This delay seems pretty consistent as does the 2-3 minutes postboot, almost as if something has a timeout, though I don't know what it is waiting for.

I checked in Task Manager during this time, and there are no unfamiliar processes listed. Both cmdagent.exe (the service portion) and cfp.exe (the GUI portion) are running as expected, but I can't switch to cfp.exe during this 90+ minutes. Trying to kill cfp.exe during this time simply hangs Task Manager. Leaving this sit for the 90+ minutes will let it suddenly unlock and everything goes back to normal. It isn't a normal sort of network issue, I can surf and check email just fine during this time, the only thing I cannot do is open the Comodo GUI.

I tried looking with the process list tool in an old version of Spybot; this has the added bonus of showing what network connections a process has open, which I can't check in the Comodo UI since I can't get to that while it is hung. It seems to have one ephemeral port open, the port number changes every few seconds while the GUI is not responding, but these changing ports will suddenly stop and the open port vanishes when the GUI becomes available again.

Checking system event logs gives no clues, likewise Comodo's own logs show nothing odd. I even tried setting a rule on Comodo to log its own traffic but there are no entries from that rule. Other rules do make log entries during this time so it isn't a logging issue.

Searching the Comodo forums finds several posts with similar symptoms (all from version 3.x or 5.x, I didn't see any later) but all of the supposed cures end up not solving it even for the posters who initially thought they had found the answer. (Apart from "upgrade your OS, then update to latest version", generally something post-ver 5 - but then why did this version work perfectly for 4.5 years on this system and even longer on my other systems?) I have tried the uninstall-reboot twice-reinstall path a couple times with initial success, but the problem always returns after 2-3 reboots so it isn't really the solution.

I plan to run more malware scans later today but so far have not found anything; since there are no other symptoms I'm not really expecting to find anything when they are finished.

Assuming the scans come up clean, does anybody have a suggestion for how I might track down the cause of this odd behavior?


Edited by w2k4eva
marked as solved
Link to comment
Share on other sites

  • 5 weeks later...

Has nobody else ever seen this?

I ran scans with MBAM, SuperAntiSpyware, and Avast boot time scan. As expected, no malware found.

Also noted another odd thing. The 90 minute delay can be cut short by temporarily disabling the ethernet adapter; the GUI unlocks, and the tray icon works again. Re-enable it, and everything is good to go. FWIW, I found it was set up for a fixed IP address rather than the usual assignment from the router's DHCP server, so it wasn't even waiting for an IP address.

Any debugging suggestions?

Link to comment
Share on other sites

  • 2 weeks later...

Well, the fixed IP address turned out to be the relevant clue. I changed this back to automatic assignment from the router's DHCP service, rebooted, and had no connection. Investigating this showed the XP DHCP client service had somehow gotten disabled. Resetting this to Automatic solved the issue.  Apparently Comodo likes to see the DHCP handshake happening for whatever reason, even if it does not actually need the IP address - I can even go back to fixed IP address now without getting that 90 minute delay any more!

Edited by w2k4eva
  • Upvote 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    • No registered users viewing this page.

  • Create New...