Deep-dive: why every Rust test binary died on Windows before running a single test (STATUS_ENTRYPOINT_NOT_FOUND)

[debpalash]

Part of a series of engineering deep-dives from VoiceStudio's reliability work. This one is about a Windows failure mode that will bite anyone adding integration tests to a Tauri app.

The symptom

While building our new backend-lifecycle fault-injection harness (#1551) — Rust integration tests that boot the real Tauri bootstrap code against scripted fake backends — Windows CI failed with:

error: test failed, to rerun pass `--test backend_lifecycle`
Caused by: process didn't exit successfully: `...backend_lifecycle-*.exe` (exit code: 0xc0000139, STATUS_ENTRYPOINT_NOT_FOUND)

No test output. No panic. No stack. The binary died before main ran, and only on Windows — macOS and Linux were green.

Bisecting a loader failure with CI

STATUS_ENTRYPOINT_NOT_FOUND means the Windows loader couldn't resolve an entry point in some imported DLL — it happens at load time, before any of your code executes. So nothing inside the test could be the cause, but which import was it?

We proved it with a one-round bisect: a temporary probe test file (tests/win_load_probe.rs) that linked the same crates but contained a single trivial test. It died with the same code — confirming the failure was pure link/load, independent of any test logic. (The probe was removed in the same PR once it had served its purpose.)

The root cause: comctl32 v5 vs v6

Tauri's dialog/tray stack imports TaskDialogIndirect from comctl32.dll. That function only exists in Common-Controls v6 — and Windows resolves v6 only for binaries whose manifest declares a dependency on it. Without that declaration, the loader falls back to comctl32 v5, which has no TaskDialogIndirect, and the process dies at load with STATUS_ENTRYPOINT_NOT_FOUND.

The app binary never hits this because tauri-build embeds a proper manifest into it. But cargo gives test binaries no manifest at all. So the moment a test binary links anything that imports TaskDialogIndirect, it becomes unrunnable on Windows — regardless of whether any test ever opens a dialog.

The fix

Embed a minimal Common-Controls v6 manifest into test binaries only, from build.rs:

if std::env::var("CARGO_CFG_TARGET_OS").as_deref() == Ok("windows") {
    let manifest = PathBuf::from(std::env::var("CARGO_MANIFEST_DIR").unwrap())
        .join("tests").join("windows-test.manifest");
    println!("cargo:rerun-if-changed={}", manifest.display());
    println!("cargo:rustc-link-arg-tests=/MANIFEST:EMBED");
    println!("cargo:rustc-link-arg-tests=/MANIFESTINPUT:{}", manifest.display());
}

with tests/windows-test.manifest declaring the single dependency:

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency><dependentAssembly>
    <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls"
      version="6.0.0.0" processorArchitecture="*"
      publicKeyToken="6595b64144ccf1df" language="*" />
  </dependentAssembly></dependency>
</assembly>

rustc-link-arg-tests scopes the linker args to test binaries, so the app build (which already gets its manifest from tauri-build) is untouched.

Takeaways

• If your Tauri (or any comctl32-touching) crate has zero cargo test integration tests on Windows, the first one you add may die at load. The failure is invisible until then.
• STATUS_ENTRYPOINT_NOT_FOUND on a test binary = look at imports and manifests, not at your code.
• A disposable CI probe binary is the cheapest bisect there is for load-time failures you can't reproduce locally.

The full harness this unblocked: #1551 — 9 fault-injection scenarios (crash loops, spawn failure, port conflict, startup timeout, deferred-init death) now run against the real supervisor code on all 3 OSes in CI.