Windows desktop build intermittently fails with STATUS_DLL_INIT_FAILED (0xC0000142) in parallel vp tasks

[eddy-curly]

Summary

pnpm dist:desktop:win:x64 intermittently fails on Windows during stage 1 of 5 ("Building desktop/server/web artifacts"). The @t3tools/desktop#build task exits with -1073741502 = 0xC0000142 = STATUS_DLL_INIT_FAILED, which is a Windows process startup failure, not an error raised by our code.

Re-running the identical command with no changes succeeded, so this is a flake rather than a reproducible defect.

Observed

vp run: 0/3 cache hit (0%), 1 failed.

  [1] @t3tools/web#build:     vp build                                        OK
  [2] t3#build:               node scripts/cli.ts build                       OK
  [3] @t3tools/desktop#build: node scripts/build-preview-annotation-css.mjs   FAILED (exit code: -1073741502)

The web and server bundles both built fine; only the third parallel task died.

Evidence it is environmental, not a code bug

• node scripts/build-preview-annotation-css.mjs run standalone from apps/desktop exits 0.
• The script is not new — it predates the current sync (last touched by 2fa37ec1, 3d9e8dea, dd739c88).
• An immediate retry of the same pnpm dist:desktop:win:x64 completed successfully end-to-end (~18 min) and produced a valid NSIS artifact.
• 0xC0000142 on Windows typically indicates DLL initialisation failing at process start, commonly under desktop-heap/session resource pressure when several processes are spawned concurrently.

Environment

• Windows 11 Pro 10.0.26200
• node 24.15.0, pnpm 11.10.0
• Three vp build tasks running in parallel, with cache disabled for all three

Why it matters beyond the flake itself

The failure mode is quiet in a way that can cause real damage downstream. A failed build leaves no new artifact in release/. Any tooling that then picks "the newest release/*.exe" silently selects a stale installer from a previous build. Because the fork's package version does not bump between syncs (0.0.31 -> 0.0.31), reinstalling that stale artifact reports the same FileVersion before and after, and is indistinguishable from a successful update unless the file timestamp is checked.

So a transient build flake can turn into a silent downgrade/no-op reinstall that reports success.

Suggested fix

1. Retry transient process-spawn failures (0xC0000142 and the related 0xC0000005/-1073741819 family) a small number of times before failing the task, or serialise the desktop task rather than running all three concurrently.
2. Translate these numeric exit codes into a readable diagnostic. exit code: -1073741502 gives no indication that this is a Windows resource condition and not a build error, which sends people debugging the wrong thing.

Test case needed

A regression test cannot reliably reproduce 0xC0000142 itself, so the test should target the contract around it rather than the flake:

• Build-failure contract: given a stage that exits non-zero, assert build-desktop-artifact.ts produces no artifact in release/ and propagates a non-zero exit — i.e. a failed build can never leave a partially-written or stale-looking artifact behind. This is the behaviour that makes the flake dangerous.
• Artifact-freshness contract: assert that any consumer selecting an installer refuses one not strictly newer than what is already installed, and verifies success by on-disk timestamp/size change rather than by version string. Simulate with fixtures: stale artifact, equal-timestamp artifact, fresh artifact.
• Exit-code mapping: unit-test that known Windows fatal status codes map to human-readable messages, so a recurrence is diagnosed from the log rather than from a bare negative integer.