D+ Rules disappeared - 3.0.25 x32 - Vista SP1 (UAC).

Today for the Second time my D+ Rules where completely gone !
I had to restore a backup again to get back to a D+ rule base with 210 entries in it.
Anybody had the same experience ?

There is no error, nothing went wrong, nothing in the logfiles.

I don’t know yet how to reproduce this…

Hallo Ronny,
Please post about your actively-running security and utility applications .
For more info about Bugreports refer to CFP BUGREPORT BOARD NOTICE

Are you running from an administrator account? With UAC on? Be sure you have CFP3 set to “run as an administrator” in the properties. When did your rules disappear?–after sleep, reboot, or ? Try rebooting and see if they go away again, to help eliminate Vista permissions issues. What other security programs are you running?

Running:
CFP 3.0.25
CMF 2.0.4.20
BOclean 4.26
Avast 4.8 Webshield

I can’t yet tell what happened when the rules disappeared, but looking at the registry while creating d+ events the whole registry key gets cleared before the “new” version is written to the registry. Maybe this writing the registry got interrupted somehow ?

As i posted in the Subject i am running Admin/UAC yes.
Where should i set the “run as admin” properties then ? CFP(GUI) is started from the \CurrentVersion\run key.

IIRC Vista UAC should not affect the registry zone where CFP writes its configuration but I may be wrong and there could be some privilege issue behind this.

There is a Tutorial on how to make CFP3 work nicely with Vista and UAC.

If you are still affected by this issue please reoprt back as the only way to go would be to gather more details as well as feedback from other eventually affected members.

I think i have found a possible cause.

If i apply changes to my current D+ Rules it takes cfp.exe about 15 seconds with 45% cpu load to write all my rules to the registry (232 rules at the moment).

If i put this together with me pressing Apply on a D+ Pop up (with remember set) while shutting down my laptop it could be that cfp has no time left to write all the rules back to the registry and i end up with a corrupted policy.

i’ll see if i can “force” this to confirm this behavior.

Can someone tell me if this 15sec cpu load is normal for this version ?
I’m running D+ in SafeMode and setup almost all processes with a custom policy.

There have been other reports of rule problems with 3.0.25 on the firewall side , could be related to the issues of https://forums.comodo.com/bug_reports/new_my_network_zones_entry_not_working-t24161.0.html. Suggestion would be to try 3.0.24 temporarily to see if that fixes the problem. You can get it at Download Comodo Internet Security 12.2.4.8032 for Windows - Filehippo.com.

I have a P4 HT 3 GHz and over 1gb ram available and XP sp3 32bit.
Other apps: Avira, Comodo Safesurf, Riva Tuner, Unlocker assistant, Speedfan, Daemon tools, Comodo Vulnerability Analyzer, Logitech Setpoint
Applying 130 D+ policies takes 3-4 seconds with a 40% CPU load.

I guess it would be possible to force this issue using some tool but a normal operation test would be needed to confirm it.

In order to force this issue I guess that a Force shutdown PoC (proof of concept) could be used.
These PoC use specific APIs to force a system shutddown (eg. NtShutdownSystem) if used improerly these PoC could cause dataloss.

I guess that forcing this dataloss on CFP it could give some hints about how CFP handle incomplete configurations.
Anyway I don’t advise to try this.

Under normal operations Windows usually alerts all apps about a pending shutdown to let them terminate without data loss.
IIRC a related windows setting that kicks in during shutdown is the time to wait before termination of non-responding apps (it should be 30-60 seconds).

This means that under normal conditions CFP will be forcefully teminated on shutdown if it is not able to do its things in 60 20+5 seconds.

IIRC CFP saves all its configuration upon exit/termination (I’ll have to test this again).
So I guess that the overall time to save the entire ruleset and the time to wait before a forceful temination could be related to this issue but if the time to wait is 60 seconds this may not be the case.

EDIT: I found out the relevant registry entries

HKCU\Control Panel\Desktop\WaitToKillAppTimeout 20 seconds
HKCU\Control Panel\Desktop\HungAppTimeout 5 seconds

The default timeout isn’t 60 but 20 seconds.

Thanks I updated my post.
I guess I have to take another remainig test to to confirm that CFP rewrites its entire configuration upon exit.

if HKCU\Control Panel\Desktop\AutoEndTasks value was not altered (defaults to 0) it should be possible to visually confirm this CFP termination scenario.
In fact if CFP crosses the default 20 sec limit a termination messagebox (end task) should be displayed at shutdown

Hello All,

One thing i know for sure is that if i change anything in D+ rules the whole registry key
HKEY_LOCAL_MACHINE\SYSTEM\Software\Comodo\Firewall Pro\Configurations\0\HIPS\Policy
get’s cleaned up and rebuild every time that’s why it causes so much CPU load.

Maybe i’ve triggered an extra feature by reshuffling the D+ rules so it’s sorted on

c:\windows.…
c:\program files.…
c:\data\tools.…

I like my rules in alphabetic order :SMLR

My registry doesn’t contain the WaitToKillAppTimeout and Hung AppTimeout so i guess i’m default.
Vista however does contain the WaitToKillServiceTimeout and that’s set to 20000

So far how many times your ruleset were deleted?
Did you find out soon after it happened during a session or did you find out after a reboot?
Did you happen to see an End task dialog on shutdown?

Hi Gibran,

I’ve experienced this 3 times now.
I’m not 100% sure if it was after reboot, thing that triggered me was firefox asking for things i’ve allowed earlier(weeks).
I’m sure i did not see a “End task” Diaglog on shutdown.

It was a pain but I used regmon to check again what happens on CFP exit.

It looks like CFP parse its configuration ose section at time, delete that section and rewrite it.
When you apply D+ rule changes this will only happen to the D+ section in the registry.

Can you close CFP manually and check how much time CFP CPU load raise?
If I understood correctly not all your D+ rules were deleted (or not always).

I guess this behaviour is more likely to happen when you shutdown your pc than actually saving only your CFP ruleset.
IMHO CFP is forcefully teminated soon after reach the D+ section, delete it and start rewriting the rules.
This coincidentally affect only your D+ ruleset.

Maybe it could be possible to forcefully cause this scenario altering

WaitToKillAppTimeout, HungAppTimeout and AutoEndTasks

Fast Shutdown Faster Windows 2000, Windows XP, Windows 2003 and Windows Vista

Well the configuration handling isn’t exactly optimal, even Microsoft discourages the use of registry for this case (large key/value numbers and frequent modifications) and rewriting the whole keytree just because one single option changed… ???, well looking at the format of the stored data I understand why they do this, but it’s far from optimal. Storing settings in a simple database would be probably better and a lot faster (at least when writing/editing a rule, but reading probably too).

Thanks for the comment khagaroth. However this will not help finding the real cause behind this issue.

I managed to reproduce it (after making a nice backup :SMLR).

Situation:
I run IEPrivacykeeper http://www.unhsolutions.net/IE-Privacy-Keeper/index.html to cleanup some stuff on shutdown, i removed a few d+ entries from this tool so it will pop up at system shutdown.

I shutdown my system with a shortcut to C:\Windows\System32\shutdown.exe /s /t 00

The pop up appears asking me to allow IEPrivacykeeper Interprocess memory access to another application… i wait a few seconds and press APPLY with Remember.

The system shuts down normally without any abnormal message.

I start my system again and after login i get pop up’s i normally don’t have so i check the d+ policy.
Almost empty only some 20 entries.

I fire regedit and take a look at the registry key:
[HKEY_LOCAL_MACHINE\System\Software\Comodo\Firewall Pro\Configurations\0\HIPS\Policy]
“Num”=dword:00000021 (33 decimal).

My backup file however shows:
[HKEY_LOCAL_MACHINE\System\Software\Comodo\Firewall Pro\Configurations\0\HIPS\Policy]
“Num”=dword:000000eb (235 decimal).

i made some screenshots and put a sysinternals procmon on cfp and clicked right mouse on the cfp, exit.
Shutting down cfp takes over 2 minutes with heavy cpu load.

(0) shows the corrupted policy.
(1) shows the registry still knows 232 rules (starts at 0).
(2) shows heavy cpu load on “exit”.
(3) shows the registry after shutdown now knows only 34 rules.
(4) contains a partial procmon pml file of the cfp shutdown.

[attachment deleted by admin]

[attachment deleted by admin]

I was off-track then :cry: The time to close CFP you reported is way too long and according to my hypothesis should have been enough to lose part of your ruleset on each reboot.

But is this the same issue or a new related one? Do you remember if the other times you lost your ruleset you replied on an alert upon shudown?

On my PC (XP sp3 32bit) I was not able to replicate the issue you described in your latest post nor my hypothesis.
CFP is set to safe mode.
I lowered WaitToKillAppTimeout to 3 sec and HungAppTimeout to 500 milliseconds (exiting CFP usually require up to 10 seconds here).
I used ultradefrag to reproduce the issue you described.
I removed ultradefrag rules and I run it. I keep a D+ alert for ultradefrag on screen and used shutdown.exe /s /t 00 to reboot.
During rebooting I clicked few times the OK button of D+ alert (it was marked to remember as well).

I tried this three times but my ruleset was unaffected.

Hello gibran,

A “normal” cfp exit takes 20 seconds with cpu load 50% (dual core, one core flatout).
I’m not absolutely sure but i think both times i “Applied” a pop up on shutdown.

How many rules does your D+ contain ? and as i stated before, i have “manualy” sorted the rules.

Around 130 D+ rules. I rearranged some rules too but I left the default ones on top (eg when i did thaose test after reboot I found ultradfrag rule on top).
Rearranging rules should be fine now but previously devs explicitely prevented manual sorting of D+ rules.
IIRC this was to force the application of the *(all application) rule before other rules.

Now some new rules are placed at the top of the D+ Computer security policy list so I guess it doesn’t matter anymore

[attachment deleted by admin]