Windows 11 blocks unsigned .NET 8 WPF application during development.

Use a dedicated development/test PC with Smart App Control in Evaluation or Off mode and install Microsoft’s SmartAppControlAuditNoISG audit policy; this permits frequent unsigned builds to run while recording which binaries would fail Smart App Control’s signing requirement.^1^

Identify the component and blocked file

1. Check Settings → Privacy & security → Windows Security → App & browser control → Smart App Control settings:
   • On means enforcement.
   • Evaluation evaluates without blocking.
   • Off means SAC is not enforcing.^2^
2. From an elevated command prompt, inventory active App Control policies:

      citool.exe -lp
   

3. Reproduce the failure, then open Event Viewer → Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational:
   • Event 3077: an executable, DLL, or driver was blocked.
   • Event 3076: it would have been blocked under enforcement.
   • Correlate the event with any 3089 signature event. Check File Name, Process Name, PolicyName, signing levels, and verification error.^3^
4. For MSI, scripts, or COM objects, also inspect Microsoft → Windows → AppLocker → MSI and Script. These two logs diagnose most App Control failures.^4^

Error 0x800711C7 is consistent with an Application Control block, but the event’s PolicyName and blocked-file path determine whether SAC, an organizational App Control policy, or another rule caused this instance.

Configure nonblocking development testing

Do this only on a dedicated test system. Installing the policy writes to the EFI system partition; preserve the original configuration and do not use this as an end-user workaround.

1. Put SAC in Evaluation or Off.
2. Download Microsoft’s sample audit policies from https://aka.ms/sacauditpolicies and extract SmartAppControlAuditNoISG.bin.
3. In an elevated command prompt, run:

      mountvol S: /S
      copy SmartAppControlAuditNoISG.bin S:\efi\microsoft\boot\cipolicies\active\{5283AC0F-FFF1-49AE-ADA1-8A933130CAD6}.cip
      citool.exe -r
      citool.exe -lp
   

4. Confirm the listed policy name is VerifiedAndReputableDesktopEvaluationAuditNoISG.
5. Rebuild and exercise every application path, including Graphtec communication, installers, updates, and uninstallers. Review 3076 audit events for every EXE or DLL that would be rejected.

This audit policy does not create a per-application exception. Builds run because SAC is Evaluation/Off, while the policy reports failures against the signing requirement. Evaluation can transition automatically, so periodically check citool.exe -lp.

Signing choices

Commercial/publicly trusted signing is not mandatory for isolated development, but it is the reliable route for running under consumer SAC enforcement. SAC permits recognized code or code signed by a certificate from a trusted provider; unknown unsigned code is blocked by default.^2^

• Local or managed development: A self-signed/internal certificate can be explicitly trusted on controlled machines. Under App Control for Business, the administrator must also add an applicable certificate, publisher, catalog, or managed-installer rule to the policy. Merely installing a self-signed certificate locally does not make it acceptable to consumer SAC enforcement.
• SAC-compatible direct distribution: Sign the application with Azure Artifact Signing—the preferred Microsoft option—or a valid code-signing certificate from a trusted provider.^5^
• Sign all shipped code, including EXEs, DLLs, installer/bootstrapper files, scripts, temporary installer binaries, and uninstallers.^6^

Transition to first users

1. Produce a release build and sign every binary.
2. Test installation, all features, plotter integration, update, and uninstall under SAC enforcement.
3. For direct distribution, use trusted code signing; new signatures can still require reputation to build.
4. Alternatively, publish an MSIX through Microsoft Store, which signs the package during certification. Store submission of an MSI/EXE still requires the installer and PE files to be signed.^7^

References

1. Test App Signatures with Smart App Control - Windows apps
2. Smart App Control - Windows apps | Microsoft Learn
3. App Control debugging and troubleshooting
4. Understanding App Control events
5. Sign your app for Smart App Control compliance - Windows apps
6. Application and driver control
7. Publish your first Windows app