Fix 0xC0000906 STATUS_VIRUS_INFECTED on Windows

Quick answer: 0xC0000906 means a real-time AV engine (Windows Defender, Sophos, CrowdStrike, etc.) is holding a file lock or has flagged the binary — you either whitelist the file, pull it from quarantine, or turn off the offending filter and retry.

I've seen this error code crop up three or four times a year across enterprise fleets, and it's almost never an actual virus. The status code is STATUS_VIRUS_INFECTED, which Windows returns when a registered antivirus minifilter driver vetoes a file open. It's the kernel telling the calling process: nope, that file's flagged. The calling process could be anything — an MSI installer, a PowerShell script, a vendor's driver package, an SCCM deployment. The common trigger in my experience is a freshly downloaded vendor EXE or DLL that hits Defender's cloud protection heuristic and gets tagged as a false positive. Second most common: an old AV product like McAfee Endpoint or Sophos Central sitting on a stale signature that flags a legitimately signed binary.

Don't waste time on SFC or DISM. This isn't a corruption error. It's a policy block. Fix the AV decision and the error disappears.

Fix 1: Check if it's actually flagged (30 seconds)

Before you do anything, confirm whether Defender thinks the file is malicious. Open an elevated Command Prompt and run:

"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -Scan -ScanType 3 -File "C:\Path\To\YourFile.exe"

If the output says found 1 threats, you've got your answer. If it says clean, the block is coming from a third-party AV — skip to Fix 3.

Fix 2: Remove the Defender detection and whitelist

Open Windows Security (Start → type Windows Security).
Go to Virus & threat protection → Protection history.
Find the entry for your file. Click the dropdown and hit Actions → Allow on device. This is critical — Restore alone won't stop it getting re-flagged.
Now add an exclusion. Virus & threat protection → Manage settings → scroll to Exclusions → Add or remove exclusions → Add an exclusion → File or Folder. Point it at the specific EXE, not the whole directory. Whole-directory exclusions are how ransomware slips through.
Retry whatever was throwing the error.

If you're on a managed fleet and those toggles are greyed out, you're under Intune or Group Policy. You need to push the exclusion from Computer Configuration → Administrative Templates → Windows Components → Microsoft Defender Antivirus → Exclusions or via Intune's Defender Antivirus policy. Local UI edits get reverted on the next policy sync.

Fix 3: Third-party AV is the culprit

If MpCmdRun came back clean, some other filter driver is holding the file. Common offenders: Sophos Intercept X, CrowdStrike Falcon, SentinelOne, McAfee ENS, Trend Micro Apex One.

Open the AV console and check quarantine. Pull the file out and add it to the allow list. Sophos calls it "Exclusions", CrowdStrike calls it "Prevention Policies → Exclusions", SentinelOne calls it "Exclusions" too but buries it under SentinelOne → Policy → Exclusions.
If you can't find the file in quarantine, temporarily disable real-time protection (in a lab or maintenance window, never on a production user's box without approval), retry the operation, then re-enable and add the exclusion.
With CrowdStrike Falcon specifically: the block often comes from the Machine Learning prevention policy, not the quarantine list. You need to add the SHA256 hash to the ML exclusion list, not just the file path. Path exclusions won't release an ML block.

Fix 4: It's an installer unpacking a payload

Some installers (older InstallShield builds, certain Nullsoft NSIS packages, a handful of vendor updaters) extract a temporary EXE to %TEMP% and execute it. The AV flags the extracted EXE, and the parent installer dies with 0xC0000906. You'll see the temp file appear and vanish in Procmon.

Two options: whitelist the specific hash of the extracted payload (grab it from Defender's Protection History — the hash is right there), or run the installer from a directory already excluded from scanning. I prefer the hash approach. It's tighter and you don't have to leave a whole folder unprotected.

Alternative fixes if the above doesn't clear it

Reboot. Sounds dumb, but minifilter drivers occasionally get stuck on a file handle after a scan. A reboot drops the handle and the block clears.
Unblock the file from the zone identifier. If the file was downloaded from the internet, Windows marks it. Run:
```
Unblock-File -Path "C:\Path\To\YourFile.exe"
```
This won't fix a real AV block, but it kills the "Windows protected your PC" follow-on errors.
Check the file's actual signature. Run signtool verify /pa /v "C:\Path\To\YourFile.exe". If it's unsigned or the signature is broken, your AV is right to block it. Stop fighting it.
Submit for false-positive review. Microsoft has a portal at microsoft.com/wdsi/filesubmission. Third-party vendors have equivalents (Sophos, CrowdStrike both have submission forms). Turnaround is usually 24–48 hours.

Prevention

If you're pushing software via SCCM, Intune, PDQ, or any RMM, exclude the deployment cache directory before you push. For SCCM that's C:\Windows\CCM\Cache. For Intune Win32 apps it's C:\Program Files (x86)\Microsoft Intune Management Extension\Content. For PDQ Deploy it's C:\Windows\AdminArsenal\PDQDeploy\Repository. Skipping that step is why half the 0xC0000906 tickets I've closed existed in the first place. Set the exclusions once, and you never see this error again on that endpoint.

And don't be tempted to disable real-time protection globally as a "fix". I've seen that one bite people. Whitelist the specific file or hash and move on.