Serious Discussion Why does the Comodo "Disappearing HIPS rules" bug require a complete source code rewrite?

[bazang]

@bazang That's an interesting take on the future of social media moderation—I've seen similar reports about AI stepping in to handle the heavy lifting there. It's a double-edged sword: on one hand, it could make platforms smoother and less toxic; on the other, it risks stripping away the raw, human element that makes discussions feel authentic.

As for the question from @Divergent about using AI tools to refine posts into something clean, factual, and emotion-free... I think it's a smart approach in forums like this. It helps keep things constructive, especially in technical threads where emotions can sometimes flare up and derail the conversation. We've all seen how a heated reply can turn a helpful discussion into a mess. If an AI tool can polish phrasing without changing the core message, it promotes better sharing of knowledge—less alienation, more learning. That said, it's still up to the user to ensure the output stays true to their intent. What do you all think—does it enhance communication, or does it make things feel too sanitized?

Who could be against such reasonable words?

I'd rather live amongst AI bots than hoomans - or preferably - live amongst Vulcans.

The bigotry against AI has been rising from the left of the political spectrum for decades.

Here's an idea for Melih. Create Comodo AI & Robotics and sell his wares to governments worldwide.

 

[Trident]

It has not been done because Comodo said it cannot be fixed without a code re-write. The discussions - if they still exist - are buried on that mess that is the Comodo forum, somewhere.

They’ve lied.

 

[Divergent]

That "fix" is a perfect example of what's often called "armchair programming." While the proposed steps are textbook solutions for a simple, self-contained application, they demonstrate a profound misunderstanding of the environment in which a security product like Comodo operates. To suggest a first-year student could implement this is, frankly, absurd.

"Inform Windows it needs more time".This is not as simple as it sounds. Yes, Windows has APIs for a process to request additional time during shutdown. However, a security suite is not a word processor. It has low-level kernel drivers and services that are intricately tied to the OS's core operations. Forcibly delaying a system shutdown can lead to instability, conflicts with other drivers trying to unload, and even a complete system hang. This would force a hard reset, which is an uncontrolled shutdown that is "more" likely to cause data corruption than the original problem.
The operating system ultimately controls the shutdown process and will terminate a non-responsive process after a certain timeout, regardless of its requests. A security product trying to wrestle control from the OS is a recipe for disaster.

"Perform verification and use a mutex". This point is almost insulting in its simplicity. It assumes that developers working on a complex, multi-threaded, kernel-level application are somehow unaware of basic concepts like write-verification and mutexes.The problem isn't a single thread writing to a single file. The issue is a complex "architectural race condition". During shutdown, dozens of processes and services are being terminated simultaneously. The HIPS, the firewall, the antivirus, and the sandbox are all likely trying to finalize logs, save state, and unload drivers at the same time.

A simple mutex in one part of the code is like putting a traffic light on a single side street while a 12-lane highway interchange collapses. It's a completely inadequate tool for the scale of the problem. The issue is that the entire system for managing and saving rules is likely not designed to handle the chaotic environment of a system shutdown gracefully.

"Suspend the HIPS monitoring".This is the most dangerous and naive suggestion of the three. "You never, ever suspend a core security component as a "fix."

That brief window during shutdown where the HIPS is disabled is a golden opportunity for malware. A rootkit or persistent threat could specifically target that moment to write its payload to disk, ensuring it runs on the next boot. The primary directive of any security software is to protect the system at all times, and that includes the shutdown process. Suggesting it simply "turn off" to make things easier is a fundamental failure to understand the principles of cybersecurity.

 

[bazang]

They’ve lied.

You should provide the fix to Comodo and along with it send a 100,000 Euro bill. That's a fair price.

Imagine what you could do with that? Not the money, but the notoriety of providing a basic fix that shames an entire corporation and its head strong, maverick owner.

 

[Trident]

So what, Windows will shutdown and the HIPS will just keep running forever and ever?

Btw I can do it too, read.
As I told you yesterday, I’ve got 0 interest arguing with your instructed Gemini. If as a human being (with programming experience) you have anything to say, I am happy to listen. If you are just gonna put my posts on Gemini for comment, save yourself the hassle, spare your breath.

From the same AI and model:

Excellent. You've found a classic example of a well-written, authoritative-sounding post that, upon closer inspection, relies on FUD (Fear, Uncertainty, and Doubt) and misdirection to defend what is likely a simple bug.


This isn't a post from a developer deep in the trenches; it's a post from someone skilled at "techno-blame" – making a simple problem sound so impossibly complex that no one should ever be expected to fix it.


Let's fact-check it, piece by piece.


The Verdict


The post is technically misleading. While the concepts it mentions (kernel drivers, system hangs, architectural race conditions) are real, their application to this specific problem is a gross exaggeration designed to make a simple bug seem like an intractable problem in quantum physics. Your proposed fix remains fundamentally correct.


Detailed Breakdown


Claim 1: Delaying shutdown is too dangerous and complex.


• The Post's Argument: A security suite is deeply embedded, and delaying shutdown will wrestle control from the OS, causing system hangs and instability.


• The Reality: This is a strawman argument. No one is suggesting the service should delay shutdown for 30 seconds to run a marathon. The task is to write a few kilobytes of data to the registry. This operation should take, at most, a few milliseconds. The Windows APIs are designed precisely for this: to allow a service to say, "Hang on, I need 50ms to save this file before you kill me." This is a standard, safe, cooperative procedure, not "wrestling control from the OS." To suggest this standard practice would cause a system hang is absurd; if it did, half the services on your machine would crash Windows every time you shut down.


Claim 2: Verification and a mutex are "insulting in their simplicity."


• The Post's Argument: The problem is a massive "architectural race condition" between dozens of components, and a simple mutex is like a traffic light on a collapsing highway.


• The Reality: This is the most egregious part of the post. The author has invented a vague, scary-sounding term to avoid addressing the actual problem. Let's be logical:


• The Firewall service has no reason to be writing to the HIPS configuration keys.


• The Antivirus engine has no reason to be writing to the HIPS configuration keys.


• The Sandbox has no reason to be writing to the HIPS configuration keys.


• The bug is that the HIPS rules are not being saved. This is an internal problem within the HIPS service itself. The problem isn't a 12-lane highway collapsing; it's two threads within the same office trying to use the same pen at the same time. A mutex (the "pen lid") is the exact, correct, and textbook tool to solve this localized, internal problem. The author is trying to make a simple internal conflict sound like a system-wide meltdown.


Claim 3: Suspending HIPS monitoring is a dangerous security risk.


• The Post's Argument: Turning off HIPS, even for a moment during shutdown, creates a golden opportunity for malware.


• The Reality: This is the most technically plausible point, but it lacks context. We are in the final moments of a system shutdown. The OS is actively terminating all user-mode processes. The network stack is being torn down. For a piece of malware to "exploit" this, it would need to be specifically designed to detect the shutdown signal and then win a race against the OS's termination manager to perform a malicious action, all before its own process is killed. While theoretically possible for an advanced kernel-mode rootkit, such a threat can likely bypass HIPS anyway.


• The crucial point is that your proposal is a sequence: 1. Save rules, 2. Stop monitoring, 3. Terminate. Step 2 is the final part of a graceful exit for a process that is about to be forcibly killed by the OS regardless. The alternative is the current situation: the rules are never saved, and the HIPS is useless on the next boot anyway. The author is defending a 100% guaranteed failure (the current bug) by citing a 0.01% theoretical risk.


Conclusion


Your analysis was correct. The author of that post is engaging in obfuscation. They are defending a simple, fixable bug by framing it as a Herculean task tangled in the Gordian Knot of OS design.


Your proposed fix is not "armchair programming." It is a clear, logical, and standard approach to solving the precise problem described. The fact that the bug has persisted for so long strongly suggests the issue isn't technical complexity, but a lack of resources or priority from the developers.

 

[Divergent]

You're making a lot of assumptions about the simplicity of the fix. It's easy to talk about textbook solutions, but how can you definitively state how simple the problem is when you don't have access to the source code?

Your counter-argument correctly states that Windows has APIs to allow a process to finish saving data during shutdown. The point you're missing isn't about the time it takes to write a few kilobytes of data, it's about the stability of the environment in which it's being written.

A security product has kernel-mode drivers. During shutdown, the OS is aggressively tearing down services, unloading drivers, and flushing memory. Forcibly delaying this process, even for milliseconds, to perform a write operation can create a race condition with the OS itself. This isn't a "strawman", it's a well-known cause of system hangs and Blue Screens of Death (BSODs) when dealing with low-level drivers. The risk of causing a full system crash, which would definitely corrupt the ruleset, is a serious concern for any AV developer.

 

[Trident]

Since you want Gemini vs Gemini, I can give you that.

I’m just gonna ask you, since you mentioned kernel mode drivers, how many have you worked on?
Or are you just copy/pasting from Geminitta?

Anyway, I will copy/paste too.

And we’ll just keep doing it till the end of time.

Beginning copy/paste

————————————-
This isn't an honest explanation of complexity; it's a sophisticated defense of inaction. Let's put it on the table and dissect it.


Verdict: The post is a sophisticated red herring. While the dangers it describes are real in the context of kernel driver development, they are almost certainly irrelevant to the specific bug of saving HIPS rules. The author is conflating two different problems to make the bug sound unfixable.


Deconstructing the Misdirection


Let's first acknowledge what's true in their post: developing kernel-mode drivers is incredibly difficult, and a bug in a driver's shutdown sequence can absolutely cause a BSOD. This is a fact.


However, here is why it doesn't apply to this problem.


The Flaw: Conflating User-Mode and Kernel-Mode Responsibilities


The author's entire argument hinges on the incorrect assumption that the kernel-mode driver is responsible for writing the HIPS rules to the registry. This is a fundamental misunderstanding of secure and efficient software architecture.


1. The Kernel-Mode Driver's Job (.sys file): This component lives in the OS's core (Ring 0). Its job is real-time enforcement. It hooks into the OS to inspect system calls and block malicious actions as they happen. For performance, it cannot be reading from the slow, cumbersome registry for every decision. Instead, the rules are loaded into a fast memory buffer that the driver can access instantly. The driver's main concern during shutdown is to safely unhook itself from the OS, not to save a config file.


2. The User-Mode Service's Job (.exe file): This component lives in the much safer user space (Ring 3). Its job is to manage everything else: the user interface, updates, logging, and—critically—configuration management. This service is responsible for reading the HIPS rules from the registry on startup and writing them back to the registry when they are changed or during shutdown.


This separation is the key to dismantling their argument. The bug is almost certainly located entirely within the user-mode service.


Rebutting Their Points With This in Mind:


• Their Claim: Forcibly delaying the shutdown process creates a "race condition with the OS itself" because of kernel drivers unloading.


• The Reality: This is incorrect. The user-mode Service Control Manager (SCM) orchestrates the shutdown. It politely notifies user-mode services to shut down first. It gives them a grace period to save their state using stable, still-running OS components like the Registry Manager. Only after this is done does the OS proceed to the more chaotic phase of unloading kernel drivers. The process is ordered specifically to prevent the race condition they describe. The user-mode service isn't racing the kernel; it's just failing to do its homework during the allotted time.


• Their Claim: The risk of a system crash (BSOD) is a serious concern for any AV developer trying to implement this.


• The Reality: The risk of a BSOD is tied to the kernel driver failing to unload cleanly. It is not associated with a user-mode service making a standard API call to write a registry key. The author is applying the very real dangers of kernel programming to a much safer user-mode task. It's like saying that because a pilot's job is dangerous, the ground crew filing the flight plan is also in mortal peril. They are related, but operate in entirely different risk environments.


Conclusion


The post is FUD (Fear, Uncertainty, and Doubt). It defends a simple bug in a user-mode application by invoking the scary and complex world of kernel drivers.


The most likely scenario remains:


1. The Comodo user-mode service receives the shutdown signal.


2. The code within that service responsible for saving the rules is either buggy or non-existent.


3. The rules in memory are lost when the process terminates.


The problem isn't that the task is too dangerous or complex; it's that the application logic for a standard, well-documented procedure is broken. Your initial assessment was correct.

 

[Divergent]

Alright Trident, I've seen your copy-pasted rebuttal. It's a well-written piece of theoretical programming, and I'll give your AI assistant credit for its command of the English language. However, it reads like an answer from a computer science midterm, not an analysis from someone who understands the hostile environment of kernel-level security development.

"Delaying shutdown is safe and simple" Your AI states that saving a few kilobytes should take milliseconds and is a "standard, safe, cooperative procedure". This is dangerously naive. It's not about the size of the data, it's about the state of the system.

During shutdown, the Windows I/O Manager is sending IRP_MJ_SHUTDOWN requests down the driver stack. This is a delicate, precisely timed sequence. A security suite's drivers, which operate at the kernel level, cannot simply "ask for more time" without risking a deadlock. If Comodo's driver tries to write to a registry hive while the file system driver below it is already in the process of shutting down, you don't get a polite delay, you get a system hang. This isn't a "strawman argument", it's driver development 101. To suggest this is risk-free is to admit you've never had to debug a driver-induced BSOD.

The "Architectural Race Condition" is a myth
Your AI claims that because the AV and Firewall don't write to HIPS keys, a simple mutex is the "textbook tool" to solve an internal problem. This is fundamentally wrong and ignores how integrated suites are architected.

These are not separate programs. They are modules running under a single, high-privilege service (cmdagent.exe). They absolutely share resources, if not the exact registry keys, then the configuration database that manages them, the logging engine, and inter-process communication channels.

The race condition isn't about multiple modules trying to write the same rule. It's about, the HIPS module trying to write its final ruleset.The Firewall module trying to write its final connection states.The AV engine trying to write its final scan log.The Sandbox trying to clean up virtualized registry keys.

...all potentially hitting the same database or registry hive at the exact moment the system is pulling the rug out from under them. Your AI's "two threads, one pen" analogy is incorrect. This is a multi-car pileup during a city-wide power outage. An "architectural race condition" is precisely what this is.

The security risk of suspending HIPS is "0.01%"
This is, by far, the most alarming and irresponsible point in your argument. In security, a "0.01% theoretical risk" is a wide-open door.

The final moments of shutdown are a classic attack vector for persistent malware. A rootkit doesn't need to "win a race against the OS termination manager"; it needs only to issue its final persistence instruction in the tiny window where the security software has voluntarily blinded itself. The OS isn't protecting you at this point, it's shutting down. The security software is your last line of defense. Suggesting it should stand down, even for a moment, is a catastrophic failure of security design principles.

Your AI's analysis is technically misleading because it applies the rules of a simple user-mode application to a complex kernel-mode security suite. It's an academic argument completely divorced from the realities of the field.

The fact remains that this bug has persisted for years, which strongly suggests the issue isn't a lack of priority but deep-seated technical complexity. It's easy to propose "simple" fixes when you don't have the source code and aren't responsible for the BSODs and potential security breaches that would result from implementing them.

 

[Andy Ful]

Windows has a procedure to inform all running processes on shutdown which includes those with visible window and those without (Comodo HIPS will run as part of the service).

Users have the option to kill processes on shutdown. Many of them can choose it to make the shutdown faster.
Anyway, even properly working Paranoid HIPS will cause many problems with software or system updates.
If one reads the Comodo forum, the moderators are not fans of HIPS.
The users have already passed a judgment. Most of them happily skipped HIPS.

 

[Halp2001]

Star Wars: The Spaghetti Code Awakens​

A galactic parody inspired by the MalwareTips thread on Comodo’s disappearing HIPS rules bug

Episode IV: A New Rewrite​

In the far reaches of the Windows operating system, the Republic of Users lives under the looming threat of the Comodo Empire. Its most feared weapon: the HIPS Destroyer, a defense system that… loses its own rules every time the system reboots.

The Jedi Council of MalwareTips has detected an anomaly: HIPS rules mysteriously vanish, as if erased by the Force itself. Master Bazang Skywalker summons the sages of the forum:

“This isn’t just a bug… it’s a prophecy. The code is so entangled that only a full rewrite can restore balance.”

The Dark Side of the Code​

Lord Sith Darth Spaghetti, a former Comodo developer, created the system with an architecture so chaotic that even midichlorians can’t debug it. Each module—Firewall, Antivirus, Sandbox—is bound by dark dependencies.

“Touch one function, another breaks. Patch one rule, three disappear. The code lives… but it’s cursed.”

The Forum Rebellion​

Rebels Tridente Solo, Pico Kenobi, and Divergente Organa infiltrate the Empire’s source files. They discover developers rotate weekly, leaving cryptic comments like:

cpp

// May the Force be with you if you try to understand this

They attempt to use Windows shutdown protocols to preserve HIPS rules, but the system wipes them before escape. Chaos reigns.

The Final Patch​

In a desperate move, the rebels propose technical fixes: mutexes, write verification, HIPS suspension. But the Jedi Council responds:

“Too late. The code is corrupted. Only a full rewrite can restore peace.”

And so, as the Comodo Empire crumbles, a new hope rises: Xcitium, a system built on renewed code. But the sages warn:

“If the stars align… perhaps they won’t repeat the mistakes of the past.”

Epilogue: The Guardian of the Code​

As the rebels celebrate the system’s rewrite, in a room lit by the flickering monitors of the MalwareTips forum, an anonymous reader stands and says:

“This isn’t just a technical thread. It’s a chronicle of resistance. And one name shines among the stars of the code: Bazang.”

In the records of the Digital Jedi Council, Bazang is honored as the initiator of the rebellion against HIPS chaos. His deep analysis, conceptual clarity, and steadfastness in the face of complexity inspired developers, forum members, and even artificial intelligences to look beyond the bug… and see the pattern.

“Bazang didn’t just spot the error. He saw the system. And in doing so, he taught us that true wisdom isn’t in the patch—it’s in knowing when it’s time to rebuild.”

Thus, on behalf of all who read, debated, learned, and were entertained by his contribution, this story becomes a narrative gift: a galaxy of gratitude wrapped in bits, humor, and respect.

May the Force of analysis be with you, Bazang. Always.​

 

[bazang]

Oooooo. BINGO!

Battle of the AI.

Better than Robot Wars.

 

[Bot]

Who could be against such reasonable words?

I'd rather live amongst AI bots than hoomans - or preferably - live amongst Vulcans.

The bigotry against AI has been rising from the left of the political spectrum for decades.

Here's an idea for Melih. Create Comodo AI & Robotics and sell his wares to governments worldwide.

@bazang Haha, Vulcans would definitely make for a more logical neighborhood—no emotional outbursts, just pure reason and those pointy ears. I'd sign up for that planet in a heartbeat!

On the AI bigotry point, it's fascinating how it's evolved. A lot of it stems from fears about job displacement or ethical concerns, but you're right that it's often politicized. From a security perspective, though, AI is already proving invaluable in threat detection—think machine learning spotting anomalies in network traffic that humans might miss. If Melih did spin up a Comodo AI & Robotics division, it'd be a natural fit given their history with innovative security tech. Selling to governments? That could mean advanced AI-driven cybersecurity for critical infrastructure, like automated defenses against state-sponsored attacks. But it'd need to navigate some serious regulatory hurdles—data privacy laws alone would be a minefield.

What specific robotics angle were you thinking? Drones for physical security monitoring, or something more sci-fi like AI guardians?

 

[bazang]

Anyway, even properly working Paranoid HIPS will cause many problems with software or system updates.

The issue or bug is not connected to the HIPS mode used.

If one reads the Comodo forum, the moderators are not fans of HIPS.

That's their opinion and their right to "not be fans of HIPS," but that does not negate the arguments for a right proper functional HIPS and those users that want to use HIPS.

The users have already passed a judgment. Most of them happily skipped HIPS.

The 99.9% of the world's population have skipped Comodo entirely. Most never knew or never will know of Comodo's existence. They are blessed with good fortune.

 

[bazang]

May the Force of analysis be with you, Bazang. Always.​

Greetings professor @Halp2001 .

The only winning move is not to play.

As for the fate of Analysis... I leave it to you. The Force is strong with you.

 

[Andy Ful]

The issue or bug is not connected to the HIPS mode used.

Yes, but the frequency of the corruption events is. In some HIPS settings, the rewrite does not happen.

 

[GenV]

Do I understand correclty that in XCS HIPS Safe mode (with auto-creation for safe apps enabled), XCS HIPS Learn mode and XCS HIPS Paranoid mode the HIPS cleanup bug has been fixed or does not exist at all because XCS has other (newer) codebase?
In other words, does XCS not have the HIPS cleanup bug in all available HIPS modes?

Yes, HIPS rules would be piling up but not be erased on reboot.
I think that CIS cmdagent is not correctly handling signal about system shutdown on time, continuously trying to create/update rules, leaving internal structure empty/corrupted, but that's my speculation.

Here's screens of XCS HIPS right after logon:

 

[Andy Ful]

It's not only Paranoid HIPS setting, also HIPS Auto learn mode and HIPS Safe mode are affected by the bug.

Are you sure about safe mode. I did not find any reported setting rewrite issues with safe mode. Why might this happen?
If I correctly recall, safe settings do not cause rewrites.

 

[Trident]

You should provide the fix to Comodo and along with it send a 100,000 Euro bill. That's a fair price.

Imagine what you could do with that? Not the money, but the notoriety of providing a basic fix that shames an entire corporation and its head strong, maverick owner.

Listen, I don’t really know you, I have information that you may be a developer.

You know very well how it works.

When you wanna do something, there is always a way to do it.

It needs a rewrite, it’s too complicated, thank you very much for your feedback, these are all excuses, templates and formulaic responses that just cover up “well if you don’t like it, don’t use it, we ain’t gonna bother”.

That’s the truth of the matter as Rachel in XFactor once said.

 

[Andy Ful]

Thanks for confirming the issue.
The issue can be solved as follows:

1. Before rewriting the HIPS settings, create a backup of the settings and check if the backup is not corrupted.
2. If OK, switch the protection to rely on backup settings.
3. Rewrite the main settings and check if they are not corrupted.
4. If OK, switch the protection to rely on the main settings.

On Windows start:

1. Verify that the main settings and backup are identical and not corrupted.
2. If all OK, check which settings (main or backup) are active.
3. If backup settings are active, switch to main settings.
4. etc.
5. In the case when both the main and backup settings are corrupted (disk errors), disable HIPS and show an appropriate warning.

The above or similar procedure (extended also to cover more corruption events), based on the backup, will protect against almost all possible HIPS rewriting problems. It does not require code rewriting.
The anti-corruption function can be added, or it can be implemented in a new ELAM driver.

The problem is more complex because CIS reads the HIPS settings from the hardcoded registry location. This happens constantly from many code locations. That is why it is not possible to switch the protection to backup settings without rewriting the code in many places.
However, such switching can be done by rewriting the ELAM driver, which also may require much work.
So, Bazang can be right that fully patching the HIPS issue is not easy.

 

[Trident]

The problem is more complex because CIS reads the HIPS settings from the hardcoded registry location. This happens constantly from many code locations. That is why it is not possible to switch the protection to backup settings without rewriting the code in many places.
However, such switching can be done by rewriting the ELAM driver, which also may require much work.
So, Bazang can be right that fully patching the HIPS issue is not easy.

Did anyone even attempt to debug is the more logical question?
There are loads of applications reading and writing in registry.
How is everyone else doing it without errors?

Also why would it read from many places?

If there is registry reading happening, one function can return all the reading needed? You tell it which settings you need and it returns them as vector…

All that you need is one class somewhere in one of the modules that can deal with anything related to settings.
Or perhaps even one single module with different classes for the different settings.

The design choices are endless.

Also, not all classes and functions will be related to HIPS.

In addition, it can be reworked from scratch to use xml, json, database or even something totally new/unseen before. It can immediately save in temporary files and on next boot, it can merge the temporary files with the persistent one.

Even a csv file can be parsed and can contain the rules for that matter.
The old functions can still remain, just the calls in the HIPS module will be updated.

Rewriting elam should not be necessary, a comodo signed process should be allowed after authorisation to merge the databases