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

[Guest]

[Ronny]

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...

[gibran]

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

[sded]

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?

[Ronny]

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.

[gibran]

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.

[Ronny]

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.

[sded]

There have been other reports of rule problems with 3.0.25 on the firewall side , could be related to the issues of http://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 http://filehippo.com/download_comodo/.

[gibran]

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.

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

[khagaroth]

The default timeout isn't 60 but 20 seconds.

[gibran]

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

[Ronny]

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 

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

[gibran]

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.

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?

[Ronny]

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.

[gibran]

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

[khagaroth]

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).

[Tags:]