Hi, also have same problem. One solution is with two monitors. Move comodo popup to second monitor. Then all popups will be shown there. Then I can see comodo popup that game want to access my keybord/dx/etc. But it is not possible to navigate through popup by keybord. Only by mouse. If i handle popup by mouse game continues ok. Bad is that sometime i move popup back (because of not using second monitor or whatever) and i’m lost :// No waiting, keys, blind clicking helps. Not even PC hardware button to turn off (gracefully shut down). I’m quite angry because after hardware reset all RAID discs start to check their state which takes hours and PC is very unresponsive.
I guess I’ll add my comments about this as I get it fairly often for new games I haven’t created rules for yet.
Essentially a game switches to full screen and then does something CIS doesn’t like. The system is then frozen for a multiple of the pop-up timer setting. The audio alert is active for CIS pop-ups but none sound for several multiples of the pop-up timer.
The major problem is that CIS6 seems to freeze things until a pop-up alert can tell it what to do… but the fullscreen game does something where the pop-up alert never shows up. For example the attached screenshot. The game does something CIS blocks but doesn’t create an alert. It does this several times and then finally shows an alert when the system unfreezes. The alert timeout for the screenshot is set to 30 seconds. CIS logs 5 actions that it suspends the program to ask about, but only shows an alert for one.
If the alert timeout is 30 seconds, the system may be completely frozen for a couple minutes. If the alert timeout is the default 120 seconds, the system will be frozen for 5-10 minutes. This is HUGELY annoying. I can’t find any settings to change to get the alert to show up on the first event. I might add I never had this problem with CIS5… it always showed alerts when events warranted it.
[attachment deleted by admin]
I guess I figured out a workaround for this problem since my last post. Since the problem was that games switching into fullscreen mode triggered this alert, I just told Comodo to stop triggering this alert. Might sound like an overly simple idea, but most people would just add exceptions to a specific program to get rid of the alert. (once)
I’ve attached a screenshot of the setting to add, though it’s quite easy. Go into the HIPS rules, edit the All Applications rule and add csrss.exe to the list of allowed files in Interprocess Memory Access.
To test this, I ended up making a pretty much blank XNA “game” that switches to fullscreen and then exits 20s later. Even this simple program triggered this exact alert… which tells me that Comodo was overzealous to protect against this.
The unfortunate thing is that I have no idea what security risks there are allowing a program to access the memory of csrss.exe. Otherwise I would suggest that Comodo make it a default-allow like they have for ctfmon.exe.
[attachment deleted by admin]
The above solution will not work. First of all it will allow memory access by csrss.exe to the game where it is the game that needs the memory access to csrss.exe process. Second, CIS will follow the rule that comes first (it reads top down) and that is the rule for the Windows System Application group.
You need to make a rule for csrssl.exe and place above the Windows System Application group. Make the rule for csrss.exe and choose to copy the Windows System Application group as the base line of the new policy.
Then go to Protection Settings and activate Interprocess Memory Access. Then add the game executable to the exceptions of Protection of Interprocess Memory Access. See attached image for an example.
[attachment deleted by admin]
Hmm, you say that it won’t work… but I would not have posted it if it did not already work for me conclusively. I don’t like putting misinformation in writing without disclaimers.
Your explanation doesn’t make sense to me as I read it. I am modifying the All Applications(bottom-most) profile, which I assume is any application without a rule above. I tell it to allow (outgoing?) memory access to csrss.exe. So in effect the rule states that any outside program can access csrss.exe’s memory. But your explanation states that adding an exception to memory access allows “incoming” memory access? That seems somewhat contrary to the alert system and what happens when I allow an application.
EDIT: Looking at the settings again… did you perhaps think I was adding the exception under the Protection Settings tab instead of the Access Rights tab? Outgoing vs Incoming? All I am changing is the one exception added to the Access Rights tab… and it has now fixed both of my Win7 systems from freezing.
In my previous testing, the “test” program had no D+ rules, so only the All Applications rule affected it. I see now that csrss.exe is inside of the Windows System Applications profile… however, it still doesn’t make sense to me that these entries affect “incoming” access instead of “outgoing” access.
At any rate, I have a second Win7 system that I’m going to have to implement the changes on… though I rather hate testing this issue as it will freeze my system for several minutes with a black screen. Would it help illustration at all if I attached my XNA program here? It’s easily less than 50KB if you have the prerequisites installed.
I made a wrong assessment. I assumed that the Windows System Application group had memory access protection enabled. But it doesn’t. In that case your solution will do the job.
I would advice you though to make a rule for your game application only and not to edit the blanket All Applications Rule. Giving memory to a Windows system file is not something to do lightly.
Running Paranoid mode with no trusted vendors makes every single game on my computer capable of freezing my computer for (4-to-12)*120 seconds. That’s a pretty terrible trade off.
The question becomes, what is the likelyhood of a program targeting that loophole… and what vulnerabilities even exist for such a loophole.
I understand your advice for general users so I won’t question it. I just have to make the decision of which is worse: freezing my computer for 5-30 minutes if I forget to pre-create a rule for a new game; or allow a possible vulnerability which may or may not have an exploit.
In closing, I’m fairly certain that Comodo v5 did not ever cause this kind of complete system lockup in this case. My involvement in this thread was to somehow hopefully get it to not happen in v6… for anyone. Does v5 simply not monitor this one thing, or does the process suspending work differently causing this issue?
Running Paranoid is not for the faint hearted.
The question becomes, what is the likelyhood of a program targeting that loophole... and what vulnerabilities even exist for such a loophole.To harden your system you can change the Windows System Application and Allowed Application policy to protect against memory access. If I understand you correctly.
I understand your advice for general users so I won't question it. I just have to make the decision of which is worse: freezing my computer for 5-30 minutes if I forget to pre-create a rule for a new game; or allow a possible vulnerability which may or may not have an exploit.When an exploit is being tried to run the BO detection will kick in. Unknown program will not be allowed to change protected files (.exe, .sys, dll ..)
In closing, I’m fairly certain that Comodo v5 did not ever cause this kind of complete system lockup in this case. My involvement in this thread was to somehow hopefully get it to not happen in v6… for anyone. Does v5 simply not monitor this one thing, or does the process suspending work differently causing this issue?
[/quote]
When running v5 with paranoid settings you would have gotten into the same situation unless I am missing something…
Using Clean PC mode with a new game in the Unrecognized File list would yield the same alerts and the same hard-freeze. It’s not a matter of what the mode is called rather what is being done with the system.
This may be a bad example… but take how v6 blocks applications running other applications. V5 would block the process from even starting until the alert allows it, while v6 suspends the new process while the alert is visible and then terminates it if it is not allowed. Sometimes the parent process will show an access denied message. (new with v6’s behavior)
This is merely an example of how v5 and v6 do a protection vastly different. I’m just assuming that because I didn’t encounter this fullscreen issue in v5, that something changed in v6 in how Comodo suspends processes and thus caused this issue to appear. It’s just a slightly educated guess that I have no way of testing. The alternate answer could be that the default settings of v5 verses v6 caused me to configure v6 differently to cause this.
As I mentioned before, I’m trying to provide dialog to prevent this happening to anyone. The optimal solution would be that Comodo HIPS somehow stops hard freezing the system it is trying to protect – using any sane combination of settings. However, as this is merely a user forum, I don’t seriously think this dialog will affect Comodo’s development.
Did you import a v5 configuration in v6? That is not recommended and can lead to unexpected behaviour.
No, I never have. I don’t even keep old configurations if I reinstall the same version.
If you meant this:
{...} The alternate answer could be that the default settings of v5 verses v6 caused me to configure v6 differently to cause this. {...}The meaning of that is that the blank defaults of v6 might cause me to directly manipulate the settings differently than the blank defaults of v5 might have made me want to change settings. I did not mean to imply that I ever imported the defaults of v5 onto v6.
Clean PC mode is nearly the same as Paranoid Mode everything new is classed as unknown.
As a example for Paranoid Mode in CIS Version 3 you could delete all Defense+ rules and not freeze your computer, starting with CIS Version 4 you could not.
Every version since has made Paranoid Mode more difficult to use, it is now to easy to freeze your computer with overload from the amount of alerts.
Also now with version 6 in Paranoid Mode you will have shutdown problems (slow), the only way is to check Defense logs and add rules manually.
An interesting divergence between making the UI so called easier to use for general users(the install and forget it crowd) while making everything else harder for those trying to keep control over their system with educated decisions… such as hiding settings behind more layers of UI and it causing issues like this and just described above.
Regardless, I’ve hated all of the other security suites I’ve seen… so I’ll just live with the harder to access UI(except the new alert UI, I love that) and iron out problems like this as I get to them. I’m just of the opinion that causing these kind of issues in a version upgrade seems like a stability regression.
Or you could look at as fixing leaks with D+.
Without knowing what is going on behind the scenes, that’s only a supposition. My alternative hypothesis without any experimental backing is that several v6 blocking methods changed.
I mentioned earlier that a change from v5 to v6 is that when HIPS blocks a program from executing a program… v5’s method was to prevent the child process from ever spawning while v6’s method was to immediately suspend the child process after it spawned and possibly terminate it.
What would happen if v6’s memory protection worked the same way? If v6 allowed incrementally more of the procedure than v5 did and then suspended the target process until the alert told it to allow/block. Temporarily suspending csrss.exe, which is known to be a bridge between usermode and kernelmode activities, might cause this freezing that is described here.
I admit that I only have anecdotal evidence to link together this hypothesis since I haven’t gone the extra step and made my testing program. But I think it’s equally irresponsible of you to simply say that HIPS causing more lockups/instability is because it’s more secure.
Well how do you envision a default deny based security suite to enact protection from unknown applications, or having no except rule made for it. Do you expect some voodoo magic behind the scenes to suddenly understand the program and allow it?
I’m not certain what I said to make you ask that, but the short answer would be no.
I’m just under the understanding that v5 didn’t cause full system unresponsivness where as v6 does and I tried figuring out exactly why it happened by offering hypotheses on what changed between v5 and v6. I didn’t find myself accepting your answer that HIPS was leaking in this instance with v5 and that v6 fixed it.
I apologize for my conduct if I have offended anyone. I do not mean to be hostile, but that seems to be the way people are reading my responses by the way I am able to read theirs.
CIS has always caused a “full system freeze” anytime an unrecognized full screen application started without a rule for me, it was even worst back in v3/v4. I don’t have such problems anymore with cloud up and TVL.
Some earlier in the thread claim to have never seen it, so I guess we have 3 camps. It doesn’t really matter to me at the moment as I don’t intend on going back to v5. Just diagnosing it how it works with the current version.
The problem doesn’t appear to be this simple anyways. I made a pair of testing programs that read and wrote each other’s memory and only the protected-against process seemed suspended, not the protected process. I guess it should be unsurprising that initializing fullscreen exclusive mode is complicated enough to cause things to go wrong if interrupted.
I am sorry… I have read all the posts and really couldnt figure out what I have to do to fix this. I have the same problem when I play XCOM but i couldnt even tell it was from COMODO until now. After i googled i found this topic and found out my problem was from COMODO.
I am not so computer litterate like you guys 
so if anyone could tell me step by step what i actually have to do to fix this i would muchj appreciate
thank you in advance