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.

[radroid]

Priority triage — 2026-08-07: Rank 11 / 11 — Tier 7 (environmental flake, mitigate not fix)

Lowest priority: STATUS_DLL_INIT_FAILED (0xC0000142) is a Windows process-startup flake, non-reproducing, and an immediate retry succeeded. Right response is a retry-on-exit mitigation, not a prioritized fix.

[radroid]

Triage 2026-08-07 — the dangerous half is already addressed; keep this open for the diagnostic half

The update-delivery design (PR #51) names this issue in its Closes: line as "#47 (stale-artifact hazard — the contract half)", and the implementation on t3x/update-delivery-impl carries build identity as t3codeCommitHash (12 chars) + a build counter rather than the package version. That directly removes the failure this issue calls out as the reason it matters beyond the flake — "the fork's package version does not bump between syncs (0.0.31 → 0.0.31)… indistinguishable from a successful update." A commit-hash identity cannot collide between two builds of different trees.

Related, and worth knowing: upstream has cut be1a83674 chore(release): prepare v0.0.32, which is inside the unmerged 103-commit backlog (#49). So the version does move after the next sync — but only once per upstream release, which is still far coarser than per-build, and so it does not by itself fix the ambiguity.

What is not covered and should keep this issue open

Neither #51 nor the sync addresses the exit-code mapping half, which is the part that makes a recurrence expensive to diagnose: exit code: -1073741502 gives no indication that 0xC0000142 is a Windows process-startup/DLL-init condition rather than a build error. That is a small, self-contained, platform-specific improvement with no seam cost, and it is worth keeping regardless of how delivery is built.

The retry/serialisation suggestion is more debatable — retrying a transient spawn failure hides resource pressure that may be worth surfacing. Recommend the readable diagnostic first, and only add retry if it recurs after that.

Priority: low, and unblocked — it does not depend on #49.