Windows 11 Can't Run .exe Files? Fix .exe, .cmd, and .ps1 Blocks

This guide is for local administrators and technically capable users on unmanaged or lightly managed Windows 11 Pro systems whose executable, batch, or PowerShell script files have stopped running after installation or a feature update. Corporate devices enrolled in Intune or joined to a domain with Group Policy are a different situation those paths are called out explicitly below.

By the end, you'll be able to identify which Windows security layer is causing the block, confirm whether you can fix it yourself, and know when to escalate to an IT administrator.

The most important framing before touching anything: if .exe, .cmd, and .ps1 files are all failing, the cause is almost certainly intentional security enforcement, not installation corruption. Windows 11's application control stack covers far more than standalone apps. It also governs scripts, MSI installers, batch files, and PowerShell sessions, any of which can be blocked or restricted depending on active policy (Microsoft Learn).

Before proceeding: open Settings → System → About and note your Windows 11 version. The diagnostic steps are the same across builds, but the 24H2 caveats in this guide are version-specific.

The three causes this guide addresses, in descending order of likelihood:

1. Smart App Control or App Control for Business is blocking unsigned code
2. PowerShell execution policy or Mark-of-the-Web is blocking .ps1 files specifically
3. File association corruption following a 24H2 upgrade (rare; treated as a last-resort check)

If Windows 11 can't run .exe files, start by separating security blocks from file corruption

Understanding the difference between enforcement layers and safety features prevents misdiagnosis and stops you from changing the wrong thing.

True enforcement layers will block your files and won't yield to user-level settings:

• Smart App Control, introduced in Windows 11 22H2, allows only digitally signed code or code that Microsoft's cloud-based Intelligent Security Graph classifies as safe. Unsigned code that can't be confidently evaluated is blocked. Code deemed unsafe is always blocked, regardless of user action (Microsoft Learn). This applies to Windows Pro, not just Enterprise.
• Smart App Control starts in evaluation mode after a fresh install and decides within roughly 48 hours whether to stay active. Critical constraint: once it moves to enforcement mode and is later disabled, it cannot be re-enabled without a full Windows reset or reinstall (Microsoft Learn). On enterprise-managed devices, it automatically disables itself within that same 48-hour window. So if you're on a domain-joined or Intune-enrolled machine, Smart App Control is probably not your problem.
• App Control for Business (formerly WDAC) and AppLocker, when deployed via Group Policy or Intune, can restrict applications, scripts, MSI packages, and batch files. This means .cmd files fall under the same enforcement umbrella as .exe and .ps1. These are admin-deployed policies; a standard user cannot modify or override them.

Safety features look like blocks but yield to user-level changes:

• PowerShell execution policy controls when PowerShell loads configuration files and runs scripts. Microsoft explicitly states it is not a security system that restricts user actions a user who can't run a script file can bypass the policy by pasting the script's contents directly into the console (Microsoft Learn). Execution policy alone will not block .exe or .cmd files.
• Mark-of-the-Web (MOTW) tags files downloaded from the internet with a Zone identifier. Under RemoteSigned execution policy, unsigned downloaded scripts won't run. This affects specific downloaded files, not all scripts on the system.

Diagnostic shortcut: If all three file types (.exe, .cmd, .ps1) fail, suspect Smart App Control or a deployed App Control/AppLocker policy. If only .ps1 files fail, start with execution policy and MOTW. If .exe and .com files fail specifically after a 24H2 upgrade, jump to the edge-case note at the end of the fixes section.

How to identify which layer is responsible: a diagnostic sequence

Complete these steps in order. Each one either confirms a cause or rules it out.

Prerequisites: Some steps below require a local administrator account specifically any check that inspects App Control policy state or modifies machine-level execution policy. Steps 1 and 2 can be completed by a standard user.

Step 1: Read the error message

The error message is the fastest signal available:

If you see no error and files simply fail to launch, continue through the steps below.

Step 2: Check Smart App Control status

Open Windows Security → App & browser control → Smart App Control. If the status reads "On" or "Evaluation," it is actively making allow/block decisions. If "Off," rule it out and move to Step 3.

Step 3: Check PowerShell's language mode

Open PowerShell and run:

• ConstrainedLanguage means a WDAC or AppLocker policy is enforcing restrictions. This is an admin-deployed policy you cannot override locally (Patch My PC).
• FullLanguage means the PowerShell engine is not constrained; look elsewhere.

24H2 caveat: A regression in Windows 11 24H2 caused AppLocker Script Rules to stop correctly enforcing Constrained Language Mode, meaning scripts that should have been restricted ran with full PowerShell privileges. The language mode check could return FullLanguage even on a machine where AppLocker script rules were correctly configured. Microsoft addressed this through the May 2025 security update via WLDP runtime fixes, and separately in PowerShell 7.6 (Patch My PC; BornCity). If you're on an unpatched 24H2 system and AppLocker policies seem to have no effect, apply the May 2025 or later cumulative update and retest before drawing conclusions.

Step 4: Check execution policy

Run:

Look at the MachinePolicy and UserPolicy rows first. If either shows a concrete value such as Restricted, Group Policy is setting that scope a locally applied Set-ExecutionPolicy command will not override it. That requires a Group Policy change by an administrator.

If both MachinePolicy and UserPolicy show Undefined, no Group Policy is controlling execution policy. Local policy is in effect and you can change it yourself (Microsoft Learn).

Step 5: Check for Mark-of-the-Web on specific files

If a particular downloaded script is failing rather than all scripts, run:

A ZoneId=3 value confirms the file is tagged as internet-sourced. Clear the tag with:

(Microsoft Learn)

What you can actually fix yourself (and what you can't)

Work through whichever fix matches your confirmed cause.

Self-service fix: execution policy is blocking .ps1 files (MachinePolicy/UserPolicy are Undefined)

From an elevated PowerShell session:

RemoteSigned allows locally created scripts to run unsigned while requiring a digital signature for scripts downloaded from the internet. That's a reasonable default for most non-managed machines. You should see no further "running scripts is disabled" errors for local .ps1 files.

What to expect after: Run Get-ExecutionPolicy -List again to confirm LocalMachine now shows RemoteSigned. If the policy immediately reverts, Group Policy is overriding the change. That means you're in a managed environment, and the fix belongs with your IT administrator.

Self-service fix: a specific downloaded file is blocked by Mark-of-the-Web

Use Unblock-File as described in Step 5. Right-clicking the file and choosing Properties → Unblock achieves the same result if you prefer a GUI.

Self-service fix (with caution): Smart App Control has moved to enforcement and is blocking trusted, unsigned code

Smart App Control can be disabled via registry. Set the VerifiedAndReputablePolicyState DWORD value under HKLM\SYSTEM\CurrentControlSet\Control\CI\Policy to 0, then run CiTool.exe -r from an elevated command prompt. Microsoft documents this registry path for turning Smart App Control off (Microsoft Learn).

Treat this as a last resort, not a first step. Before editing the registry, confirm Smart App Control is the actual cause using Step 2. This removes a default protection layer, and because Smart App Control cannot be re-enabled without resetting Windows the decision is not easily undone. Apply it only to code you've verified is legitimate and trustworthy.

Admin-required: App Control for Business, AppLocker, or Group Policy is enforcing restrictions

If Step 3 returned ConstrainedLanguage, or if MachinePolicy in Step 4 shows a concrete value like Restricted, a policy deployed by an administrator is in effect. You cannot override this locally. Contact your IT department or policy owner to request an exception or policy modification, and ask them to confirm the policy was intentionally applied rather than misconfigured.

If you are the administrator on an unmanaged machine and you deployed an AppLocker or WDAC policy yourself, review that policy in the Local Security Policy editor or via Get-AppLockerPolicy -Effective and confirm it's configured as intended.

Edge case, last resort: .exe and .com files are broken after a Windows 11 24H2 upgrade

At least one documented case a single Microsoft Tech Community post from early 2025 describes a 24H2 upgrade that broke .exe and .com file associations entirely, leaving Notepad, Task Manager, and Command Prompt all failing after login. Recovery tools didn't help. Full resolution reportedly required rolling back all quality and feature updates.

This is based on a single user report without corroborating Microsoft documentation. If you've worked through every other cause above and Windows 11 can't run .exe files specifically after a 24H2 upgrade, rolling back the feature update is worth attempting before a full reinstall. Don't start here.

Decision tree: which path applies to you

Work through the diagnostic steps first, then match your result below.

Smart App Control shows "On" or "Evaluation" and is blocking files: Verify the blocked code is legitimate, then consider the registry disable documented in Microsoft Learn. Remember the action is permanent short of a Windows reset.

Only .ps1 files fail, MachinePolicy/UserPolicy are Undefined: Set execution policy to RemoteSigned from an elevated session, then retest.

A specific downloaded script fails but others work: Use Unblock-File to clear the Mark-of-the-Web tag.

Language mode is ConstrainedLanguage, or MachinePolicy shows a concrete restriction: You're in a managed environment. Escalate to your IT administrator a registry edit won't help and may create a support headache.

All .exe and .com files fail after a 24H2 upgrade, nothing else explains it: Attempt a feature update rollback before considering a full reinstall.

For managed environments, Microsoft's App Control for Business documentation covers enterprise policy deployment in detail. For ongoing Constrained Language Mode diagnostics, PowerShell 7.4 and later support Audit mode for App Control policies a less disruptive way to inspect what a policy would block before enforcing it (appcontrol.ai).