[Bug][Windows 11] pwsh tool spawns fail with 0xC0000142 (STATUS_DLL_INIT_FAILED) — no output, any command, reproducible

[krt-krt]

Summary

All subprocess invocations through DSH Desktop's pwsh tool fail on Windows 11 with no stdout/stderr output and a fixed exit code 3221225794 (= `0xC0000

Environment

• OS: Windows 11 (build 10.0.26100.0)
• App: DeepSeek Harness Desktop (Electron-based), installed at C:\Users\Administrator\AppData\Local\Programs\DeepSeek Harness
• Runtime dir: C:\Users\Administrator\.dsh-desktop\dsh-runtimes\dsh-primary-runtime\dependencies\
• Antivirus: Windows Defender only (no third-party AV)

Reproduction Steps

1. Open a DSH Desktop session.
2. Ask the agent to run any trivial command via the pwsh tool, e.g. Write-Output "test".
3. Observe the tool result.

Expected Result

Command executes normally, stdout captured and returned.

Actual Result

• stdout/stderr: completely empty
• exit code: 3221225794 (decimal) = 0xC0000142 (hex) = STATUS_DLL_INIT_FAILED
• Happens regardless of command content (Write-Output, Get-Date, python -c ..., node -e ... all fail identically)
• Reproducible every time; not intermittent
• No Application Error entries appear in Windows Event Viewer (consistent with failure occurring during process/DLL initialization, before WER kicks in)

Control Experiment (decisive)

In a plain PowerShell terminal outside DSH, on the same machine, same binaries:

PS C:\Users\Administrator> python -c "print('PY_ALIVE')"
PY_ALIVE
PS C:\Users\Administrator> node -e "console.log('NODE_ALIVE')"
NODE_ALIVE

Both succeed with exit code 0. This rules out system-level corruption (SFC/DISM clean, VC++ redist reinstalled, no AV interference) and isolates the problem to DSH's subprocess-spawning / output-capture path.

Additional Clues Found in DSH's Own Artifacts

• crash-2026-10-06T07-25-23-644Z-host.log shows dsh desktop host exited with 1073807364 (= 0x40010004, a different code, suggesting a separate host-level instability around the same timeframe).
• crash-2026-09-28T15-37-19-883Z-web-boot.log shows @deepseek-ai/dsh-client-runtime/client module missing → 1 entry did not activate (build-time externals drift — possibly unrelated but worth noting).
• From app.asar's internal subprocess/win32-process/README.md (as found by another agent inspecting the packaged artifact):

  "Console isolation is unavailable — children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED (0xC0000142); children share the host console, and pipe-based stdio redirection is unaffected."
  "The logon SID + EVERYONE keep-alive group is present in both modes: without it, early DLL initialization dies with 0xC0000142 and CNG crashes pwsh with 0xE0434352."
  Code comment: "FAILS CLOSED: any failure throws — never spawn unrestricted"
  This suggests the failure mode is a known boundary condition in DSH's restricted-token / DACL sandbox design (write-restricted token + Low integrity + CREATE_NO_WINDOW), possibly misconfigured or broken in this environment.

Keywords for Search / Triage

0xC0000142, STATUS_DLL_INIT_FAILED, CREATE_NO_WINDOW, CREATE_NEW_CONSOLE, subprocess/win32-process, write-restricted token, DACL sandbox, "Console isolation is unavailable", "FAILS CLOSED"

Suggested Investigation

Given the control experiment (same binaries work outside DSH), this looks like either:

1. A bug in DSH's CREATE_NO_WINDOW-flagged process creation combined with its restricted-token/DACL sandbox, causing DLL init failure specifically in that spawn path; or
2. A bug in DSH's stdout/stderr pipe-capture layer — the process may actually run, but output is silently lost and a bogus exit code is reported back.
   A quick way to distinguish: have DSH run a command that writes to a file instead of stdout (e.g. python -c "open(r'C:\temp\probe.txt','w').write('ALIVE')"), then check outside DSH whether the file was actually created/modified. If the file gets written but DSH reports "no output / exit 3221225794", the bug is in output capture, not process creation.

---

[kaganoxcw]

Same failure reproduced independently over here: #8991.

That report adds a data point this one does not have: there, DSH's own shell had already resolved to PowerShell 7.6.6 (PSHOME = C:\Program Files\PowerShell\7), and the confined call still died with 0xC0000142. So the failure is not explained by pwsh being absent from PATH.

It also reproduces on Windows 11 build 22631 (23H2) with a machine-wide install, whereas this report is build 26100 (24H2) with a per-user install — so the bug is not specific to either.