Unable to Run C Programs in VS Code Due to Windows Application Control Policy

To keep Smart App Control enabled, sign every GCC-generated executable with a valid code-signing certificate from a trusted provider; Smart App Control has no per-application allow-list for unsigned local builds.

Why the executable is blocked

A newly compiled MinGW executable is normally unsigned and has no established reputation. When Smart App Control cannot confidently classify a program, it checks its signature; an unsigned or invalidly signed program is treated as untrusted and blocked. There is currently no “Allow this app” exception. ^1^

This is Windows enforcement, not a VS Code or GCC configuration error. Changing the output folder, running VS Code as administrator, or using another terminal on the same Windows installation will not bypass it.

Supported solution: sign each build

1. Obtain a trusted code-signing identity.
   • Microsoft identifies Artifact Signing as the preferred signing option.
   • Alternatively, obtain a code-signing certificate from a trusted certificate provider.
   • Identity verification, regional availability, and charges can apply, so check the current requirements before purchasing anything.
   • A self-signed certificate or locally trusted test certificate is not sufficient for Smart App Control; the certificate must be issued through a provider trusted by Windows. ^2^ ^3^
2. Install SignTool. Microsoft documents SignTool as part of Visual Studio tooling. Installing SignTool alone does not establish trust—the certificate used by it must meet the preceding requirements. ^2^
3. Compile and then sign the executable. For a certificate stored in the Windows certificate store, the general form is:

gcc main.c -o main.exe

signtool sign `
  /sha1 YOUR_CERTIFICATE_THUMBPRINT `
  /fd SHA256 `
  /tr RFC3161_TIMESTAMP_SERVER `
  /td SHA256 `
  main.exe

Replace the thumbprint and timestamp-server placeholder with values supplied for your signing service. Do not use a certificate selector belonging to an unrelated certificate.

4. Verify the result.

signtool verify /pa /v main.exe

The expected result is successful signature verification and a valid certificate chain. You can also open main.exe → Properties → Digital Signatures → Details → View Certificate → Certification Path to inspect the chain. ^4^

Automate compile-then-sign in VS Code

Place a task similar to this in .vscode/tasks.json, adjusting the certificate and timestamp placeholders:

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "compile",
      "type": "shell",
      "command": "gcc",
      "args": ["main.c", "-o", "main.exe"],
      "problemMatcher": ["$gcc"]
    },
    {
      "label": "sign",
      "type": "shell",
      "command": "signtool",
      "args": ["sign", "/sha1", "CERT_THUMBPRINT", "/fd", "SHA256",
               "/tr", "TIMESTAMP_SERVER", "/td", "SHA256", "main.exe"],
      "dependsOn": "compile",
      "dependsOrder": "sequence",
      "problemMatcher": []
    }
  ]
}

Run Terminal → Run Task → sign. Compilation must succeed before signing, and each rebuilt .exe must be signed again because compilation changes the file.

Confirm which policy blocked it

If a correctly signed build remains blocked:

1. Open Event Viewer.
2. Go to Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational.
3. Find the event matching the execution time:
   • 3077 means an enforced App Control policy blocked the file.
   • 3089 reports signature information; an unsigned file has TotalSignatureCount equal to 0.
4. Check whether the event names a policy other than Smart App Control. ^5^

If this personal PC has a work or school management profile, an organization’s App Control policy may also be present; that policy must be handled by its administrator.

Alternatives and security implications

• Separate development environment: Use another PC, VM, or operating-system environment whose execution policy permits unsigned development binaries. Merely moving the file or opening another shell on the same Smart App Control-enforced installation does not help.
• App Control for Business: Granular publisher, path, or hash rules belong to managed App Control for Business policies, not Smart App Control. This is generally an administrative deployment rather than a simple personal-PC exception. ^6^
• Disable Smart App Control: This permits unsigned development builds but reduces protection against untrusted applications. Prefer signing or an isolated development environment. Re-enabling behavior depends on the Windows build: older installations can require resetting or reinstalling Windows, while recent Windows updates support re-enabling from Windows Security on eligible devices. Check Windows Security → App & browser control → Smart App Control settings before making the change. ^7^ ^1^

References

1. Smart App Control Frequently Asked Questions | Microsoft Support
2. Sign your app for Smart App Control compliance
3. Artifact Signing trust models
4. How to troubleshoot app package signature errors
5. Understanding App Control events
6. Understand App Control for Business policy rules and file rules
7. App & browser control in the Windows Security App | Microsoft Support