Installation problem: Comodo firewall agent locks cirrus.exe

[jdmarch]

I reported by email several weeks ago that I have been unable to install cirrus updates in recent months without rebooting because the file cirrus.exe is locked.

Today, when this problem occurred again, I used process explorer to determine that the locking process is cmdagend.exe, a service which is part of the Comodo 2.4 firewall. This process has cirrus.exe opened 5 times (5 different handles.) Interestingly, though I have 13 applications and 78 processes running on my system at the moment (and cirrus is not one of them!), cirrus.exe is the *only* file proper locked by cmdagent (in process explorer's "file" category, cmdagent also locks the win32 system folder, and some /Device objects which are mostly named pipes, but no other normal files.)

I wonder whether cirrus does something unusual which attracts comodo's attention in an unusual way, or perhaps fails to release some resource when it terminates?

I have very little troubleshooting time available, but I will see what else I can quickly learn about this odd behavior, in particular whether I can observe when these locks develop. For a start, of course, I'll go offline, shut down comodo and try to install cirrus without rebooting!

Windows 2000 SP4

[jdmarch]

Quick update:

1. As expected, I had no trouble installing cirrus after killing cmdagent (and before rebooting, see 2.)

2. Apparently it's not possible to shut down comodo's cmdagent service gently, and if it is killed externally, it's not possible to restart it from the services applet. So eventually I had to reboot anyway.

3. After rebooting, starting cirrus and opening a simple FTP session did not cause cmdagent to place a lock on cirrus.exe. So it's still a mystery what causes this lock.

=====
Update: I'm now running a background batch file to check for this lock every 1 minute. Hopefully this will help to reveal what causes the lock.

[jdmarch]

Testing results:

1. Comodo agent permanently locks cirrus.exe whenever cirrus tries to copy any of a number of a Comodo program files to which read access is denied. I do a nightly mirror of my system/program drive to a backup drive, and this mirror included a number of exe and dll files (and data.edb) in the Comodo program dir, as well as two sys files in system32\drivers. All these files had "access denied" which resulted in comodo locking cirrus.exe, apparently permanently until rebooting.

2. After excluding all these files from the backup session, the problem disappears.

3. Attempting to copy these files with Total Commander results in an identical result: Total Commander pgm file is locked by Comodo.

4. However attempting to copy these files with the internal copy command in JP software's 4NT shell does not result in any file lock (though access is still denied.).

While this seems to be more a quirk (feature?) of comodo than of cirrus, it is certainly worth being aware of and might be worth working around if possible.

[Zoë]

Thanks for the research. Short of reverse engineering how 4NT performs it's copy, I'm not sure how we can work around the issue. We're using the standard Windows CopyFile function, so any issue it has is going to affect an awful lot of programs. You might try BC2 with the OldCopyMethod tweak and see if it works any differently.