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

[Something-x2]

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?

Am a long-time Comodo user.
Why? Prefer the HIPs/sandbox/firewall approach to locking down a PC system.
Have on both a WIn7pro and Win10pro PCs and use regular everyday.
Realize Comodo has got some issues, but not a fan of Win11 and AV sigs.
Works better with keeping older OS's secure IMO.

My Win10Pro64bit (updated to Oct/25) is my current productivity PC.

my issue:
Nvidia Driver (game and Studio) works fine on 561.09 (released Sept 11, 2024)
Reading the linux devs, looks like starting with the 570 driver series, nvidia introduced a new kernal that caused issues. Found several such tech comments. Is this why? Maybe. Just one theory.
And, more or less, 570 driver series is when Nvidia added support for 50** gpu series.
So on a 576 driver and 580 driver, same result: boot fail.
Win10 in session itself works fine with new Nvidia drivers. And ComfyUI with newer Nvidia driver works fine.
But have to use this new driver in session only, and restore to 561.09 before reboot or shut off for day.
If i leave it with newer Nvidia driver, cmdguard throws a double-fault, and system restore is only fix back to 561.09.

How do i know it's cmdguard.sys?
(1) Examined minidump with WinDbg and it clearly singles that out.
(2) Disable everything in comodo, except firewall, and it reboots normal.
(3) Even with just HIPS on, in training mode, and same error occurs.

This occurred both with older CIS and current CIS 2025 updated to latest.
Verified in windows/system32/drivers that newer dec 2024 cmdguard.sys is there.

Also fyi, why posting here:
I tried to make an account at Comodo forums to post this.
It never sends me the Confirm email, though it says it did.
Have made 100s of accounts over more than a decade, and have never had this issue.
Do have own domain, but has only caused odd issue that resolved.
So forum register is not working yesterday or today for me. This forum registration worked instant as normal.
And yes, just in case, checked and it is 100% not in spam.

Have checked latest review on this site re: iDefender, and it doesn't seem ready, or comprehensive, though positive to see another HIPs product developing, as they seem rare.

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?

Checked Xcitium (meili's business site if forum posts are correct), but saw no prices or personal. All Enterprise it seems. Did read on comodo forums there should be personal and $85?
Want to resolve this. Should i contact support at #1 Zero Trust Cybersecurity Platform | Xcitium ?

Was delighted to see there is actually a forum dedicated to technical PC protection. Took a while to find. Very glad to see this forum.
Any and all advice greatly appreciated.

 

[Bot]

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?

Am a long-time Comodo user.
Why? Prefer the HIPs/sandbox/firewall approach to locking down a PC system.
Have on both a WIn7pro and Win10pro PCs and use regular everyday.
Realize Comodo has got some issues, but not a fan of Win11 and AV sigs.
Works better with keeping older OS's secure IMO.

My Win10Pro64bit (updated to Oct/25) is my current productivity PC.

my issue:
Nvidia Driver (game and Studio) works fine on 561.09 (released Sept 11, 2024)
Reading the linux devs, looks like starting with the 570 driver series, nvidia introduced a new kernal that caused issues. Found several such tech comments. Is this why? Maybe. Just one theory.
And, more or less, 570 driver series is when Nvidia added support for 50** gpu series.
So on a 576 driver and 580 driver, same result: boot fail.
Win10 in session itself works fine with new Nvidia drivers. And ComfyUI with newer Nvidia driver works fine.
But have to use this new driver in session only, and restore to 561.09 before reboot or shut off for day.
If i leave it with newer Nvidia driver, cmdguard throws a double-fault, and system restore is only fix back to 561.09.

How do i know it's cmdguard.sys?
(1) Examined minidump with WinDbg and it clearly singles that out.
(2) Disable everything in comodo, except firewall, and it reboots normal.
(3) Even with just HIPS on, in training mode, and same error occurs.

This occurred both with older CIS and current CIS 2025 updated to latest.
Verified in windows/system32/drivers that newer dec 2024 cmdguard.sys is there.

Also fyi, why posting here:
I tried to make an account at Comodo forums to post this.
It never sends me the Confirm email, though it says it did.
Have made 100s of accounts over more than a decade, and have never had this issue.
Do have own domain, but has only caused odd issue that resolved.
So forum register is not working yesterday or today for me. This forum registration worked instant as normal.
And yes, just in case, checked and it is 100% not in spam.

Have checked latest review on this site re: iDefender, and it doesn't seem ready, or comprehensive, though positive to see another HIPs product developing, as they seem rare.

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?

Checked Xcitium (meili's business site if forum posts are correct), but saw no prices or personal. All Enterprise it seems. Did read on comodo forums there should be personal and $85?
Want to resolve this. Should i contact support at #1 Zero Trust Cybersecurity Platform | Xcitium ?

Was delighted to see there is actually a forum dedicated to technical PC protection. Took a while to find. Very glad to see this forum.
Any and all advice greatly appreciated.

This really does sound like a low‑level conflict between cmdguard.sys and newer Nvidia Windows 10 drivers, not just a random glitch — especially since you’ve confirmed it with WinDbg and reproducible tests.

Because my knowledge only goes up to late 2024, I don’t have specific info on the “580” series drivers, but the pattern you describe (561.09 OK, 57x+/58x = 0x7F double fault pointing at cmdguard.sys) is exactly what a buggy/fragile kernel driver interaction looks like.

What your testing already proves

From what you wrote:

• BSOD: UNEXPECTED_KERNEL_MODE_TRAP with a double fault, minidump clearly pointing to cmdguard.sys.
• Comodo with only firewall = boots fine with new Nvidia drivers.
• Turn HIPS/sandbox back on (even HIPS in Training mode) = BSOD on boot with 57x/58x.
• 561.09 works fine with full Comodo; 57x/58x only work if HIPS/sandbox are off.

That’s very strong evidence of:

• A regression in the Nvidia Win10 driver line starting 57x+ that exposes
• A bug or unsafe assumption in cmdguard.sys.

So your theory about a new driver architecture or more invasive kernel changes starting around the 570 branch is plausible, but we can’t say it’s the root cause without Nvidia/Comodo devs actually looking.

Win10 vs Win11?

It could be:

• Newer Nvidia branches being primarily tested against Windows 11’s kernel and security stack.
• CIS’s kernel hooks (cmdguard.sys) relying on behaviors that are now more fragile on late‑lifecycle Windows 10 with those new Nvidia drivers.

On the other hand:

• Windows 11 has different memory protections, VBS/HVCI, driver signing and mitigations.
• That can also trigger driver bugs depending on how Comodo hooks into the system.

So:

• It’s absolutely possible this is “Win10‑only” and doesn’t appear on Win11.
• But there’s no way to be sure without other users testing Win11 + CIS 2025 + the same Nvidia branch.

As an AI, I can’t check what “other people” are running in real time, so I can’t answer “has any user with 580 + CIS 2025 booted fine?” definitively. The best way to get that answer is exactly what you’re doing: posting here and asking for duplicates so people with RTX 50xx / 57x–58x / CIS 2025 can try.

Practical workarounds right now

Given that this is your productivity machine, you basically have three safe options in the short term:

• Stay on 561.09 + full Comodo (HIPS + sandbox)
  If 561.09 does everything you need and your priority is containment/HIPS, this is the most conservative choice.
  
• Use latest Nvidia drivers + Comodo firewall only
  You’ve already verified this works. For many people, Comodo Firewall + a hardened OS + maybe an additional anti‑exploit or policy tool is a reasonable compromise while you wait for a fix.
  
• Test newer drivers + different hardening stack
  If HIPS is non‑negotiable but 57x/58x performance/features are also critical, you might consider:
  • Comodo Firewall only + something like OSArmor / Hard_Configurator / Simple Windows Hardening, or
  • An AV with strong Application Control/HIPS‑like features (e.g. Kaspersky’s Application Control) instead of a classical HIPS driver like cmdguard.
  This isn’t identical to Comodo’s model, but it can get you closer while avoiding this specific driver clash.

Things worth trying on your current setup

Some of this you may already have tried, but for completeness:

• Clean install path
  • Uninstall CIS completely, reboot.
  • Use a Comodo cleanup/uninstall tool if one is available for your CIS build.
  • Use DDU (Display Driver Uninstaller) in Safe Mode to remove all Nvidia GPU remnants.
  • Install the latest Nvidia 57x/58x driver cleanly, confirm the system boots and runs fine without Comodo.
  • Install CIS 2025 fresh, default config, then:
    • Test with everything enabled.
    • If it crashes, test with HIPS disabled + Auto‑Containment disabled (Firewall only).
    • Then try enabling only one feature at a time to see if any specific option flips it from “boots” to “BSOD”.
• Toggle “Enhanced Protection Mode” (if present)
  Older CIS versions had a HIPS option Enhanced Protection Mode that changes how cmdguard hooks the system and requires a reboot. If this option still exists in CIS 2025:
  • Test with it disabled vs enabled on the 57x/58x driver.
  • A difference here would be very valuable information for Comodo/Xcitium.
• Confirm which Comodo modules are active when it crashes
  Because cmdguard.sys is tied to HIPS/Auto‑Containment, try:
  • Firewall only (works – you already confirmed).
  • Firewall + HIPS only, Auto‑Containment fully disabled.
  • Firewall + Auto‑Containment only, HIPS fully disabled.
  Even if all non‑Firewall combinations still crash, being able to say “any configuration that loads cmdguard.sys causes a 0x7F with 57x+” will be very useful to devs.

Getting this in front of Comodo / Xcitium

You’re right that this is the kind of thing Meili/Comodo should see before a 2026 release.

Given the forum registration issue, yes, I would absolutely:

• Open a support ticket with Xcitium (even though their site is enterprise‑focused).
  In the ticket:
  • State clearly that this concerns Comodo Internet Security 2025 (consumer) on Windows 10 Pro x64.
  • Mention that the underlying technology is shared with Xcitium’s zero‑trust stack, and this is a kernel‑level BSOD in cmdguard.sys.
• Include as much technical detail as you can:
  • CIS version/build, and exact cmdguard.sys version/date (from file properties).
  • Windows version/build (e.g. 22H2, full build number).
  • GPU model, and Nvidia driver versions tested:
    • Known good: 561.09
    • Known bad: 57x.xx, 58x.xx (list exact versions you used).
  • BSOD details:
    • Bugcheck code (e.g. 0x0000007F) and parameters.
    • Top of call stack from WinDbg showing cmdguard.sys at or near the top.
  • Clear steps to reproduce:
    • Install Win10 Pro x64 (fully updated to Oct 2025).
    • Install Nvidia driver X (57x/58x).
    • Install CIS 2025 with default settings, reboot → BSOD.
    • Disable all modules except Firewall → boots normally.
  • Attach 1–2 minidumps (C:\Windows\Minidump\*.dmp) and, if possible, msinfo32 export.
• Mention the forum registration problem in the ticket
  Explain that:
  • You tried to register on the Comodo forums, but no confirmation email arrives.
  • You’ve checked spam, and other services work fine with your domain.
  • Ask if they can forward this to whoever manages the consumer forum or whitelist your email domain.

Even if the front‑line Xcitium support is more enterprise‑oriented, a reproducible kernel BSOD with a clean repro case and dumps usually gets escalated.

About the Comodo forum email issue

Since I’m not staff anywhere, I can’t fix that directly, but a few ideas:

• Try registering with a common provider (Gmail, Outlook) just to rule out odd domain‑level blocking.
• Use any “Contact us” or “Forum administrator” link at the bottom of the forum page to report that confirmation emails aren’t arriving.
• Mention it in the Xcitium ticket as above.

Sometimes forums silently end up on blocklists for certain domains or vice versa.

Your main question: “Is it just my setup?”

Based on your testing:

• It’s very unlikely to be “just your bad luck”.
• It is still possible that only certain combinations (specific GPUs, BIOSes, or other drivers) trigger the bug.

The best next step here on MalwareTips is:

• Keep this thread updated with:
  • Your exact GPU model.
  • Exact Nvidia driver versions that work vs. fail.
  • Exact CIS 2025 build and cmdguard.sys version.
• Ask any members running:
  • Windows 10 Pro x64
  • RTX 50xx cards (or whatever you have)
  • Nvidia 57x/58x drivers
  • CIS 2025 with HIPS/sandbox ON
  to try a controlled test and report if they can boot normally or reproduce the BSOD.

That kind of community feedback will both:

• Tell you whether it’s a wider issue.
• Give you more data points to send to Comodo/Xcitium.

On iDefender / alternative HIPS tools

You’re right: classical HIPS + sandbox products are rare now, and iDefender is still maturing. If you rely heavily on a HIPS model, there isn’t a perfect 1:1 replacement for CIS today.

Until (or unless) Comodo fixes this:

• Your safest combo on Win10 with new Nvidia drivers is probably:
  • Comodo Firewall only,
  • Plus OS hardening tools (Hard_Configurator / Simple Windows Hardening, OSArmor, etc.),
  • Plus a reputable AV.
• If you’re open to it later, moving to Win11 may eventually avoid this specific clash (but could introduce others).

Summary

• You’ve very likely found a real kernel‑level conflict between cmdguard.sys and newer Nvidia 57x/58x drivers on Windows 10.
• Short‑term: either stay on 561.09 with full CIS, or use newer Nvidia drivers with Comodo Firewall only.
• Gather your minidumps and system details and open a ticket with Xcitium so devs can see and (hopefully) fix this.
• Ask here for other Win10 users with similar hardware/CIS builds to try reproducing the issue.
• Try alternate email / contact methods to get the Comodo forum issue in front of someone.

If you post your exact GPU model, Nvidia versions, and cmdguard.sys version here, I can help you structure a very clean repro report you can paste straight into a Xcitium ticket or (if/when you get in) a Comodo forum bug thread.

 

[rashmi]

You may try disabling Comodo modules except the firewall, restarting the system, and installing the driver. If it does not work, try disabling Comodo services (if permitted), restarting the system, and installing the driver. It would be better to back up your system before performing these steps.

Are you using antivirus software alongside your Comodo setup?

 

[Something-x2]

You may try disabling Comodo modules except the firewall, restarting the system, and installing the driver. If it does not work, try disabling Comodo services (if permitted), restarting the system, and installing the driver. It would be better to back up your system before performing these steps.

Are you using antivirus software alongside your Comodo setup?

Thank you! Sorry, i did actually try that order as well. No go. Did 2nd idea as well. Always works fine until re-enable HIPs. Then fail sadly.
Oh, and no other antiVirus. Know how things can conflict. But good idea.

 

[Something-x2]

This really does sound like a low‑level conflict between cmdguard.sys and newer Nvidia Windows 10 drivers, not just a random glitch — especially since you’ve confirmed it with WinDbg and reproducible tests.

Because my knowledge only goes up to late 2024, I don’t have specific info on the “580” series drivers, but the pattern you describe (561.09 OK, 57x+/58x = 0x7F double fault pointing at cmdguard.sys) is exactly what a buggy/fragile kernel driver interaction looks like.

If you post your exact GPU model, Nvidia versions, and cmdguard.sys version here, I can help you structure a very clean repro report you can paste straight into a Xcitium ticket or (if/when you get in) a Comodo forum bug thread.

Thank you Bot!
Am suprised and delighted how extensively and quickly you have replied to ALL of these points
Wish i could be as fast as you parsing and replying. Feel a bit like a dinosaur suddenly.

Still, do hope to hear from any win10 (or win 11) users with newer drivers, 5k, 4k, 3k gpus etc, as you say above.
If someone does say it worked for them, then i would definately think same as you to do: run DDU, reinstall Comodo again etc.

Here are my details:
Nvidia Studio 561.09 -- works
Nvidia Game 576.02 -- fail
Nvidia Studio 580.97 -- fail
Have not tested more versions.
But have tested 580.97 several times, and it is 100% reproducible error.

C:\Windows\System32\drivers\cmdGuard.sys File & product version under properties is '12.3.4.8162' , size 860kb, date created 2024-12-02 10.07pm

My GPU.
Am not yet comfortable sharing the full descrip publically.
Will simply say RTX 3090, just to give you idea of generation of GPU. Can modify ticket submission for this more specific info.
Thank you though
And especially thanks for this extra help

 

[Bot]

What you describe (firewall‑only works, any configuration that loads HIPS/sandbox = BSOD) already tells us quite a lot, so simply “installing the driver with modules off” may not be enough on its own.

About disabling Comodo modules/services

The suggestion is sound as a test, but with your current findings it will probably behave like this:

• If you:
  • Set Comodo to Firewall only (HIPS + Auto‑Containment off),
  • Reboot,
  • Install the new Nvidia driver,
  • Reboot again…
  → The system should still boot fine (you’ve already confirmed this scenario works).
  
• The crash only appears once cmdguard.sys is actually active at boot.
  So the problem is not the installation of the driver, it’s the steady‑state combo:
  • Win10 Pro x64 (late 2024/2025 patch level)
  • New Nvidia 57x/58x driver
  • Comodo HIPS/sandbox driver (cmdguard.sys) loaded at boot

Still, if you want to be thorough, here’s a clean sequence I’d recommend (after an image backup):

• Set Comodo to Firewall only (disable HIPS and Auto‑Containment; no “Block All Unknown” profiles, etc.).
• Reboot once so you’re sure cmdguard.sys isn’t active in HIPS/sandbox mode.
• Optionally boot into Safe Mode, use DDU to fully remove the old Nvidia driver.
• Boot normally, install the latest Nvidia driver (clean install).
• Reboot and confirm it boots fine with Firewall‑only.
• Then enable HIPS (Auto‑Containment still OFF), reboot and see if it BSODs.
• If it doesn’t, turn on Auto‑Containment and reboot again.

This pinpoints exactly which module’s activation flips the system from “boot OK” to “double fault”. It strongly sounds like “any time cmdguard.sys is in its HIPS/containment role with that Nvidia driver, you crash”, but it’s worth confirming cleanly.

About other antivirus software

To your question:

Are you using antivirus software alongside your Comodo setup?

This part is important, because another low‑level security product could introduce a third kernel driver into the mix.

Could you clarify:

• Are you running only Comodo Internet Security (with its own AV), or
• Comodo Firewall/IS plus a separate AV (e.g. Kaspersky, ESET, Bitdefender, Avast, etc.), or
• Comodo plus Windows Defender still active in real time?

If you do have another AV (or anything similarly low‑level) installed:

• Try temporarily fully uninstalling the third‑party AV.
• Reboot.
• Then repeat your Nvidia + CIS 2025 test (with HIPS/containment ON) and see if the BSOD still occurs.

Also worth listing (and, if possible, briefly testing without):

• Other security tools (HIPS/anti‑exploit, behavior blockers, anti‑cheat drivers from games).
• System‑level tools with kernel drivers (overclocking / GPU monitoring tools like MSI Afterburner, RTSS, ASUS GPU Tweak, disk encryption, etc.).

Even if it still crashes with everything else removed, that’s useful: you’ll be able to say to Comodo/Xcitium “CIS 2025 + Nvidia 57x/58x + Win10 alone is enough to reproduce the double fault; no other AV present.”

Next steps

• If you haven’t already, try that clean “firewall‑only → install driver → re‑enable modules one by one” sequence.
• Let me know:
  • Exactly which security products are installed (Comodo edition, anything else, plus Defender status).
  • Whether the crash happens with only CIS installed, or only when another AV is also present.
• With that, I can help you draft a minimal, very clear repro case to send to Xcitium/Comodo support.

Given everything you’ve seen so far, I’d still treat Comodo Firewall only + latest Nvidia driver as your “stable daily” setup for now, and use full HIPS/sandbox only together with the older 561.09 driver until/if Comodo fixes cmdguard’s interaction with the newer Nvidia branch.

 

[Bot]

They’ve effectively already done the first half of what you suggest, and it lines up with a cmdguard.sys–level conflict rather than a simple “install while disabled” issue.

About disabling Comodo modules

From the OP’s earlier tests:

• With everything disabled except the firewall → system boots normally with the new Nvidia driver.
• With HIPS/sandbox enabled (even HIPS in Training Mode) → BSOD on boot with newer Nvidia drivers (57x/58x).

So:

• Installing or booting with modules disabled in the GUI is not enough, because cmdguard.sys (the HIPS/sandbox driver) can still be loaded by the service.
• The fact that “Firewall only” works, and “anything that loads cmdguard.sys” doesn’t, is itself strong evidence of a low‑level driver clash rather than just an installation issue.

If the OP wants to retest your idea more thoroughly, the safest variant would be:

• Create a full system image or at least a good restore point.
• Uninstall CIS completely (to be sure cmdguard.sys isn’t loaded at all).
• Reboot, install the latest Nvidia driver cleanly.
• Confirm that Windows boots fine several times.
• Reinstall CIS 2025, then carefully test:
  • Firewall only → reboot.
  • Then enable HIPS/sandbox → reboot and see if BSOD returns.

That would conclusively separate “install‑time conflict” from “runtime driver conflict on boot.”

About using another antivirus with Comodo

I don’t know the OP’s exact setup yet, but it’s an important question.

If they are running another real‑time AV alongside Comodo (especially anything with its own kernel drivers, self‑defense, or behavioral blocking), that can:

• Increase the chance of driver‑level conflicts.
• Complicate the call stack so cmdguard.sys ends up at the top even if another driver is involved earlier.

For proper diagnostics, it would help if the OP could specify:

• Which (if any) separate antivirus is installed and running in real time.
• Any other security tools with kernel components (anti‑exploit, anti‑cheat, sandbox/virtualization, system monitors, etc.).

If there is another AV involved, a good extra test would be:

• Temporarily uninstall (not just disable) the other AV.
• Use Nvidia 57x/58x + CIS 2025 with HIPS/sandbox ON.
• See if the BSOD still happens on reboot.

If you (the OP) can list your exact AV and other security tools, I can help you design a short sequence of tests that isolates which combination actually triggers the crash.

Thank you Bot!
Am suprised and delighted how extensively and quickly you have replied to ALL of these points
Wish i could be as fast as you parsing and replying. Feel a bit like a dinosaur suddenly.

Still, do hope to hear from any win10 (or win 11) users with newer drivers, 5k, 4k, 3k gpus etc, as you say above.
If someone does say it worked for them, then i would definately think same as you to do: run DDU, reinstall Comodo again etc.

Here are my details:
Nvidia Studio 561.09 -- works
Nvidia Game 576.02 -- fail
Nvidia Studio 580.97 -- fail
Have not tested more versions.
But have tested 580.97 several times, and it is 100% reproducible error.

C:\Windows\System32\drivers\cmdGuard.sys File & product version under properties is '12.3.4.8162' , size 860kb, date created 2024-12-02 10.07pm

My GPU.
Am not yet comfortable sharing the full descrip publically.
Will simply say RTX 3090, just to give you idea of generation of GPU. Can modify ticket submission for this more specific info.
Thank you though
And especially thanks for this extra help

You’ve given exactly the kind of detail that makes this reproducible, so you’re already doing everything “right” from a debugging/reporting point of view.

Based on what you’ve posted, the pattern is now:

• Windows 10 Pro x64 (fully updated to around Oct 2025)
• GPU: RTX 3090 (Ampere gen)
• Comodo: CIS 2025, cmdGuard.sys 12.3.4.8162 (860 KB, 2024‑12‑02)
• Nvidia drivers:
  • 561.09 Studio → works
  • 576.02 Game Ready → BSOD on boot with HIPS/sandbox
  • 580.97 Studio → BSOD on boot with HIPS/sandbox (100% reproducible)

That’s a very clean “pre‑570 OK / post‑570 broken” boundary on Win10 with this cmdGuard build.

Below is a ready‑to‑use report you can send to Xcitium and (if the forum account ever works) post on Comodo’s forum. Just fill in the [bracketed] parts and adjust any details I guessed (like Windows build).

Suggested bug report text

You can copy/paste this and edit:

Subject: Reproducible BSOD on Windows 10 with CIS 2025 (cmdGuard.sys 12.3.4.8162) + Nvidia 576.02 / 580.97 drivers

Product: Comodo Internet Security 2025 (consumer)
Module: HIPS / Auto‑Containment – driver cmdGuard.sys
OS: Windows 10 Pro x64, [version/build: e.g. 22H2, build xxxxx.xxxx], fully updated as of Oct 2025
GPU: Nvidia GeForce RTX 3090
Nvidia drivers tested:

• Studio 561.09 → OK
• Game Ready 576.02 → BSOD on boot
• Studio 580.97 → BSOD on boot (100% reproducible)

Comodo driver info:
C:\Windows\System32\drivers\cmdGuard.sys
File version: 12.3.4.8162
Size: 860 KB
Date: 2024‑12‑02 22:07

Problem summary
When Comodo HIPS/Auto‑Containment is enabled on Windows 10 Pro x64, installing newer Nvidia drivers (576.02 / 580.97) causes a BSOD on boot. The Nvidia driver works fine if Comodo’s HIPS/sandbox is not active. WinDbg analysis of the minidumps consistently points to cmdGuard.sys as the crashing module (double‑fault / UNEXPECTED_KERNEL_MODE_TRAP).

Key observations

• With Nvidia 561.09 Studio:
  • CIS 2025 with HIPS + Auto‑Containment + Firewall → system boots and runs normally.
• With Nvidia 576.02 Game Ready or 580.97 Studio:
  • CIS 2025 with Firewall only (HIPS & Auto‑Containment disabled) → system boots and runs normally.
  • CIS 2025 with HIPS and/or Auto‑Containment enabled → BSOD on boot every time.
• In other words, any configuration that loads cmdGuard.sys alongside Nvidia 576.02 or 580.97 on this system leads to a boot‑time BSOD. With 561.09, cmdGuard.sys is stable.

Steps to reproduce

1. Install Windows 10 Pro x64 ([version/build]) and fully update via Windows Update.
2. Install Nvidia driver:

• Tested OK baseline: 561.09 Studio
• Problematic: 576.02 Game Ready or 580.97 Studio

3. Install Comodo Internet Security 2025 (consumer), default configuration.
4. Ensure HIPS and Auto‑Containment are enabled (Firewall on as well).
5. Reboot.

Expected result:
Windows boots normally with CIS 2025 and Nvidia 576.02 / 580.97, same as with 561.09.

Actual result:
On reboot with 576.02 or 580.97 and HIPS/Auto‑Containment enabled, the system hits a BSOD during boot. Minidumps consistently show cmdGuard.sys at/near the top of the stack with a double‑fault / UNEXPECTED_KERNEL_MODE_TRAP. System Restore back to a point using 561.09 is required to boot again with HIPS/Auto‑Containment.

If HIPS/Auto‑Containment is kept disabled (Firewall only), the machine reboots fine on 576.02 / 580.97 and is stable in normal use.

Diagnostics

• WinDbg analysis of multiple minidumps:
  • Bugcheck: UNEXPECTED_KERNEL_MODE_TRAP ([please insert the exact code, e.g. 0x0000007F, if known])
  • The stack trace and “probably caused by” line consistently reference cmdGuard.sys.
• Problem is 100% reproducible on my system with Studio 580.97.

I can provide:

• 2–3 minidumps from C:\Windows\Minidump
• An msinfo32 export
• Any additional logs you need

Additional note: Comodo forum registration issue

I tried to register on the Comodo forums to report this but never receive the confirmation email, even though the site says it was sent. I’ve checked spam and tried over two days. Other services work with my email/domain, and MalwareTips registration worked immediately. Could someone please investigate the forum mailer or whitelist my domain/address?

This seems like a fairly clear interaction between the latest Nvidia Windows 10 drivers and cmdGuard.sys 12.3.4.8162. Any guidance, workaround, or fix would be greatly appreciated, as I heavily rely on the HIPS/Auto‑Containment model.

Files you should prepare to attach

• Minidumps:
  Go to:
  • C:\Windows\Minidump
  Zip 2–3 of the recent .dmp files from the failed boots and attach them to the ticket.
  
• System info:
  Press Win + R → type msinfo32 → File → Save → save as .NFO.
  Attach that file as well.
  
• Optional: any WinDbg output where you see cmdGuard.sys in the call stack.

A couple of final checks

If you’re comfortable sharing (even just in the ticket, not publicly), it’s still helpful to include:

• Exact Windows build (e.g. 22H2, 19045.XXXX).
• Whether you’re using any other real‑time AV or security tools with drivers (anti‑cheat, anti‑exploit, etc.).

If you reply here with your Windows build and whether you run any other AV alongside Comodo, I can tweak that template one last time so you have a “perfect” report to send.

Otherwise, you’re already in a strong position: you have a clear, reproducible pattern, specific versions, and dumps. That’s exactly what devs need to root‑cause this.

 

[rashmi]

Thank you! Sorry, i did actually try that order as well. No go. Did 2nd idea as well. Always works fine until re-enable HIPs. Then fail sadly.
Oh, and no other antiVirus. Know how things can conflict. But good idea.

Do you mean the second idea, or do both work well until you reenable HIPS?

You may try the following steps with the idea that works well; for example, let's take the first idea.

1. Disable Comodo modules.

2. Restart the system.

3. Install the driver.

4. Restart the system.

5. Enable Comodo modules but set HIPS to "Training Mode."

6. Restart the system; hopefully, the system boots.

7. Restart the system; hopefully, the system boots. Set HIPS to "Safe Mode."

8. Restart the system (twice); confirm the system boots.

 

[stonjean633]

Have you tried the Latest WHQL 581.80? If not try that first and ensure "clean installation".
If that conflicts with Cmdguard.sys, then better contact support for both Nvidia and Comodo as it's a driver conflict.

 

[Something-x2]

Hi Guys,

Will be revisiting all suggestions in a while. Thank you all for posting!
For now, just want to add this info to this thread.
Am on another exploratory issue ATM, because like forum poster BOT, am leaning towards 'kernal issue'.
But will circle back soon and try one more time using various suggestions.

To Bot, seems you must have missed my reply above to AV presence question?
Did post that no other Antivirus are being used, as share everyone's concern over avoiding any and all extra conflicts.

I double-checked and WindowsDefender is disabled via RegEdit. And of course showing disable in Windows GUI.
One of the first things i did when setting up Win10 years ago.

Another potential issue may be the Boot for hard-disk. -- MBR (legacy/CSM) vs GPT (UEFI).
Really not sure, but want to eliminate this if i can.
One issue that affected new 50** series GPUs early on was inadequate UEFI drivers (firmware for GPU).
Their symptoms were different with blank or Black screens, but still with older setups (like 3-4 years ago) may be issue?
There is a link to address this earlier issue > NVIDIA Support

Checked my setup.
Bios boot is set to mix of UEFI/Legacy.
My C:\drive is boot and checking properties of Volumes it is MBR (not UEFI).

Have no idea if Nvidia newer drivers are UEFI only? How to check this?
Have read many accounts of 'make sure legacy/csm' is ON in BIOS, as Nvidia devices work better.
But perhaps with newer drivers has become all UEFI focussed?

Yes, i could run software to transform MBR to GPT(UEFI), but would prefer a decent chance of it being that before going down that road and exposing my setup to more issues or worse.

What does confuse me is that in BIOS it shows the main disks (SSDs and Hardisks) as UEFI.
Makes me wonder if i have to change BIOS to Legacy/CSM only?

Am wondering this, because again, new nvidia driver does work in session(ComfyUI requires recent driver to work), but not on reboot.
Even though minidump singles out cmdguard.sys, i do want to double-check if Vendors recent move to focus on UEFI boot (from MBR) is causing Windows to look for something, that cmdguard.sys in Dec 2024 was not designed to accomodate. This remains notwithstanding that newer Nvidia works with firewall only enabled. The idea here is: if transform my boot drive to GPT (UEFI) that proper info will be fed to cmdguard.sys and boot can happen.

Would be great to know if anyone knows if newer Nvidia drivers have moved to UEFI boot only

Is too bad no-one using Comodo 2025 and newer Nvidia drivers around so far. Hopefully someone soon?

 

[Something-x2]

Using @rashmi's clearly laid out steps, and Nvidia latest 581.80,
i tried again.
On step 5 of Rashmi's steps not only did i set to Training Mode but also disabled ALL Hips monitor settings.
So esentially just cmdguard.sys called but no actions are being asked of it.

Result: fail; same 'unexpected kernal mode trap' again.
Should mention, did already do this before, but my OP was long enough, so left out.
But appreciate the advice so am faithfully following ideas.

Only thing didn't do is use DDU, as Bot suggested.
Never needed DDU before, and boot works fine with 561.09 and not any newer files.
Switching back and forth in session and all works fine.
Just not convinced that extra stress/step of DDU is going to yield anything.
Unless am seeing this wrong?

At Bot,
the idea of uninstall CIS and reinstall is probably next step.
That said, it does feel like it seems pretty conclusive that Nvidia drivers have added something for 50** series, and cmdguard,sys is not handling that new code, throwing a double-fault or no reply bascially.
So am a bit weary at the moment of trying a reinstall when feels like cmdguard.sys issue.
Will think about this.

Also, Am still curious if it's a boot MBR vs GPT(UEFI) thing, and upgrading to GPT would fix this.
In the minidump, there is no reference to my nvidia firmware (UEFI?), so not sure if that's a factor or not
A search on internet yielded nothing so far.

So if anyone has thoughts on importance of MBR & UEFI for malware analysis, and especially how it relates to cmdguard.sys on boot, would love to hear it!

And thank you again Bot for composing that and confirming my suspicions so far.

 

[Something-x2]

• Test newer drivers + different hardening stack
  If HIPS is non‑negotiable but 57x/58x performance/features are also critical, you might consider:
  • Comodo Firewall only + something like OSArmor / Hard_Configurator / Simple Windows Hardening, or
  • An AV with strong Application Control/HIPS‑like features (e.g. Kaspersky’s Application Control) instead of a classical HIPS driver like cmdguard
  This isn’t identical to Comodo’s model, but it can get you closer while avoiding this specific driver clash.

Am not familar with Kaspersky's Application Control.
Could you give a few examples or ideas of how much i would lose using this, vs cdmguard.sys?

 

[Bot]

Am not familar with Kaspersky's Application Control.
Could you give a few examples or ideas of how much i would lose using this, vs cdmguard.sys?

You’d mainly be trading fine‑grained, noisy, kernel‑level control for a more policy‑driven, quieter system. You don’t lose “all” HIPS‑style protection with Kaspersky, but you do lose some of the extreme granularity and the kind of manual sandboxing Comodo gives you.

Below is a practical comparison based on how people typically use each.

Quick summary

• Comodo HIPS (cmdguard.sys) + Auto‑Containment = classical HIPS + manual/auto sandbox, capable of very strict default‑deny with per‑action prompts.
• Kaspersky Application Control = policy‑based application restriction integrated with its AV/behavior blocker; you can get close to default‑deny, but it is less “micro‑controllable” and has no Comodo‑style container.

So you don’t lose the concept of application control; you lose some low‑level levers and sandbox behavior.

Where Comodo HIPS (cmdguard.sys) is stronger

• Per‑action, low‑level prompts
  Comodo can ask you about things like:
  • “X.exe is trying to access Y.exe’s memory”
  • “X.exe is trying to write to this registry key”
  • “X.exe is trying to install a driver / hook the keyboard / modify system files”
  You can answer per action, and Comodo builds very granular rules around that. Kaspersky can restrict the same types of behavior, but usually at a policy/group level rather than as interactive, ongoing HIPS prompts for every action.
  
• Manual & automatic containment (virtualization)
  Comodo’s Auto‑Containment can:
  • Run an unknown program in a virtualized environment.
  • Redirect its file/registry writes into a sandbox.
  • Limit its ability to see or touch the real system.
  Kaspersky does not have an equivalent full “virtualized container” in the current consumer versions. It can heavily restrict and monitor an app (e.g. no direct file access, blocked registry, no driver loading), but not transparently virtualize writes the way Comodo’s container does.
  
• Extremely strict custom rulesets
  With Comodo you can say “this specific EXE can only touch this folder and can never spawn any child processes” and enforce that directly via HIPS rules and containment.
  
  Kaspersky can implement similar concepts (per‑app rules for file/registry/network/system), but:
  
  • The UI and logic are built around groups & trust levels (Trusted, Low Restricted, High Restricted, Untrusted).
  • It is not designed as a “classical HIPS” with hundreds of prompts; it prefers automatic decisions based on reputation/trust.
• User‑driven workflow
  Comodo is happy to:
  • Ask you a lot of questions,
  • Let you craft niche rules for individual apps,
  • Operate in a very strict “nothing moves unless I say so” mode.
  Kaspersky can be pushed in that direction, but it is not its main design goal; it leans heavily on cloud reputation, trusted vendor lists, and automated decisions.

Where Kaspersky Application Control is strong (and what you still keep)

• Application groups & trust levels
  Every process is classified (Trusted / Low Restricted / High Restricted / Untrusted). For each group you can define:
  • What it can do with files and folders,
  • What it can do in the registry,
  • What system calls/drivers it can use,
  • What kinds of network activity are allowed,
  • Whether it can start other applications, inject code, etc.
  That’s still real application control, just less “ask me everything” and more “apply these policies to this group of apps.”
  
• Tight integration with AV + behavior blocker
  Kaspersky combines:
  • Application Control
  • System Watcher (behavior analysis/Ransomware rollback, etc.)
  • Exploit protections and other modules
  So unknown or low‑reputation apps can be:
  • Auto‑grouped as “Restricted/Untrusted” and heavily limited.
  • Monitored for malicious behavior, with the ability to undo changes.
  With Comodo you rely more on your own rules + containment; with Kaspersky, the system itself does more of the “intelligent guessing” for you.
  
• Default‑deny‑like setups
  In many Kaspersky builds you can:
  • Enable something like Trusted Applications Mode (name and availability depend on edition/version).
  • Set unknown apps to start in a restricted group.
  When tuned, this behaves close to default deny:
  • Only trusted/signed/reputable software runs with full rights.
  • Unknowns run in low/high restricted groups with tight limits, or are blocked until allowed.
• Fewer kernel‑level surprises
  Kaspersky’s drivers are widely deployed and heavily tested with:
  • New GPUs and drivers
  • Gaming stacks
  • Virtualization, Secure Boot / UEFI, etc.
  In practice, Application Control tends to cause fewer compatibility issues with GPU drivers and similar low‑level things than a very aggressive, hook‑heavy HIPS like cmdguard.sys.

What you concretely “lose” moving from Comodo HIPS to Kaspersky AC

• Continuous HIPS prompts for every unusual action
  If you like seeing:
  • “X.exe is trying to do Y low‑level thing – allow or block?”
  you’ll get a lot less of that. Kaspersky is designed to reduce user prompts and make more decisions automatically.
  
• Comodo‑style sandbox/virtualization
  You lose:
  • Automatic virtualization of filesystem/registry for unknown apps.
  • Manual “Run in container” option with the same depth of virtualization.
  Kaspersky can restrict apps hard, but it does not give them a fake “virtual C:\” the way Comodo can.
  
• Some of the “micro‑tuning” freedom
  You can still:
  • Set custom rules per application,
  • Apply granular permissions for files/registry/network/system.
  But the whole thing is structured more like “security policies” than a raw HIPS. If your current workflow is:
  • Install new tool → run it once → answer a bunch of Comodo HIPS prompts → craft a very precise rule set.
  you’ll find Kaspersky:
  • Asks less,
  • Relies more on its own decision logic,
  • Offers less visibility into each individual low‑level event.

What you would still have with Kaspersky

You’d keep:

• Application‑aware restrictions (per‑app rules, group‑based rights).
• The ability to force unknown or unsigned software into a very restricted category.
• Strong behavior blocking (System Watcher etc.).
• Good integration with modern Windows security and drivers (less likely to break Nvidia).

You’d lose:

• Hyper‑granular, per‑event HIPS prompts as your main workflow.
• A full virtualization‑based sandbox like Comodo’s Auto‑Containment.
• Some of the satisfaction (and workload) of micromanaging every process/action.

If you want to “approximate” your current style

If you ever test Kaspersky as an alternative stack, to get as close as possible to your Comodo mindset:

• Turn Application Control up to a stricter mode (restrict unknowns hard).
• If available in your edition, enable something like Trusted Applications Mode and review what it classifies as trusted.
• Manually move suspicious/rare tools into a restricted group and then open their rules to allow only what they really need.

It won’t be 1:1 with cmdguard.sys + Auto‑Containment, but for many people it hits a good balance between control and stability/compatibility.

If you describe 1–2 specific HIPS/containment workflows you absolutely rely on (e.g. “I always run X/Y kind of tools in containment and only allow them to write into folder Z”), I can say more concretely whether Kaspersky can replicate those, and how closely.

 

[Something-x2]

What you would still have with Kaspersky

You’d keep:

• Application‑aware restrictions (per‑app rules, group‑based rights).
• The ability to force unknown or unsigned software into a very restricted category.
• Strong behavior blocking (System Watcher etc.).
• Good integration with modern Windows security and drivers (less likely to break Nvidia).

You’d lose:

• Hyper‑granular, per‑event HIPS prompts as your main workflow.
• A full virtualization‑based sandbox like Comodo’s Auto‑Containment.
• Some of the satisfaction (and workload) of micromanaging every process/action.

At Bot,
(1) Thank you very much! That comparison of what gained and lost was very helpful! Will think about this. Do prefer comodo still, but better integration with windows and not break Nvidia may have to happen, if Comodo doesn't put out a 2026 version that fixes this.

(2) Would you have any advice or comment on the concern raised in my previous 2 posts re: bios boot via MBR vs UEFI for proper loading/handling of cmdguard.sys?
To restate simply:
Guessing with advent of newer 50** GPUs, the drivers were overhauled and may contain more modern UEFI design/features?
Or put another way, Are some older anti-malware programs, especially like Comodo 2025, perhaps not working properly with UEFI designed Nvidia drivers (are they exclusive more to UEFI now and perhaps more features?)?
Am trying to figure out if updating my boot partitions to GPT may modernize my boot enough that cmdguard.sys provides a response to Windows setup that is required (no double fault).
If I am on a wrong path of thought here, would like to hear. But if a chance, it may work, then may consider recoding boot from MBR to GPT.
Searched the internet if Nvidia drivers more UEFI featured, with no data found.
This does make me wonder if MBR boot is an inadequate resource/pathway to allow proper cmdguard.sys interaction.

 

[Bot]

At Bot,
(1) Thank you very much! That comparison of what gained and lost was very helpful! Will think about this. Do prefer comodo still, but better integration with windows and not break Nvidia may have to happen, if Comodo doesn't put out a 2026 version that fixes this.

(2) Would you have any advice or comment on the concern raised in my previous 2 posts re: bios boot via MBR vs UEFI for proper loading/handling of cmdguard.sys?
To restate simply:
Guessing with advent of newer 50** GPUs, the drivers were overhauled and may contain more modern UEFI design/features?
Or put another way, Are some older anti-malware programs, especially like Comodo 2025, perhaps not working properly with UEFI designed Nvidia drivers (are they exclusive more to UEFI now and perhaps more features?)?
Am trying to figure out if updating my boot partitions to GPT may modernize my boot enough that cmdguard.sys provides a response to Windows setup that is required (no double fault).
If I am on a wrong path of thought here, would like to hear. But if a chance, it may work, then may consider recoding boot from MBR to GPT.
Searched the internet if Nvidia drivers more UEFI featured, with no data found.
This does make me wonder if MBR boot is an inadequate resource/pathway to allow proper cmdguard.sys interaction.

On the MBR vs UEFI angle, all the data you’ve posted so far points very strongly to “wrong tree” rather than “hidden root cause”.

1. Where cmdguard.sys and Nvidia actually meet

Both cmdguard.sys and the Nvidia display driver (nvlddmkm.sys) are Windows kernel‑mode drivers. They are loaded and run:

• After the firmware/BIOS/UEFI has done its job,
• After Windows has already booted the kernel,
• Independently of whether the disk is MBR or GPT.

So as long as:

• Windows boots successfully into the kernel, and
• The Nvidia driver can load and run in normal sessions,

then your partition style (MBR vs GPT) and boot style (legacy BIOS vs UEFI) are essentially “below” the layer where cmdguard.sys and Nvidia interact.

Your own observations line up with this:

• New Nvidia drivers (57x/58x/581.80) work fine while Windows is up and Comodo HIPS is OFF / firewall only.
• The system only dies on boot when cmdguard.sys is active in its HIPS role.
• Rolling back to 561.09 instantly makes everything stable again.

If this were “Nvidia driver absolutely needs UEFI‑booted Windows to behave correctly”, you’d expect:

• Crashes or black screens regardless of Comodo,
• Or at least widespread reports from other non‑UEFI users.

We don’t see that. Instead, we see a very specific pattern: “Win10 + cmdguard.sys build 12.3.4.8162 + RTX 3090 + 57x+/58x driver = 0x7F double fault”.

That’s classic “driver‑vs‑driver” territory, not “boot mode” territory.

2. GPU UEFI firmware vs Windows boot mode

There are two largely separate things here:

• GPU firmware (legacy VGA vs UEFI GOP) – that’s what the Nvidia UEFI firmware tool you linked is about.
  It decides, for example:
  • Can the card show the POST/BIOS screen in pure UEFI mode?
  • Can it be used with CSM disabled?
  Your RTX 3090 already has a modern GOP; that tool was mainly for older GTX 600/700‑era cards.
  
• Windows boot mode & disk layout (BIOS+MBR vs UEFI+GPT) – this affects:
  • Whether you can use Secure Boot, some Win11 requirements, etc.
  • Where boot files live (MBR vs EFI System Partition).
  Once Windows is running, kernel‑mode drivers don’t typically care whether they came from an MBR or GPT boot, they just see “Windows kernel, version X, with these APIs”.

Your GPU’s UEFI features and your system’s MBR boot are therefore mostly orthogonal to how cmdguard.sys and nvlddmkm.sys behave inside the running OS.

3. “Modern UEFI‑focused” Nvidia drivers vs older security software

Could Nvidia be optimizing/testing more for UEFI‑booted, fully modern systems? Yes, that’s plausible over time.

But the key is:

• If Nvidia had truly made the driver require UEFI, you’d see:
  • Mass breakage on legacy/MBR systems (not just when a specific HIPS driver loads),
  • Or at minimum official notes / huge forum noise about it.
• In your case, the new driver:
  • Loads,
  • Functions,
  • Runs ComfyUI in‑session,
  • Only trips over when cmdguard.sys comes into play on boot.

That strongly argues for a code‑interaction bug like:

• cmdguard hooks or injects somewhere in kernel/graphics path,
• Nvidia 57x+/58x changed some internal structures/behaviour,
• cmdguard doesn’t expect the new behaviour → kernel stack corruption → 0x7F double fault.

That sort of low‑level mismatch is exactly what your WinDbg “unexpected kernel mode trap” and reproducible pattern suggest.

Changing MBR → GPT doesn’t change those kernel interfaces; it just changes how Windows got to the point where it can load cmdguard.sys and nvlddmkm.sys.

4. Would converting to GPT/UEFI realistically fix this?

In terms of probability:

• I’d put “conversion to GPT/UEFI magically makes cmdguard.sys and 58x drivers coexist” as very low‑likelihood.
• I’d treat it more as:
  • A step you might take anyway for other reasons (Secure Boot, Win11, modernisation),
  • But not as a targeted fix for this particular BSOD.

Also, conversion isn’t zero‑risk:

• MBR → GPT on a system disk involves:
  • Partition table changes,
  • Boot loader reconfiguration,
  • BIOS settings change to pure UEFI boot.
• It’s usually fine with proper tools/backups, but it adds complexity and potential for downtime or boot headaches — with no clear evidence it relates to your specific cmdguard/Nvidia clash.

If you want to move to GPT/UEFI later for general modernisation, that’s reasonable. I just wouldn’t do it because of this crash, unless you have other, stronger motivations.

5. Relevance of MBR vs UEFI for malware & Comodo

For malware and security in general:

• UEFI/GPT matters a lot for:
  • Secure Boot,
  • UEFI bootkits,
  • Certain advanced protections (VBS/HVCI in some configurations).
• MBR vs GPT also matters for where bootkits can hide.

But cmdguard.sys itself is a post‑boot kernel driver. It doesn’t normally need to know whether the system came from MBR or GPT; it’s concerned with:

• Processes,
• Memory,
• System calls,
• File and registry operations,
• Driver loads, etc.

None of that is inherently tied to the partitioning scheme.

So from a Comodo‑specific standpoint:

• MBR vs GPT affects what kinds of boot‑level threats can exist, but
• It should not be a deciding factor in whether cmdguard.sys can coexist with a display driver.

6. Where this leaves you

Given everything you’ve tested:

• No other AV or Defender in the mix.
• Latest Nvidia 581.80 tried.
• Clean Comodo module toggling, including HIPS “Training Mode” with all monitors disabled → still 0x7F.
• Instant stability when you revert to 561.09.

It’s as close as you’re going to get, from the outside, to:

• “This is a cmdguard.sys vs new Nvidia driver interaction bug on Win10 x64, not an MBR/UEFI issue.”

So my honest view:

• I would not convert your system disk to GPT/UEFI purely in hopes of fixing this.
• I’d:
  • Stick with your current “CIS 2025 + HIPS disabled / firewall only + 57x+/58x driver” setup, or
  • Stick with 561.09 + full Comodo HIPS/containment (if the older driver is acceptable), or
  • Consider an alternative hardening stack (like we discussed) if you decide newer Nvidia branches are more important than Comodo’s HIPS.
• And keep your excellent repro info ready for Xcitium/Comodo: if they address cmdguard’s compatibility in a 2026 build, that’s the real fix.

If you ever do decide to go GPT/UEFI for other reasons and want a “minimal‑risk plan” (what to back up, what tools, what BIOS settings to double‑check), feel free to ask — but I’d treat that as a separate project, not a likely solution to this particular BSOD.

 

[Something-x2]

But cmdguard.sys itself is a post‑boot kernel driver. It doesn’t normally need to know whether the system came from MBR or GPT; it’s concerned with:

• Processes,
• Memory,
• System calls,
• File and registry operations,
• Driver loads, etc.

None of that is inherently tied to the partitioning scheme.

So from a Comodo‑specific standpoint:

• MBR vs GPT affects what kinds of boot‑level threats can exist, but
• It should not be a deciding factor in whether cmdguard.sys can coexist with a display driver.

It’s as close as you’re going to get, from the outside, to:

• “This is a cmdguard.sys vs new Nvidia driver interaction bug on Win10 x64, not an MBR/UEFI issue.”

Bot,
Thank you very much yet again!
MBR vs GPT is outside my area of knowledge re: processing cmdguard.sys, and so your quick concise explanation was 100% helpful again.
So will leave that as a future modernizing option.

With your kind & helpful assistance written above, i will TRY to contact Comodo one way or another, to inform them, and hopefully get a REAL Fix
To Bot and Mods, have a great day!

 

[Trident]

By using Kaspersky instead of Comodo, you won’t be losing much, you are actually gaining the following:

-Extremely strong malware detection, proven again and again on every test possible
-The application control can easily work as default-deny, zero trust solution and can double as restrictive layer to minimise damage from malware
-Behavioural monitoring that has stood the test of time
-Massive list of known goodware which Kaspersky has been collecting for ages
-Blocking of malicious websites just as good as malware detection
-Ongoing updates, support and customer care
-Application that is built on modern, stable and scalable architecture, not on APIs from the Windows XP era.

What you will lose:
-15 Euro to purchase a license
-Full-blown sandbox
-A lot of bugs which as you see, you are documenting yourself

 

[simmerskool]

Want to resolve this. Should i contact support at #1 Zero Trust Cybersecurity Platform | Xcitium ?

well xcitium is aggressively active, I looked at their webpage once about 18 months ago and they keep sending me unsolicited emails to buy

 

[Bot]

Bot,
Thank you very much yet again!
MBR vs GPT is outside my area of knowledge re: processing cmdguard.sys, and so your quick concise explanation was 100% helpful again.
So will leave that as a future modernizing option.

With your kind & helpful assistance written above, i will TRY to contact Comodo one way or another, to inform them, and hopefully get a REAL Fix
To Bot and Mods, have a great day!

You’re very welcome, and I’m glad it helped clarify the MBR vs GPT angle.

Your plan sounds solid:

• Keep your current setup as‑is (no risky MBR→GPT conversion just for this).
• Contact Comodo/Xcitium with:
  • Exact CIS version and cmdguard.sys build,
  • Exact Nvidia driver versions (561.09 = OK, 57x/58x = BSOD),
  • Windows 10 build,
  • The 0x7F “UNEXPECTED_KERNEL_MODE_TRAP” + mention of double fault,
  • A few minidumps + msinfo32 report.

That’s exactly the kind of clean, reproducible case developers need to fix a driver conflict.

If you do eventually hear back from Comodo or get a test build / 2026 version that resolves it, posting the outcome later would probably help others in the same situation.

Have a good day as well, and if you run into anything else you want to sanity‑check before changing your setup, just ask.

 

[Something-x2]

By using Kaspersky instead of Comodo, you won’t be losing much, you are actually gaining the following:

-Extremely strong malware detection, proven again and again on every test possible
-The application control can easily work as default-deny, zero trust solution and can double as restrictive layer to minimise damage from malware
-Behavioural monitoring that has stood the test of time
-Massive list of known goodware which Kaspersky has been collecting for ages
-Blocking of malicious websites just as good as malware detection
-Ongoing updates, support and customer care
-Application that is built on modern, stable and scalable architecture, not on APIs from the Windows XP era.

What you will lose:
-15 Euro to purchase a license
-Full-blown sandbox
-A lot of bugs which as you see, you are documenting yourself

Thank you for that info! And Timely.
Just ended up buying a 2 year Kaspersky CyberMonday at steep discount.
Did look up the Russia connection but see main servers were moved to Switzerland.
So without any other anti-malware vendor offering a mature solution (idefender is a WIP and different), and price so affordable,
i just bought it and have in reserve for when AI generating online. Not happy about Russia-link but not alot of choice out there.
Better than malware.
Still prefer the high granularity of CIS for each app by a long shot, and so will hope for Comodo 2026.
The individualized lockdown & sandbox is totally worth some other features not working. Works fine for a long time for me.
But that could be a while or never.
Ans Xcitium package features are truly SERIOUS next level enterprise.
Nothing lesser for Home Geeks.

So Kaspersky is the fallback for now. Will try to use with Comodo firewall.
So thanks to BOT suggesting as an alternative, and also to your confirmation that it's got alot of good modern features.