Windows 11 Smart App Control: How to safely test unsigned .NET 8 WPF applications without commercial code signing?

Use a separate, persistent Windows 11 VM for unsigned development builds, leaving Smart App Control unchanged on the host; use Windows Sandbox only for disposable tests that do not require reliable access to the Graphtec USB device.

Recommended workflow

1. Preserve the working release
   • Copy its installer, executable, DLLs, configuration, and plotter profiles to a versioned, read-only backup.
   • Do not overwrite its installation directory with development outputs.
   • Keep development builds in distinct versioned folders or package identities.
2. Create a persistent Windows 11 Hyper-V VM
   • Install Visual Studio/.NET 8, the Graphtec software and drivers, and your source/build tools in the VM.
   • Take a clean checkpoint before installing test builds.
   • Configure the VM’s own App Control state for development, rather than altering the host.
   • Keep host Smart App Control enabled. A VM has its own Windows installation and policy state; changes inside it do not change the host policy.
3. Test ordinary UI and installer behavior in Windows Sandbox
   • Sandbox is hardware-isolated and disposable; closing it removes installed software, files, and state. It is appropriate for clean-install and smoke tests, but not as the primary development environment ^1^.
   • Map only a build-output directory, preferably read-only. Mapped folders expose host data to the sandbox, while networking and clipboard sharing are enabled by default ^2^.

<Configuration>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\STCut\TestBuild</HostFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

4. Test the physical plotter separately
   • Hyper-V does not provide general native USB passthrough. Enhanced Session Mode can redirect supported devices, but not every specialized USB plotter interface is guaranteed to appear or operate correctly ^3^.
   • In Hyper-V Manager → Hyper-V Settings, enable Enhanced Session Mode Policy and Enhanced Session Mode. Reconnect to the VM, select Show Options → Local Resources → More, and check whether the plotter appears under supported Plug and Play devices ^4^.
   • If the plotter cannot be redirected, use a separate physical Windows test installation/device for final cutting tests. The available documentation does not establish that this Graphtec model supports Hyper-V redirection.

Running unsigned builds on the main laptop

Smart App Control enforcement has no documented per-application developer exception for repeatedly rebuilt unsigned binaries. It allows code recognized by Microsoft’s intelligence service or code signed by a certificate issued through a CA in the Microsoft Trusted Root Program; unknown unsigned code is blocked by default ^5^.

Therefore, there is no supported way to guarantee that frequently changing unsigned builds will run on the SAC-enforced host without changing that enforcement model. Cloud reputation is also unsuitable for development outputs because every rebuild can produce different binaries.

The previously suggested SmartAppControlAuditNoISG policy is a testing policy, not a host allow-list. It audits signing compliance and requires SAC to be in Evaluation or Off mode; installing it in the EFI policy location would also conflict with your stated requirement not to modify EFI policy ^6^.

Do not force SAC modes through the registry on the primary installation. Microsoft labels that procedure as testing-only and warns that it can compromise SAC protection ^6^.

Self-signed development certificates

A self-signed certificate is appropriate for local development—particularly for an MSIX package—when the certificate is explicitly trusted on the test machine. It is not a substitute for a publicly trusted signing identity and does not satisfy SAC’s documented trusted-CA requirement for an otherwise unknown app ^7^.

For an MSIX build, Microsoft documents generating and installing a local certificate, then signing the package:

winget install -e --id Microsoft.WinAppCLI --source winget
winapp cert generate --manifest .\appxmanifest.xml `
  --output .\devcert.pfx --install
winapp sign .\STCut.msix --cert .\devcert.pfx

WinApp CLI is currently public preview. The certificate subject must match the package manifest’s Publisher value ^8^.

Keep the PFX private, use a non-default password, trust it only in development VMs, and remove its trust when testing ends. For unpackaged EXE/DLL builds, SignTool can Authenticode-sign and verify files, but locally trusting that certificate still does not turn it into a Trusted Root Program CA identity for SAC ^9^.

Confirming error 0x800711C7

0x800711C7 means an Application Control policy blocked a file; it does not, by itself, prove that Smart App Control was the specific policy. The same HRESULT is reported for DLL-load failures caused by Application Control ^10^.

On the affected laptop:

1. Run an elevated PowerShell window:

$dir = "$env:LOCALAPPDATA\Temp\DiagOutputDir\CiDiag"
cidiag.exe /stop
citool.exe -lp -json > "$dir\CiToolOutput.json"
msinfo32.exe /report "$dir\SystemInformation.txt"

2. Open Event Viewer → Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational.
3. Reproduce the failure and find:
   • 3077: file blocked by an enforced policy.
   • 3076: file would be blocked by an audit policy.
   • 3089: correlated signature details; TotalSignatureCount = 0 identifies an unsigned file.
4. In event details, inspect File Name, Process Name, PolicyName, PolicyId, requested/validated signing levels, and correlate 3089 events using ActivityID.
5. Also inspect Applications and Services Logs → Microsoft → Windows → AppLocker → MSI and Script for installer or script blocks.

CiToolOutput.json identifies every active policy, while the 3076/3077 event’s PolicyName identifies which policy rejected that particular file ^11^ ^12^.

For eventual distribution, sign every executable, DLL, installer, temporary installer component, script, and uninstaller—not only the main WPF executable ^13^.

References

1. Windows Sandbox
2. Use and configure Windows Sandbox
3. YubiKey USB device doesn't appear in a Hyper-V virtual machine
4. Share devices with your Hyper-V virtual machine
5. Smart App Control overview
6. Test your app's signature with Smart App Control
7. Code signing options for Windows app developers
8. Sign your MSIX package: end-to-end guide
9. Windows Desktop Application Program
10. Application Error - Microsoft Q&A
11. App Control debugging and troubleshooting
12. Understanding App Control events
13. Application and driver control