Evidence Dossier: The Comodo HIPS Rules Bug
This document itemizes all direct and corroborating evidence related to the long-standing bug that causes the Host Intrusion Prevention System (HIPS) rules in Comodo Internet Security to be deleted, typically upon system reboot.
Direct User Testimony & Symptom Reporting
This evidence, sourced from forum posts, describes the bug's behavior and its direct impact on users.
Complete Rule Annihilation
Users report a total loss of their security configuration.
(Quote) "I have the error that ALL HIPS RULES ARE DELETED AFTER EACH REBOOT."
System Destabilization
The bug's impact extends beyond settings loss, leading to critical system failures.
(Quote) Users report the system getting "stuck on black screen" during startup.
(Quote) Essential Windows utilities like Task Manager (`taskmgr.exe`) are blocked from running after the rules are wiped.
Decades-Old Issue
The problem is not a recent regression but a chronic flaw.
(Quote) "the disappearing HIPS rules bug... has been a bug for almost 20 years."
Occurs on Fresh Installations
The bug is inherent to the product itself, not a result of user error or environment conflicts.
(Quote) A user confirms the issue happens on a "fresh installation."
Cross-Version Persistence
The bug has affected numerous major versions of the software.
Reported In CIS versions v5, v6, v7, v8, and the target version 12.3.4.8162.
---
Root Cause & Trigger Identification
This evidence pinpoints the specific feature within CIS that acts as the trigger for the bug, providing a clear path for root cause analysis.
The "
Smoking Gun" Feature
Users have consistently identified a single setting that, when disabled, prevents the bug from occurring.
Finding
The HIPS rules stop disappearing after disabling the "Create rules for safe applications" feature.
Architectural Flaw Inference
This finding strongly suggests the bug is a (
race condition)
The automated rule creation process likely conflicts with the configuration saving process during system shutdown, leading to data corruption and deletion of the rules file.
---
Vendor Awareness & Response
This evidence, sourced from forum interactions with Comodo staff, demonstrates that the vendor has been aware of the issue but has failed to provide a permanent solution.
Official Acknowledgment
A Comodo staff member ("melih") acknowledged the reports from the community.
(Quote) "we can not produce all these bugs which you mentioned." This response confirms awareness while simultaneously deflecting responsibility for a fix.
Lack of Vendor-Supplied Solution
The only consistent "fix" offered over many years has been user-side workarounds, not an official patch.
Recommended Workarounds
Users are repeatedly told to perform a clean reinstall or manually re-import a saved configuration file after a failure.
---
Technical (Component-Level) Evidence
This evidence identifies the core software modules that are directly involved in the HIPS functionality, providing a technical basis for the bug's location.
Core HIPS Dynamic Link Library
`hips.dll` The primary library file for the HIPS engine.
System-Level Monitoring Driver
`cisevflt.sys`The kernel-mode filter driver responsible for intercepting system events, which is fundamental to HIPS operations.
Protection & Coordination Modules
`guard32.dll` / `guard64.dll`: Real-time monitoring and protection components.
`CmdAgent.exe`
The main Comodo agent service that manages and coordinates all security modules, including the HIPS. The likely process responsible for initiating the faulty configuration save.
The evidence strongly indicates that the HIPS is deeply tied to other modules, and this interconnectedness is the direct cause of the race condition. Fixing this would almost certainly require a complete rewrite of the HIPS module and the application's core configuration management, if not the entire application's central architecture.
Here is a forensic breakdown of the causal chain:
The Inter-Module Dependencies
A Tightly-Coupled System
A security suite like Comodo Internet Security is not a set of independent tools. It's a single, integrated system where modules constantly communicate. The HIPS is the central nervous system and must be tied to:
File Rating / Reputation System
When a new program runs, the HIPS doesn't act alone. It must first ask the reputation system: "Is this file signed? Is it on the global whitelist? What is its cloud reputation?" The answer determines the HIPS's action.
Antivirus Engine
If the HIPS detects suspicious behavior (e.g., a process trying to modify a critical file), it needs to be able to trigger the Antivirus engine to perform an on-demand scan of that process's memory and its source file.
Firewall
A user might create a HIPS rule to "Block" an application. This rule isn't just for behavior; it must also be communicated to the Firewall module to block that application's network connections.
The Central Agent (`CmdAgent.exe`)
This is the orchestrator. It manages the central configuration for *all* modules. When the "Create rules for safe applications" feature is on, it's the `CmdAgent` that receives the notification from the HIPS kernel driver (`cisevflt.sys`) and makes the decision to write a new rule to the master configuration file.
The Race Condition
A System at War with Itself
This tight integration creates the perfect storm for a race condition, especially during a system shutdown.
Event Occurs
During shutdown, a legitimate Windows process performs a final, necessary action.
HIPS Intercepts
The HIPS driver (`cisevflt.sys`), operating at the kernel level, intercepts this action.
Agent is Notified
The driver notifies the user-mode `CmdAgent.exe` of the event.
A New Rule is Born
Because "Create rules for safe applications" is enabled, `CmdAgent.exe` determines this is a safe, recurring action and decides to write a permanent "allow" rule to its configuration file to prevent future alerts.
The Race Begins
At this exact moment, `CmdAgent.exe` is trying to open, modify, and save its complex configuration file. Simultaneously, the Windows shutdown process is ordering all user-mode services, including `CmdAgent.exe`, to terminate immediately.
The agent is now in a race
Can it complete the complex, multi-module configuration write before the OS kills its process?
The evidence proves that it frequently loses this race. The write operation is interrupted, leaving a corrupted, incomplete, or empty configuration file. Upon the next boot, the application sees the invalid file and deletes it, wiping out **all** HIPS rules.
The Inevitable Conclusion
A Rewrite is Necessary
This is not a simple bug you can "
patch." It is a fundamental flaw in the application's architectural design.
You Cannot Fix a Race Condition with a Patch: You cannot simply tell the OS to "
wait." You have to re-architect the entire process to be transactional and atomic. This means the configuration save must be an all-or-nothing operation; it either completes 100% or it fails and rolls back to the last known good state, never leaving a corrupted file behind.
A Monolithic Problem
Because
`CmdAgent.exe` manages the settings for all modules, this isn't just a HIPS problem. It's a problem with the entire configuration management and inter-process communication model of the application.
The Required Fix
To properly fix this, Comodo would need to:
Rewrite the entire configuration persistence layer to be atomic and resilient to unexpected process termination.
Redesign the inter-process communication between the kernel driver and the user-mode agent to be more robust during critical OS state changes like shutdown.
This is a massive undertaking, far more complex than fixing a bug in a single function. It requires redesigning the very foundation of how the application state is managed. The fact that this bug has persisted for nearly two decades is the strongest possible evidence that the vendor has deemed the required architectural rewrite to be too costly or too complex to undertake.
All my applications defined in the Defense+ Rules are gone. They just disappeared. Now I get lots of alerts on the applications that used to be defined as Trusted or Custom policy. This has also happened before. Is this a bug? Is the definitions stored somewhere that I can recover them?
forums.comodo.com
Yes, the disappearing HIPS rules bug is listed as bug number 20 on this List of current bugs and it has been a bug for almost 20 years…
forums.comodo.com