[Bug] Windows: all subprocess tools fail with 0xC0000142 — probeWindowsJob never verifies the runner can actually start

[gkpsdsg]

Environment

• OS: Windows 11 Home (10.0.26200)
• Node: v24.15.0
• Packages: @deepseek-ai/dsh 0.1.5-rc.2 (npm global install), @deepseek-ai/dsh-subprocess-local
• Launch: dsh web (web profile, 127.0.0.1:3080), sandbox workspace-write

Symptom

Every subprocess-backed tool (pwsh, glob, grep) fails with:

Error: subprocess-local: Windows Job runner exited with exit code 3221225794
before proving its managed range empty

3221225794 = 0xC0000142 = STATUS_DLL_INIT_FAILED. Reproduces for any command
(even echo / "ok"). Pure file tools (read/write/edit) keep working. Within a
single session it worked for a while, then every subsequent spawn failed — consistent
with an environmental trigger, not a command-specific bug.

Root cause

The Windows containment path is fail-closed with no runtime fallback.

In packages/subprocess/subprocess-local (lib/index.js):

• selectContainmentMode() for kind === "ordinary" on win32 returns "windows-job"
  whenever probeWindowsJob() returns true, else "fallback".
• probeWindowsJob() only performs static checks: runnerInvocationAvailable() uses
  accessSync (file exists/readable), then loadWin32ProcessBindings() and
  probeCurrentTokenJobSupport() verify the bindings load. It never actually
  launches the runner.
• So when the runner (a node.exe child spawned by launchWindowsJob) cannot
  initialize — e.g. it exits at loader init with 0xC0000142, which we observed under a
  Lenovo PCManager / Huorong AV — the static probe still passes, DSH commits to
  "windows-job", and the otherwise-good spawnSubprocess direct-spawn fallback is
  never reached. The entire subprocess tool surface dies.

Proposed fix

Add a cheap real launch probe to probeWindowsJob() (per-spawn or cached): spawn the
runner via spawnSync with the same env, and treat "reached JavaScript" as healthy
(a bare runner without its IPC channel exits 127), while any NTSTATUS init failure
(status >= 0xC0000000, or any exit other than 127/null) means the runner cannot start
→ return false → selectContainmentMode falls back to spawnSubprocess.

Also worth improving: the close handler in launchWindowsJob discards the root cause
("exited with exit code N before proving its managed range empty"). Mapping the NTSTATUS
code to a name (0xC0000142 → STATUS_DLL_INIT_FAILED) plus a hint (antivirus/HIPS
injection, broken native dependency, desktop-heap exhaustion) would cut diagnosis time
dramatically. The runner's own stderr is also currently ignored.

I have a working patch (real-launch probe + fallback + error mapping) and can turn it
into a PR if you'd like — it restored pwsh/glob/grep immediately in the affected
environment.

[catsenior507]

Confirming this independently — same error, same OS build, different trigger.

Environment: Windows 11 Home China (10.0.26200), Node v24.16.0, koffi 3.3.1, dsh 0.1.5-rc.3 (launched via a local launcher, not npx).

Hit the exact same failure:

subprocess-local: Windows Job runner exited with exit code 3221225794
before proving its managed range empty

on a trivial command (node build-tree.js — pure JS, only require('fs') / require('path'), no native module). The target script is not the culprit; the crash is in the dsh-subprocess-local runner child while it loads the koffi FFI layer (dsh-win32-process → koffi → kernel32.dll / advapi32.dll).

A second trigger branch, distinct from AV injection. In my case it was not antivirus/HIPS. It was a degraded/orphaned host: a stale watchdog (supervisor.ps1, a self-written auto-restarter) had been re-spawning dsh web with a dead -HostPid, leaving the host in a degraded state. Under that host, the runner child failed at native-load time with 0xC0000142 — the same signature as the directory picker's worker.cjs (also koffi, via dsh-host-directory-picker-native), which died before its JS even ran. A clean host restart (kill the stale watchdog + all its spawned hosts, then npm run web) fixed both.

So the trigger surface is broader than AV injection: a long-lived host that has gone degraded makes the runner fail this exact way. Worth documenting because it means "restart the host" is a legitimate first-line fix, and the probe/fallback fix here would cover both trigger classes.

Strong +1 on both proposed fixes:

1. Real-launch probe + runtime fallback — probeWindowsJob() only checks that a Job can be created; it never actually launches the runner, so a runtime runner crash gives no fallback to plain spawn. This is exactly what would have saved me.
2. Map the NTSTATUS in the close handler — 0xC0000142 → STATUS_DLL_INIT_FAILED with a hint, instead of the bare 3221225794, which is currently meaningless to end users.