CIS 4.1 x64 and two Guard DLL bugs update

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!

Many thanks.

Hi Searinox,

Can you please post a reference to the previous bug report where you describe the details etc.
That will save the dev’s time :wink:

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.

I have once again moved guard64 out of system32 and I’ve uploaded the BSOD minidump here.;msg401050#msg401050

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.

Unfortunately, as I understand it guardxx.dll have some functions which are not sandbox related, including aggregation of D+ registry alerts.

Sorry you are still having problems. I guess there was always the possibility with a multi-functional DLL that there was more than just one bug.

You could try defining the file as an installer/updater in the computer security policy, which exempts the file from more of D+ than most other policies.

Best wishes


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.

Yes of course it was a deep problem. I’m just suggesting a work around. Installer/updater, as I understand it, has certain properties not held by Windows System (eg inheritance).

In general running two security packages alongside each other is not always achievable of course!

Best wishes


I am aware that 2 products alongside eachother may not always work, but comodo and SEP never conflicted since version 3.0 and it would be a shame if from 4.x on this compatibility will be broken.

Is this still happening in

If so please give further details as requested here.

And attach a screenshot of your Defense plus logs.

Best wishes


I will have to enable logs since mine are off, also I currently have comodo uninstalled. I will check back here.

Thanks, I appreciate it.

Best wishes


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.

Hi there.

I think we’ll need to see the defence plus event logs to be able to help you. And for the developers to be able to investigate the bug.

One thought is to automate the killing and restarting of the tray app using a .cmd file. Ronny is pretty good at those, so he may be able to help.

Another thought is to disable SSDP discovery and UPNP services. Normally only relevant to XP though.

Work-arounds of course and may not help with the BSOD is still present.

Unfortunately I’m away for a week now, but doubtless other mods or users will help.

Best wishes


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.

No luck, it came back under the exact same circumstances on the new version. The new minidump is available in the BSOD thread. I am removing guard64 once again for my system’s sake…