If you're seeing 0X00000312, your software got blocked by a Software Restriction Policy (SRP) or a Safer policy rule. Here's how to kill it.
The culprit here is almost always a rule in Software Restriction Policies under Local Group Policy or Domain Group Policy. Someone (maybe even you) set a path rule, hash rule, or certificate rule that blocks that EXE or MSI. The error message even tells you which rule is doing it — it says "by policy rule %2". That %2 is the rule name.
The fix: Remove the offending policy rule
- Open gpedit.msc (Local Group Policy Editor). If you're on Home edition, skip to the registry method below.
- Go to Computer Configuration > Windows Settings > Security Settings > Software Restriction Policies.
- If you see No Software Restriction Policies, right-click and select New Software Restriction Policies. Then check the rules under Additional Rules.
- Under Additional Rules, look for a rule that matches the blocked application's path, hash, or certificate. The rule name is in the error message.
- Right-click and Delete the rule. Or change its security level to Unrestricted if you want to keep the rule but allow the app.
- Close gpedit.msc and run
gpupdate /forcein an admin Command Prompt. - Test the application.
If gpedit.msc isn't available (Windows Home)
Open Regedit as admin and go to:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiersYou'll see subkeys like 0, 1, 2 — these correspond to rule levels. Under each subkey, look at the Path or ItemData values to find the rule that blocks your app. Delete the entire subkey for that rule. Be careful — don't delete DefaultLevel or TransparentEnabled unless you know what you're doing.
Why this works
Software Restriction Policies are Windows' built-in application control system. They predate AppLocker and are still used in many enterprise environments. When a rule matches, Windows sets an access denied flag that triggers 0X00000312. Removing the rule removes the restriction. Simple as that.
If the policy is pushed from a domain controller (Group Policy object), you can't just delete it locally — it'll come back after gpupdate. In that case, you need to contact your domain admin to modify the GPO. But local rules are fair game.
Less common variations
1. The rule is in User Configuration instead of Computer Configuration
Check User Configuration > Windows Settings > Security Settings > Software Restriction Policies too. User-level SRP rules apply to specific users regardless of the computer.
2. The rule uses a certificate hash
If the rule blocks by publisher certificate, deleting the rule is still the fix. But you might also need to check the certificate store. Open certlm.msc (Local Machine certificate store), look under Trusted Publishers or Disallowed, and remove the offending cert. I've seen this happen with self-signed test certificates.
3. The rule is in the registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
Some malware or even anti-cheat software sets a debugger key there to block execution. Look for a subkey named after the blocked EXE (like notepad.exe) and check if it has a Debugger value. Delete the subkey.
4. The error appears when running from a network share
By default, SRP blocks executables from untrusted network locations. The rule is usually called All Network Locations or something similar. Either move the app to a local drive, or set the network path as an allowed zone in Internet Options > Security > Local Intranet.
Prevention
Don't add SRP rules unless you need them. They're powerful but easy to misconfigure. If you're managing multiple machines, use AppLocker instead — it's easier to audit and has better error messages. For single machines, stick to the built-in Windows Defender Application Control or just don't mess with policy rules unless you're testing something.
And if you're in a domain environment, always test policy changes in a separate OU before pushing to production. Makes for fewer angry calls.