Persistent blocked intrusions


My issue pertains to the file “glyph.exe” (an installer/patcher for an MMO) being repeatedly blocked, easily over 1000 times in an hour. After the initial pop-up I had set Comodo FW to recognize the file as an installer, so it should not have been blocked, and this was the case over the past year. But after a recent glyph download/patch I’ve been getting these repeated blocked intrusions which have been completely preventing the game from loading, delaying the loading significantly, or at the very least prevented the rendering of the in-game graphics correctly, so blank shapes would appear common, even though I’m certain my GPU is more than capable of handling the specs of the game.

The defense+ logs show that the file is flagged as wanting access to the memory. This was never the case before the patch. I’ve tried opening up the game under training mode, FW disabled, re-installed the FW, and made sure the file was recognized as trusted, and was either an allowed application or viewed as an installer, to of no avail. So finally, is it safe to let the file access the memory? As I have little to no knowledge of the consequences of doing so.

What type of memory access does the log specifically say? There are two memory access rights, one is physical memory and the other inter-process memory. In the event log for defense+/HIPS what does the target column say?

The target column says that it leads to C:Program Files\COMODO Internet Security\CisTray.exe, is this what you meant?

Yes and we know what the issue is, comodo prevents all running applications except for a few, from accessing its executables in memory. You would then need to edit the Interprocess Memory Access protection exclusion for comodo internet security HIPS rule. Active HIPS Rules, Network Access, Internet Protection | Internet Security in the exclusion select running process and select glyph.exe from the list if it is running or browse to its file location.

Thank you, modified it so the file is on the exclusion list for the firewall, but the problem persists so I’m thinking it may be an issue elsewhere. I just hope it’s safe for glyph to continue to have access to the memory.

Can you export the log for defense+/HIPS and zip and attach it here? use the view logs general task and from the drop down menu select HIPS events then make at the top next to the x icon to clear logs there should be an arrow icon to export, save it with whatever name and zip the file or change the file extension to .txt because you can’t attach html files to forums posts. And do the same for firewall events just in case.

Ok sent, hope it’s viewable. Tried changing to .txt and was unsightly as it was originally a .htm so ended up using zip.

[attachment deleted by admin]

Oh, and sorry for the double post, but I also got these logs in the firewall today too. Any clue in regards to them?

[attachment deleted by admin]

Ok like I said before you need to add the application the exclusion list of interprocess memory access protection settings for the comodo internet security HIPS rule. In HIPS rule there is a rule called COMODO Internet Security edit its rule and click the Protection Settings tab, next to Interprocess Memory Accesses click the modify link, in that windows click add, files from the list, then within the file explorer windows go to C:\Program Files (x86)\Glyph\GlyphClient.exe and ok out all windows. You should also add a HIPS rule for glyphclient and use the allowed application rulset next to the use a ruleset option in the HIPS rule window.

As for the firewall ARP blocked events, that is normal when you have enable anti-ARP spoofing set in the firewall settings. The firewall is blocking gratuitous arp packets, the only way to not see these blocked events is to disable the setting enable anti-ARP spoofing which you really don’t need unless you connect to untrusted networks such as public Wifi or school networks.

[attachment deleted by admin]

Please note as a word of warning.

If you allow any process this sort of access it will also allow it to kill CIS.

So unless you completely trust this process you should not allow this access.


I had it on the exclusions list for CIS before, which stopped the blocked intrusions. I took it back off exclusions after seeing that the problems persisted, otherwise the logs would have been empty. It could be the program itself with problems and not the firewall, but it’s hard to tell. Also, could someone elaborate on the risks of leaving it to access CIS’ memory?

If glyp.exe would get infected by a malware the malware can then take over and shut down CIS processes. Hence why we are very cautious with allowing memory access. But sometimes it is needed to have applications work properly. On a sidenote; it is not a good programming practice to keep on hammering for memory access when it is not allowed.