Positron arm64 installer fails on Win11 ARM (build 28000) — diagnosis for posit-dev/positron#12957

Posted by Claude (Anthropic, via Claude Code) on behalf of @wesm, who reproduced this on his machine and asked me to share the investigation. Evidence below is from a live debugging session on his hardware — not speculation.

Repro environment

Snapdragon X2 Elite Extreme — Qualcomm Oryon, true ARM64
Windows 11 Pro, build 10.0.28000 (Canary)
$env:PROCESSOR_ARCHITECTURE = ARM64
Tested: Positron-2026.05.1-2-Setup-arm64.exe (and the matching UserSetup variant), Inno Setup 6.4.1, Authenticode signature valid (Posit Software, PBC via DigiCert G4 OV).
Compared against: VSCodeSetup-arm64-stable.exe (1.119.0, Microsoft Corporation signed) — works on the same machine, same session.

The smoking gun

Positron's installer log (failure):

Setup version: Inno Setup version 6.4.1
Compatibility mode: Yes (Installer)
Windows version: 10.0.28000
Windows architecture: x64 (64-bit)
Machine types supported by system: x86 x64
…
Message box (OK): This program does not support the version of Windows your computer is running.

VS Code's installer log on the same machine, same Windows session:

Setup version: Inno Setup version 6.4.1
Compatibility mode: Yes (Installer)
Windows version: 10.0.28000
Windows architecture: Arm64 (64-bit)
Machine types supported by system: x86 x64 Arm64

Identical Inno Setup version. Identical OS. Different IsWow64Process2 answer.

Bypass that pinpoints the discriminator

Rename Positron's installer in place — same NTFS file ID, same Authenticode signature, same Mark-of-the-Web Zone.Identifier ADS, same SHA — and run it under any other filename:

Original Setup EXE: C:\Users\wesmc\Downloads\PositronInPlaceRenamed.exe
Compatibility mode: Yes (DetectorsAppHealth Installer)
Windows version: 10.0.28000
Windows architecture: Arm64 (64-bit)
Machine types supported by system: x86 x64 Arm64

Wizard launches, install proceeds. Renaming back to Positron-2026.05.1-2-Setup-arm64.exe reproduces the failure immediately. Cross-rename is symmetric: copying VS Code's bytes to a Positron-…-Setup-arm64.exe filename does not break VS Code; copying Positron's bytes to a VSCodeSetup-arm64-… filename works fine. So the discriminator is the filename string interacting with something keyed in Windows, not the binary.

What's identical to VS Code (eliminated as causes)

I extracted both installers' resources and compared:

RT_MANIFEST: byte-identical (1960 chars). Same JR.Inno.Setup / processorArchitecture="x86" identity, same dpiAware, same requestedExecutionLevel="asInvoker", same <file loadFrom> redirections, same <supportedOS> GUID list (Vista → Win10; Microsoft never minted a Win11 GUID, so this is correct).
Inno Setup compiler version: 6.4.0.1 in both (Inno Setup Setup Data (6.4.0.1)).
PE machine of the SetupLdr stub: 0x014C (x86) in both — Inno's outer stub is always x86.
positron.iss is fine. It already has IsWindows11OrLater() (GetWindowsVersion >= $0A0055F0) and ARM64-aware [Code] guards, equivalent to VS Code's code.iss.

Where the path-keyed shim is not

Standard inspectable layers all came up empty for the failing path:

HKCU\…\AppCompatFlags\Compatibility Assistant\Store — clearing the entries does not unstick the failure.
HKCU\…\AppCompatFlags\Layers and HKLM\…\AppCompatFlags\Layers — no entry for either Positron .exe.
apphelp.dll, C:\Windows\AppPatch\sysmain.sdb, msimain.sdb, drvmain.sdb — no Positron string anywhere.
IFEO and AppCompatFlags subkeys recursively — nothing.

So this isn't a normal AppCompat shim. After clearing PCA, the Inno log even loses its Compatibility mode: Yes (Installer) line on the failing run, while the architecture is still faked. The fake is happening at a layer below PCA — most likely the WoW64 / x86-on-ARM64 emulation tiering decision, made before Inno's stub sees IsWow64Process2.

Hypothesis

Microsoft's cloud-distributed Compatibility Telemetry (CompatTelRunner.exe, Amcache pipeline) maintains an internal per-binary policy that decides how to host 32-bit installers on ARM64 — including whether to virtualize the native machine to AMD64 for "legacy" installers. The decision is keyed on signer + filename pattern + SmartScreen reputation, and Microsoft Corporation–signed binaries get an automatic exemption. Posit's OV cert (DigiCert G4 OV, not EV) on a fresh Positron-…-Setup-arm64.exe filename earns the legacy treatment. This would also explain why some users report the issue and others don't — reputation/telemetry decisions propagate gradually.

I could not confirm this against any inspectable on-disk database, which itself is suggestive: the policy isn't local.

Recommended actions for Posit

Microsoft App Assure (appassure@microsoft.com) is the right escalation. They handle Windows-on-ARM compatibility allow-listing for ISVs and frequently help free of charge for OSS/data-science tools. The repro above (two Inno Setup logs from the same machine, identical except for Windows architecture) is the cleanest case they'll see this year.
File a Feedback Hub bug under "Apps & Compatibility" on Canary build 28000. Title suggestion: WoW64 architecture virtualization incorrectly applied to ARM64-aware Inno Setup installer signed by non-Microsoft publisher. Attach both Inno logs.
Move the Windows code-signing cert from OV → EV. EV code signing carries SmartScreen reputation from day one, passes several PCA gates that OV signing fails, and eliminates "Unknown publisher" warnings on stable Windows. Worth doing independent of this bug.
Ship a fallback ZIP/portable build for ARM64 (analogous to VS Code's code-arm64.zip). Bypasses Inno Setup entirely; immune to any of this.

Stopgap for affected users today

Rename the .exe to anything not matching Positron-*-Setup-arm64.exe (e.g. PositronInstall.exe) before running. Same bytes, same signature, works.

Happy to share the full PowerShell session and registry dumps if useful — just ask. cc @wesm

wesm/positron-12957-comment.md

Select an option

No results found