STATUS_CONTENT_BLOCKED 0XC0000804: Fix Content Blocked Error

You double-click an unsigned installer you just downloaded, and instead of the setup wizard you get a cryptic dialog or an event log entry: STATUS_CONTENT_BLOCKED (0XC0000804). The same thing shows up when a PowerShell script calls a blocked DLL, when a service tries to load a driver Windows doesn't trust, or when you run an old tool that SmartScreen has flagged. The message literally means "I refuse to execute this because policy or reputation says no."

What's actually happening here is that Windows is enforcing a content trust decision at the kernel or runtime level. It's not a corruption error, not a permissions error, and not a disk problem. It's an intentional refusal. That distinction matters because the fix isn't to repair anything — it's to satisfy or override the policy that's blocking you.

Why 0XC0000804 shows up

STATUS_CONTENT_BLOCKED is a Windows NT status code (0xC0000804) returned by components like Smart App Control, SmartScreen, Windows Defender Application Control (WDAC), and Mark-of-the-Web enforcement. When you download a file from the internet, Windows tags it with an alternate data stream called Zone.Identifier. Any executable that carries that tag is treated as untrusted until something vouches for it.

On Windows 11 22H2 and later, Smart App Control takes this further. If it's turned on, only signed, reputable apps run. Anything else — including many legitimate open-source utilities — throws 0XC0000804. On enterprise machines, WDAC policies do the same thing, often silently. The reason step 3 below works is that it removes the reputation signal while leaving the actual security layers intact.

If you see this error on a personal machine and you've never touched Smart App Control, check whether a third-party antivirus or a leftover WDAC policy is doing the blocking. Corporate-managed devices almost always have one.

Fix it in order — stop when it works

Unblock the file from the file's properties. Right-click the file, choose Properties, and look for an Unblock checkbox at the bottom of the General tab. Tick it and click OK. This strips the Zone.Identifier stream. If the checkbox isn't there, jump to step 2.
Remove the mark-of-the-web with PowerShell. Open PowerShell as your normal user (not admin) and run:
```
Unblock-File -Path "C:\Path\To\YourFile.exe"
```
If you have a whole folder of tools, target them all:
```
Get-ChildItem "C:\Tools" -Recurse | Unblock-File
```
This does the same thing as the checkbox, but it works on files that never showed the option.
Check Smart App Control. Open Windows Security → App & browser control → Smart App Control settings. If it says "On," that's your blocker. You can only turn it off — you can't turn it back on without reinstalling Windows. If you're going to run unsigned tools regularly, turning it off is the honest choice. If you're not, leave it on and find a signed alternative.
Look for a WDAC or AppLocker policy. On managed machines, run this in an admin PowerShell:
```
Get-CimInstance -Namespace root/Microsoft/Windows/CI -ClassName MSFT_CiPolicy | Format-List
```
If policies come back and you didn't set them, this is a domain or Intune deployment. You can't legally or practically remove it yourself — talk to whoever manages the machine. On a personal PC, an old policy can linger after you leave a company. It lives here:
```
C:\Windows\System32\CodeIntegrity\CiPolicies\Active
```
Delete the .cip file only if you're sure it's orphaned.
Confirm the file isn't actually malicious. Before you bypass anything, check the hash on VirusTotal. STATUS_CONTENT_BLOCKED exists because bad things get blocked. A signed installer from a known vendor is fine to unblock. A random "crack" from a forum is not — and the block is the only thing standing between you and a really bad afternoon.

If it still fails after all that

Check Event Viewer → Applications and Services Logs → Microsoft → Windows → AppLocker or CodeIntegrity. The block reason is logged there with the exact policy name or rule that fired.
Run gpresult /h report.html on a domain machine. If a WDAC or AppLocker GPO is applied, that's the wall you're hitting and no local fix will move it.
Test the file from a different folder, like C:\Temp. Some block policies only apply to user-writable paths.
Try running it as a different user. If a standard user is blocked but an admin isn't, the policy is scoped to non-admin contexts.
If it's a driver throwing 0XC0000804, it's a signing issue. Drivers must be signed by a Microsoft-trusted authority on modern Windows. There's no supported bypass for a retail install.

One last thing: don't paste `bcdedit /set testsigning on` into a machine you actually use. It disables driver signature enforcement globally and it's the wrong tool for almost every case of this error. Fix the specific block, not the entire security model.