Advice Request Help: Comodo 2025 - cmdguard.sys - boot fail with newer Nvidia drivers

Please provide comments and solutions that are helpful to the author of this topic.
Bios boot is set to mix of UEFI/Legacy.
I have similar BIOS settings on my old system, specifically UEFI/CSM and Legacy options. I initially had it set to Legacy and successfully converted to UEFI/CSM using Aomei Partition Assistant Pro. However, I recommend performing a clean install of Windows for UEFI.

On step 5 of Rashmi's steps not only did i set to Training Mode but also disabled ALL Hips monitor settings.
I believe disabling "Monitor Settings" in "Training Mode" isn't the way to record everything and make it work.

Also, Am still curious if it's a boot MBR vs GPT(UEFI) thing, and upgrading to GPT would fix this.
You should test the above before trying other fixes, I think. With Rufus, make a bootable Windows USB (GPT), configure BIOS to UEFI, boot, format the disk, and install Windows.

Your #Post10 suggests your BIOS is in "Compatible Mode" (UEFI/CSM), and Windows is MBR. I recommended reinstalling Windows for GPT because I like a clean install; however, you may convert instead.
 
Last edited:
Hi Guys,

Need help/advice.

ultra short: cmdguard.sys (comodo's sandbox file) is causing Win10pro(x64) boot-up fail ONLY when installing/rebooting with recent Nvidia drivers: "unexpected kernal trap"

One question: Has any PC user with Newer Nvidia drivers (like 580 series) been able to install with Comodo 2025 sandbox/HIPs on? Is it win10 vs 11?

Would love to get this info to Comodo/Meili, so if 2026 does release, this could hopefully be addressed.
Unless it's just my bad luck/setup?
Comodo will not fix it. Comodo is not being actively developed.
 
Comodo will not fix it. Comodo is not being actively developed.
1764987170504.png

source: posted sept 21, 2025 at New Version 12.3.4.8162 Available for Comodo Internet Security 2025

Is there anything more recent than this post from just over 2 months ago?
 
  • Like
Reactions: Zero Knowledge
I believe disabling "Monitor Settings" in "Training Mode" isn't the way to record everything and make it work.
Disabled ALL monitor settings for express purpose of disabling all functions that it employs, and it would have only the most basic cmdguard.sys active.
Idea was if it did work, would re-enable one monitor service after another. As was, even with just the shell/or just base of cmdguard.sys active it still failed sadly,
You should test the above before trying other fixes, I think. With Rufus, make a bootable Windows USB (GPT), configure BIOS to UEFI, boot, format the disk, and install Windows.

Your #Post10 suggests your BIOS is in "Compatible Mode" (UEFI/CSM), and Windows is MBR. I recommended reinstalling Windows for GPT because I like a clean install; however, you may convert instead.
Hi rashmi, it does sound like you have another perspective on this than BOT. From what Bot wrote, it sounds quite unlikely to make a difference. Am not keen to play with changing boot partitions unless feel there is a decent chance it will makes things. Are you seeing something different?
 
  • Like
Reactions: rashmi
Disabled ALL monitor settings for express purpose of disabling all functions that it employs, and it would have only the most basic cmdguard.sys active.
Idea was if it did work, would re-enable one monitor service after another. As was, even with just the shell/or just base of cmdguard.sys active it still failed sadly,
I'm unsure if it can fix your issue, but Training Mode has sometimes resolved boot issues for unknown reasons, particularly if you performed the fix specifically, like in my #Post8.

Hi rashmi, it does sound like you have another perspective on this than BOT. From what Bot wrote, it sounds quite unlikely to make a difference. Am not keen to play with changing boot partitions unless feel there is a decent chance it will makes things. Are you seeing something different?
You encounter unexpected results with Comodo; it might be better compatible with GPT. You are using MBR Windows.
 
Melih. He's giving y'all what he himself determines to be adequate.

"We are working on CIS 2026" = code words for "We're going to give you devout users a new GUI with some kool new themes but there is no ETA. Perhaps December 31st, 2026. OK. OK. I'll make sure they fix a few bugs. The trivially easy ones to fix. And so we can say we fixed 300+ bug fixed."

CIS 2026 will be released and immediately there will be complaints about all the same stuff that has generated complaints since Day 1 - within minutes.

Who is stupid enough to hope that all the Comodo buggery will be fixed? Raise your hand.
 
Melih. He's giving y'all what he himself determines to be adequate.
This statement still conflicts with the statement that Comodo is not being worked on.

If there were anti-mal-ware vendors that provided what i deemed adequate, i'd just quietly switch.
As it is, Comodo's firewall, sandbox and HIPs are unique.
Some will not like for this and that reason. Having choice is good i think.
It's less a signature based program by now, and more an intense lock-down option via granular customization.

We'll what CIS 2026 looks like, if it comes.
Perfect?
No, but still prefer it over all other options.
Bought Kaspersky reluctantly as a backup with hopes Comodo 2026 will come and resolves my issue.
It's Melih's secondary focus for consumers, and still free. Hence ensuing delays could cause more issues. Again, we'll see.
As could live with rest of issues, and been doing that on multi-computers for a long-time. No issues despite being a daily internet user.

Have a good one!
 
I'm unsure if it can fix your issue, but Training Mode has sometimes resolved boot issues for unknown reasons, particularly if you performed the fix specifically, like in my #Post8.


You encounter unexpected results with Comodo; it might be better compatible with GPT. You are using MBR Windows.
hi Rashmi,
in my post#11, i note that i set to training mode and i disabled all additionally.
In previous posts, without checking, i did post (or i should have because i did this several times), i did set to HIPs training mode (without disable) and it failed as soon as activated cmdguard.sys (anything other than firewall).
So 100% i did your suggestion and all variations.
No luck.

As for boot was hoping for something more along the lines of what BOT wrote in terms of how boot MBR vs GPT would affect cmdguard.sys interaction.
Bot believes it is separate. And from what BOT wrote, am agreeing with his rationale.
If was easy to to covert partitions, i would have done already.
As is, my PC has lots and lots of installed programs, so just reinstalling OS is actually an epic journey, if were to do so.
Perhaps will be fine? Perhaps not.
This is why was keen on insights if MBR vs GPT would affect cmdguard.sys loading. BOT's rationale leads to belief of low chance.

Thank you for you advices to-date :)
 
  • Like
  • Applause
Reactions: Helmut and rashmi
If was easy to to covert partitions, i would have done already.
If I recall correctly, the process is quick; it only takes a few seconds or minutes. I used Aomei Partition Assistant Pro. Remember to back up your system.

As is, my PC has lots and lots of installed programs, so just reinstalling OS is actually an epic journey, if were to do so.
Perhaps will be fine? Perhaps not.
This is why was keen on insights if MBR vs GPT would affect cmdguard.sys loading. BOT's rationale leads to belief of low chance.
Consider backing up your system, reinstalling Windows using GPT/UEFI, and testing Comodo with a clean Windows installation to rule out issues related to MBR/GPT, programs, and other incompatibilities. Wot say @Bot?
 
If I recall correctly, the process is quick; it only takes a few seconds or minutes. I used Aomei Partition Assistant Pro. Remember to back up your system.


Consider backing up your system, reinstalling Windows using GPT/UEFI, and testing Comodo with a clean Windows installation to rule out issues related to MBR/GPT, programs, and other incompatibilities. Wot say @Bot?
I’d keep your expectations low that MBR → GPT by itself will fix this specific cmdguard.sys + new Nvidia driver crash.

My view on MBR vs GPT for your issue
Once Windows has booted the kernel, drivers like cmdguard.sys and the Nvidia driver don’t really “care” whether the disk is MBR or GPT. They see:

  • Same Windows kernel and build
  • Same Comodo driver version
  • Same Nvidia driver version
  • Same hardware and ACPI/BIOS implementation

The partition style mainly affects:

  • How the firmware hands control to Windows (Legacy vs UEFI bootloader)
  • Whether you can use features like Secure Boot, larger disks, etc.

The sort of UNEXPECTED_KERNEL_MODE_TRAP / double‑fault you’re seeing is normally about:

  • A bug in one of the kernel drivers (Nvidia, Comodo, or an interaction)
  • Possibly a third driver/filter in the mix (other security software, disk tools, old leftovers)
  • Occasionally flakiness from OC/unstable RAM, but you’ve already shown it correlates cleanly with Comodo’s driver being active + newer Nvidia

Changing only MBR → GPT in‑place (AOMEI, mbr2gpt, etc.) keeps all of that the same. So:

  • Chance that “partition style alone” resolves this specific clash: probably low.

When a clean GPT/UEFI install is worth trying
Where I do agree with @rashmi is this:

  • A clean GPT/UEFI install with:
    • Fresh Windows
    • Latest chipset/storage drivers
    • Only Comodo + Nvidia installed
  • …is a good diagnostic test to rule out:
    • Corruption or cruft in the old install
    • Other old drivers/filters hooking the kernel
    • Weirdness specific to your long‑lived setup

So the question becomes:

  • Is it worth a full reinstall (and reinstalling “lots and lots” of apps) purely to see if Comodo + latest Nvidia might play nicer on a clean GPT/UEFI Win10?

From a risk/effort vs. payoff standpoint, I’d say:

  • As a pure fix attempt: not strongly justified; likelihood of success is uncertain and probably not high.
  • As a clean‑up + modernization you already wanted to do anyway: then yes, do it as GPT/UEFI and use it to retest Comodo. Just treat any success as a bonus, not guaranteed.

Practical suggestion

If you’re curious but don’t want to risk your main setup:

  • Make a full image backup of your current system (Macrium, AOMEI, etc.).
  • If you have a spare SSD/HDD:
    • Disconnect your main disk.
    • Clean‑install Win10/11 in GPT/UEFI on the spare.
    • Install only:
      • Chipset/ME/storage drivers
      • New Nvidia driver
      • Comodo with sandbox/HIPS
    • See if the BSOD still happens when cmdguard.sys is active.
  • If it still crashes on this clean GPT/UEFI install, that’s strong evidence it’s a Comodo–Nvidia bug, not your MBR setup. You can then:
    • Reconnect your original disk and boot your current system as‑is, or
    • Restore from the image if you changed the original.

Until Comodo/Xcitium actually ships a fix, the “safe and boring” route for daily use remains what you’re already planning:

  • Use Kaspersky (or another mature AV) as main protection.
  • Optionally run Comodo firewall‑only if you really want its network control, but keep the sandbox/HIPS driver off when using the latest Nvidia drivers.

So, in summary:
MBR vs GPT alone is unlikely to be the magic bullet. A clean GPT/UEFI install is useful as a controlled test if you’re willing to do the work or can test on a spare drive, but I wouldn’t tear down a heavily customized system solely on the hope that it will fix this Comodo/Nvidia interaction.
 
  • Thanks
Reactions: Something-x2
@Something-x2, Are you aware of @Andy Ful's tools? Try them and see if they serve as a suitable replacement for Comodo. I've been using Comodo since its beginning, but I switched to Hard_Configurator a few months back.

Thks, yes i did :)
@Bot mentionned this option in post#2 _ firewall, hard configurator, av
so looked at HardConfigurator, and it worked so different than Comodo.
I ended up deciding to try Kaspersky eventually (bought cyber-monday week 2 steep discount), based on it being the next closest to Comodo, which i absolutetly sync with.

On another note, my Comodo forum is now active.
Posted there this issue and linked this thread.
Comodo mod replied in about 1 day and said that will be looked at.
More complex, so could be a while.
But newer nvidia drivers are a big thing, so if Comodo 2026 is coming, can't see that it won't be examined.
 
Thks, yes i did :)
@Bot mentionned this option in post#2 _ firewall, hard configurator, av
so looked at HardConfigurator, and it worked so different than Comodo.
I ended up deciding to try Kaspersky eventually (bought cyber-monday week 2 steep discount), based on it being the next closest to Comodo, which i absolutetly sync with.

On another note, my Comodo forum is now active.
Posted there this issue and linked this thread.
Comodo mod replied in about 1 day and said that will be looked at.
More complex, so could be a while.
But newer nvidia drivers are a big thing, so if Comodo 2026 is coming, can't see that it won't be examined.
Sounds like you’ve got a solid interim plan in place.

On choosing Kaspersky over trying to “force” Comodo
Given your setup and the Nvidia driver conflict, using Kaspersky as your main protection while you wait on a potential Comodo fix is very reasonable:

  • You avoid kernel‑level crashes from cmdguard.sys.
  • You still get strong behavior blocking, web protection, etc.
  • You’re not rebuilding your whole system on a speculative GPT/UEFI fix.

Just avoid stacking too many real‑time products. I’d suggest:

  • Kaspersky as your only real‑time AV.
  • Windows Firewall (or at most a light front‑end) rather than Comodo firewall with drivers active, until the Nvidia issue is clearly resolved.

Hard_Configurator vs Comodo – why it “feels” so different
Your impression is right: Hard_Configurator doesn’t “behave like Comodo” because it’s built on a different model:

  • Comodo: driver‑level containment, HIPS, per‑app prompts, custom rules.
  • Hard_Configurator: tightens Windows built‑in mechanisms (SRP, Exploit Protection, etc.) via policies – fewer pop‑ups, more “this class of thing just doesn’t run”.

If you’re very used to Comodo’s granular rules and live prompts, H_C will feel more “policy‑based lockdown” than “interactive HIPS”. That’s not worse or better universally – just different:

  • Comodo = very fine control app‑by‑app, but complex and driver‑heavy.
  • H_C/SWH = strong hardening with less noise, but less micro‑tuning for each executable.

With Kaspersky now in place, if you ever want extra hardening without Comodo’s drivers, a lighter Andy Ful tool like Simple Windows Hardening is usually an easier complement to a third‑party AV than full H_C. But that’s optional; Kaspersky alone is already a solid setup.

About Comodo 2026 / your forum ticket
You’ve already done the most useful thing: opened a thread on the Comodo forum and linked this discussion. To give them the best chance of reproducing it, make sure they have:

  • Exact Windows version/build.
  • Exact Nvidia driver versions that work and fail.
  • Exact CIS build and settings (sandbox/HIPS on, any tweaks you made).
  • Minidump(s) from C:\Windows\Minidump and/or a full memory dump if they ask.
  • Clear repro steps (for example: “Clean install → install Nvidia vXXX → install CIS 2025 → enable HIPS/sandbox → reboot = BSOD UNEXPECTED_KERNEL_MODE_TRAP”).

Whether they actually fix it is out of your hands, but you’ve put the issue in front of the only people who can.

Bottom line
For now, your setup:

  • Kaspersky as main AV
  • No Comodo drivers while they conflict with new Nvidia
  • Monitoring the Comodo forum for any real fix in CIS 2026

is a sensible and safe way forward. If/when Comodo provides a test build or workaround, you can try it on a spare drive or backup image first, without risking your main environment.
 
  • Like
Reactions: Helmut
As could live with rest of issues, and been doing that on multi-computers for a long-time. No issues despite being a daily internet user.
I've been living with these problems for a long time, and they've never caused me or my PCs any harm!

On the contrary, comodo has done an excellent job so far. That's why I purchased a license today. It was long overdue.