Reject ARM64EC Windows runtime DLLs

[AnthonyRonning]

Summary

• fix Windows VC++ runtime staging to reject ARM64EC payloads that report AMD64 in the PE Machine field
• verify packaged Windows installers contain native AMD64 runtime payloads, not ARM64EC DLLs
• document why the extra ARM64EC guard exists

Investigation

Issue #594 reports an Intel x64 launch crash in VCRUNTIME140_1.dll with c000001d. The v3.1.2 installer payload is x64 overall, but the bundled VCRUNTIME140_1.dll contains an ARM64EC PDB marker:

binaries\\arm64ret\\bin\\arm64ec\\vcruntime140_1.arm64.pdb

The other VC runtime DLLs are native AMD64. ARM64EC can pass a plain AMD64 PE Machine check, so the old staging script could select the wrong redist payload deterministically.

Verification

• nix develop .#ci -c python3 -m py_compile scripts/ci/canonical-windows-nsis-payload-hash.py
• bash -n scripts/ci/verify-release-artifacts.sh
• git diff --check
• nix develop .#ci -c python3 scripts/ci/canonical-windows-nsis-payload-hash.py --verify-runtime-dlls /tmp/maple-win-issue-594/Maple_3.1.2_x64-setup.exe Maple_3.1.2_x64-setup.exe fails on published v3.1.2 as expected: VCRUNTIME140_1.dll is ARM64EC
• nix develop .#ci -c ./scripts/ci/verify-release-artifacts.sh /tmp/maple-win-issue-594 windows fails on published v3.1.2 as expected before accepting the bad payload
• pre-commit hook via nix develop .#ci -c git commit ...: Prettier check, frontend build, Bun tests

Fixes #594

Summary by CodeRabbit

• New Features
  • Added Windows installer runtime payload verification to release artifact checks, validating expected runtime components are native AMD64 and excluding ARM64EC.
• Bug Fixes
  • Strengthened Windows staging safeguards with stricter architecture detection (including ARM64EC byte/PE checks) and added runtime DLL assertions before and after staging.
  • Enhanced CI reporting with per-file native/ARM64EC classification and SHA-256 digests for verified payloads.
• Documentation
  • Updated Windows CI staging documentation to clarify ARM64EC/AMD64 PE “Machine” behavior and the installer payload selection rules.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 11 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 48afa0a1-af02-460d-96bf-828fbec71582

📥 Commits

Reviewing files that changed from the base of the PR and between 22a49f8 and a7583d5.

📒 Files selected for processing (4)

• frontend/src-tauri/resources/windows/README.md
• frontend/src-tauri/scripts/stage-windows-runtime-dlls.ps1
• scripts/ci/canonical-windows-nsis-payload-hash.py
• scripts/ci/verify-release-artifacts.sh

📝 Walkthrough

Walkthrough

Adds ARM64EC detection to Windows runtime DLL staging, a new --verify-runtime-dlls installer payload verification mode, and release-artifact wiring that runs the runtime DLL check after Windows manifest verification.

Changes

ARM64EC Filtering for Windows Runtime DLLs

Layer / File(s)	Summary
Staging helpers and DLL assertions frontend/src-tauri/scripts/stage-windows-runtime-dlls.ps1, frontend/src-tauri/resources/windows/README.md	Adds ARM64EC-aware byte scanning, native AMD64 assertions, candidate filtering, diagnostic classification output, and post-copy validation in the Windows runtime staging script; the README records the VC++ redistributable packaging note.
Installer runtime payload verification scripts/ci/canonical-windows-nsis-payload-hash.py	Adds the AMD64 machine constant, expected payload file list, PE parsing and ARM64EC marker detection helpers, extracted-file resolution, runtime payload verification, and the CLI branch for --verify-runtime-dlls.
Release verification wiring scripts/ci/verify-release-artifacts.sh	Adds Windows setup label extraction from the final manifest, resolves the matching installer artifact, runs the runtime payload verifier, and invokes it from verify_windows() after the final manifest check.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• OpenSecretCloud/Maple#563: Introduced the Windows artifact verification flow that this PR extends with runtime DLL native-AMD64 checks.
• OpenSecretCloud/Maple#575: Modified verify_windows() in scripts/ci/verify-release-artifacts.sh, the same release-verification path extended here.
• OpenSecretCloud/Maple#586: Touched the Windows runtime DLL verification area that this PR augments with --verify-runtime-dlls.

Poem

🐇 I hop through DLLs with a byte-by-byte glance,
ARM64EC gets no sneaky chance.
Native AMD64, straight and true,
Now marches into the installer queue.
Hop, hop—Windows runtime, verified bright!

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: rejecting ARM64EC Windows runtime DLLs.
Linked Issues check	✅ Passed	The changes directly address #594 by rejecting ARM64EC payloads and verifying only native AMD64 runtime DLLs are packaged.
Out of Scope Changes check	✅ Passed	The modified scripts and docs all support Windows runtime DLL validation and installer verification, with no clear unrelated additions.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/windows-vc-runtime-arch-selection

---

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying maple with    Cloudflare Pages

Latest commit:	a7583d5
Status:	✅  Deploy successful!
Preview URL:	https://5f1f68ad.maple-ca8.pages.dev
Branch Preview URL:	https://fix-windows-vc-runtime-arch.maple-ca8.pages.dev

View logs

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.