I have just installed the brand new version of comodo 4.1 and I have a report to make on two previous guard64.dll bugs, which could previously be solved only by removing the guard dll.
Windows Live Messenger Tray Bug: FIXED - WLM set to run in compatibility mode now does so correctly
Symantec Endpoint Protection Tray Bug: NOT FIXED - SEP fails to display its icon in the system tray on startup. Process must be terminated and restarted manually for it to appear. Removing guard64 from system folder fixes this. Please fix quickly while you’re still hot on the bugs’ trail!
Although you appear to have fixed WLM, I will sadly have to displace my guard64 yet again until this bug is also fixed. It can’t be far off, please look into it!
One of the restarts I had let the SEP icon load. I found this strange as the first restart after the update let SEP load. So I did another restart and on this one I got a bluescreen - INVALID_PROCESS_ATTACH_ATTEMPT. Upon analyzing the dump, SRTSP64.SYS is reported - one of SEP’s components. Clearly guard64 hates something about SEP ever since CIS 4.x. I am not using the comodo antivirus, just the firewall, and the software combination has run flawlessly up to now.
The bug was Symantec not starting in the system tray with Windows unless the guard DLL was removed. As you can see from this post, the problem is much worse now. It is in fact possible that this problem existed ever since CIS 4.0’s release, but didn’t get a chance to show since I removed guard64 after a few restarts after the bugs it caused.
Please for the love of god add an option to “Deactivate Sandbox Permanently”(assuming sandbox is guard’s only function) like Defense+ has.
This wasn’t a policy issue. All the files in symantec’s folder are added as windows system applications - the most permissive of all. There has been no change in D+ rules before and after the update. The dll’s mere presence causes instability.
Okay. For the duration of using ZoneAlarm my symantec av started appearing in the tray again. However, as soon as I reinstalled comodo, it’s not showing up again. It will OCCASIONALLY show up upon restart but rarely, only after restarting enough times. As for the symantec av bluescreen, SO FAR there has not been another. However, comodo is STILL choking SEP. Even in the new 4.1.x.920 version. I have also failed to reproduce this on 32bit, only 64 seems to be affected. This should help you narrow down the problem. If your dev teams can get a SEP license for debug purposes, you should obtain a copy of SEP and try reproducing the issue yourselves.
As for now, it seems that I have to resort to taking guard out of system32 AGAIN. However, I will simply restart until symantec starts up and try using the comp normally to see if at least the bluescreen is fixed.
I had the logs disabled, however I will enable them before the next restart. All the programs of SEP are allowed and again: using the same rules, version 3 never caused any issues. The fact that it sometimes starts shows me that there may be a race condition. UPNP was already disabled. I am now disabling SSDP. I can kill and restart the tray app manually, again AFTER the startup it doesn’t fail to launch at all. Only during startup. But I’m concerned of comodo tampering with something as low-level as the AV.
Several issues experienced in the past with guard are gone, and now SEP at least SOMETIMES starts up, also no BSODs so far so yes I can indeed see that the team has been fixing stuff. The issue is partially fixed, I’m confident the devs can eventually get everything right. Bringing innovation and keeping software stable is tough, but CFP 4 is quickly becoming as stable as 3 was. Please iron these bugs out, I know it can be done.