Yes if you import your saved config and activate it you will have your old rules back, but create rules for safe apps will be re-enabled which sounds like you had with the previous version. No you do not have to update to the new beta, it will be released as stable sometime this week.
Good evening,
using the saved configuration I solved and re-emerged the HIPS rules.
Thanks for the support :-TU
V12.2.2.7036 (Firewall only) Windows 7 Ultimate 64-bit
This just occurred after Windows startup.
I have “HIPS->HIPS Settings->Create rules for safe application” option enabled right after I installed CIS so the “HIPS Rules” list got populated with rules for safe applications.
Now when I just opened up “HIPS->HIPS Rules” to take a view at the rules the whole list was empty, all rules where gone.
Going to “HIPS->HIPS Settings->Create rules for safe application” to toggle that option off and then went back to the “HIPS Rules” the list was re-populated again.
Set “HIPS->HIPS Settings->Create rules for safe application” option back to enabled.
Probably the “HIPS Rules” list didn’t get refreshed on opening it.
Is there a way to force a refresh of the HIPS Rules list by a hotkey or so if it happens again?
There is a slight delay in starting the process of adding secure applications;
Here it works well, the only thing observed was new processes start to act and CIS start add applications safe :-TU
Known issue where rules that are created by CIS automatically will be erased on system shutdown as CIS does not get the chance to finish saving the rules when a new one is being created during shutdown. Hence no one should use the auto create rules setting as it also causes high CPU when rules are being auto created. I’m assuming the default rules are no longer there and the ones that were repopulated were the newly added rules.
So far I always did a proper system shutdown (not forced by turning power off) and let the system nicely turn off itself.
I’ve checked the content of the HIPS Rules list and rules on it seems not to be repopulated from scratch because I still can see applications on the list that I started manually a while ago.
I think there was/is some sort of delay in proper refreshing the list hence the question if it could be refreshed manually (like pressing F5 in windows explorer).
I understand that auto create rules consume high CPU load when those rules are being created but once they are created the high CPU load will decrease again, am I right?
Or does consulting the list also take the same or even higher CPU load?
If a new rule is being added during shutdown, including normal shutdown, CIS does not finish saving the rule in the registry which causes all rules to be deleted on next log in. Also if you time it right at opening the HIPS rules as a new auto created rule is being created, yes you will see all rules gone, but as long as you don’t click OK button, the next time you open the HIPS rules they will be there including the new one. All setting sections are static so you would need to close out the window and re-open it to see updated info. i.e. file list, firewall and HIPS rules, etc.
Excellent explanation futuretech.
That’s just what has happened, I opened up HIPS Rules at an unlucky moment, as you say, when an auto create rule was being added to the list. When I saw the empty list I went straight to “HIPS->HIPS Settings->Create rules for safe application” (so not by selecting Ok or Cancel button first) to toggle the option. Toggling the option has nothing to do with it, it was just acting as a time delay to give HIPS Rules the chance to refresh/update the list.
Very good to know that when noticing an empty list (be it HIPS, FW or any other list in CIS) to always click Cancel and re-open the list again (or going straight to another Settings item and then go back to the list).
But in any case never select the Ok button when you see an empty list when having auto create rules option enabled.
Great inside information, thanks!
Isn’t it possible to prevent the complete loss of a list when accidentally the Ok button is pressed by some sort of “list double buffering” and in worst case only loosing the last added auto create rule?
In my opinion programming such a fail-safe method would not be too difficult to implement and would increase the product quality.
Maybe who knows but the real fix would be to remove create rules for safe applications as it doesn’t provide any real value and cause performance hit with it enabled.
Regarding the “Create rules for safe applications”…
I find this feature very useful, even though it takes some CPU load.
So, don’t ever remove the “Create rules for safe applications” feature, hands off please! 
Hi, I’m just curious. Since Comodo will automatically trust safe files and trusted vendors no matter what, what is the usefulness of “Create rules for safe applications”?
I’m really shocked!!! :o
It never ever happened before on me but now it did, I’ve lost all my custom rules after last shutdown!!
Before I submit a bug report I ask here if this bug is already been taken care of or if it is already going to be fixed otherwise I submit the bug in the bug board.
This is really terrible…
Or rather you have been very lucky
Any saving of rules during shutdown that fails to finish corrupts the rules.
Only one way Windows treats a corrupt register or part of is it dumps it, save your configuration always.
If the rules where not saved in the register all you would have is one corrupt rule instead of all.
Dennis
Yes I know I’m a lucky guy (well sometimes then)
Seriously, do they know about this bug and are there any plans to fix it or are they working on it already?
Manually saving the config each time just before shutdown isn’t a workable solution in my opinion, who is going to do that? Do I have to stick a Post-It on my screen to let me remind of saving my config before shutdown? I do not know about any other application that requires you to save the config or settings just before you shutdown you system to prevent config or settings corruption. It sounds a bit silly when an application requires you to do that, don’t you think?
I’m not getting paid for brainstorming sessions here but here are some suggestions that could prevent this config corruption easily without requiring too much implementation efforts or costs, to name some suggestions:
- How about implementing an auto-config-save function on timer base?
- How about implementing an auto-shadow-config-save function on timer base and a mechanism that detects the corrupt primary config and restores it from the shadow copy.
- How about implementing a config double buffer or a config shadow copy in the registry and a mechanism that detects the corrupt primary config and restores it from the double buffer or shadow copy?
- How about delaying windows shutdown while saving the rules is in progress? It doesn’t take too long to finish saving into the registry.
- …
I think there a numerous simple and easy solutions to resolve this nasty bug.
Is there already a bug submitted for this? I would be glad to submit one.
The CIS configuration is stored in the registry. To get it back use system restore. After you restored export the active configuration to a folder that is not part of the CIS installation folders.
When necessary you can go back with system restore again and import and activate the saved configuration.
If I understood it correctly by reading the posts of other members about this issue, it only happens if you have “Create rules for safe applications” enabled. There is already a Bug report for this but it was submitted as a Wish instead, not sure why.
The best fix would be if they removed the “Create rules for safe applications” setting, since as it seems they are unable to fix this disappearing rules Bug or probably have other priorities on CIS development.
I hope you agree with me that this method to get the config back is really cumbersome.
Furthermore, this is not an option for me as I have disabled system restore for reasons.
The option “Create rules for safe applications” can be enabled for both HIPS as for FW which I have both on.
If it happens that FW wants to create a new custom rule at an unlucky moment during shutdown is there then also a chance that the FW custom rules get corrupted or does FW handle custom rule creation differently?
I think the answers to the following questions are very important to know…
When windows is busy with shutting down the system and HIPS (or FW if rule corruption also happens there) pops up an Alert does corruption then already take place before the Alert is actually shown or not until the Alert is either forcibly closed by windows or closed by answering the Alert?
In case of answering the Alert (that is, if you are fast enough to be able to answer it before windows forcibly closes it) does the chosen Alert answer then play a role whether or not corruption occurs?
Or does the above not matter at all and corruption just might happen at any stage during windows shutdown when HIPS (or FW) want to create a new rule?
I’m trying to find the moment in time when this corruption occurs.
Hope someone (devs?) can shed light on this.