The Windows build fix was the only part of last night's work living outside git — two junctions created by hand on the build VM.
Tauri downloads candle.exe, light.exe and makensis.exe, and all three are 32-bit. A runner running as SYSTEM has %LOCALAPPDATA% under C:\Windows\System32\config\systemprofile, and WOW64 redirection serves any 32-bit process reading System32 from SysWOW64 — where those directories don't exist. The bundlers can't see their own folder: candle exits 0x80131700, makensis reports Unable to start child process, error 0x2, and Tauri surfaces neither, only failed to run candle.exe.
Rebuild the VM, add a second Windows runner, or reset the SYSTEM profile, and Windows breaks again with an error pointing nowhere near the cause.
The job now creates the junctions itself when it detects a profile inside System32, and skips entirely otherwise — so a runner running as a normal user is unaffected. Idempotent, and written with goto rather than nested if blocks to avoid the delayed-expansion trap that already bit the MSVC step.
Verified rather than assumed: the hand-made junctions were deleted from the build VM before this branch was pushed, so this run has to recreate them from scratch. A green build-windows here means the step genuinely works on a machine that does not already have the workaround.
The Windows build fix was the only part of last night's work living outside git — two junctions created by hand on the build VM.
Tauri downloads `candle.exe`, `light.exe` and `makensis.exe`, and **all three are 32-bit**. A runner running as SYSTEM has `%LOCALAPPDATA%` under `C:\Windows\System32\config\systemprofile`, and WOW64 redirection serves any 32-bit process reading `System32` from `SysWOW64` — where those directories don't exist. The bundlers can't see their own folder: candle exits `0x80131700`, makensis reports `Unable to start child process, error 0x2`, and Tauri surfaces neither, only `failed to run candle.exe`.
Rebuild the VM, add a second Windows runner, or reset the SYSTEM profile, and Windows breaks again with an error pointing nowhere near the cause.
The job now creates the junctions itself when it detects a profile inside System32, and skips entirely otherwise — so a runner running as a normal user is unaffected. Idempotent, and written with `goto` rather than nested `if` blocks to avoid the delayed-expansion trap that already bit the MSVC step.
**Verified rather than assumed:** the hand-made junctions were deleted from the build VM before this branch was pushed, so this run has to recreate them from scratch. A green `build-windows` here means the step genuinely works on a machine that does not already have the workaround.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01KSP2KNPhuWKQ4DL5TZEn3k
The Windows fix was the only part of it living outside git — two
junctions created by hand on the build VM. Rebuild that VM, add a second
Windows runner, or reset the SYSTEM profile and Windows builds break
again with an error that points nowhere near the cause.
Tauri downloads candle.exe, light.exe and makensis.exe, and all three
are 32-bit. A runner running as SYSTEM has %LOCALAPPDATA% under
C:\Windows\System32\config\systemprofile, and WOW64 redirection serves
32-bit processes reading System32 from SysWOW64, where those directories
do not exist. The bundlers cannot see their own folder: candle exits
0x80131700, makensis reports "Unable to start child process, error 0x2",
and Tauri surfaces neither — only "failed to run candle.exe".
The job now junctions the SysWOW64 view onto the System32 originals when
it detects a profile inside System32, and skips entirely otherwise, so a
runner running as a normal user is unaffected. Idempotent, and written
with goto rather than nested blocks to avoid the delayed-expansion trap
that already bit the MSVC step.
Verified rather than assumed: the hand-made junctions were deleted from
the build VM before this was pushed, so this run has to recreate them.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
jknapp
merged commit 584fcdd837 into main2026-08-10 15:00:25 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The Windows build fix was the only part of last night's work living outside git — two junctions created by hand on the build VM.
Tauri downloads
candle.exe,light.exeandmakensis.exe, and all three are 32-bit. A runner running as SYSTEM has%LOCALAPPDATA%underC:\Windows\System32\config\systemprofile, and WOW64 redirection serves any 32-bit process readingSystem32fromSysWOW64— where those directories don't exist. The bundlers can't see their own folder: candle exits0x80131700, makensis reportsUnable to start child process, error 0x2, and Tauri surfaces neither, onlyfailed to run candle.exe.Rebuild the VM, add a second Windows runner, or reset the SYSTEM profile, and Windows breaks again with an error pointing nowhere near the cause.
The job now creates the junctions itself when it detects a profile inside System32, and skips entirely otherwise — so a runner running as a normal user is unaffected. Idempotent, and written with
gotorather than nestedifblocks to avoid the delayed-expansion trap that already bit the MSVC step.Verified rather than assumed: the hand-made junctions were deleted from the build VM before this branch was pushed, so this run has to recreate them from scratch. A green
build-windowshere means the step genuinely works on a machine that does not already have the workaround.🤖 Generated with Claude Code
https://claude.ai/code/session_01KSP2KNPhuWKQ4DL5TZEn3k