DSH plugin: Windows subprocess fails with 0xC0000142

The symptom is "the process never started": on Windows, all of DSH's shell tools (pwsh / cmd) fail with the decimal exit code 3221225794 (0xC0000142 / STATUS_DLL_INIT_FAILED), stdout and stderr are both empty, and occasionally a system-level modal dialog says "the application was unable to start correctly (0xc0000142)". It has two distinct causes that produce the same exit code: one is creating a subprocess with CREATE_NO_WINDOW (i.e. windowsHide: true) under a restricted token — the boundary is exactly that one flag, and switching to STARTF_USESHOWWINDOW | SW_HIDE works; the other is the double-click-launched GUI desktop host combined with a failed integrity downgrade, where the token stays at Medium yet carries a write restriction. It does not make it into the DSH session log (tool returns show only exit code 1), so you must find evidence in the Windows event log and in single-variable experiments that swap the host.

Triage first: 0xC0000142 means "the process did not start" — figure out which chain you are on

Bottom line up front: 0xC0000142 only tells you "the subprocess died during DLL initialization"; it does not by itself distinguish the cause. The reports contain two completely different mechanisms that produce the same exit code; the value of triage is separating them first, or you will keep probing at the wrong layer.

The first criterion is the environment: is it the command-line dsh web host failing, or the double-click-launched desktop app? One report states explicitly that on the same machine, same version, same sandbox config, the sandbox boundary inside the command-line host is entirely normal — writes outside the workspace are denied (UnauthorizedAccessException), writes inside pass, and whoami.exe is denied (the signature of a restricted token being in effect). That says "the sandbox is not broken"; it is the host environment that is isolated.

The second criterion is whether you can get evidence. Remember this first: this failure does not enter the DSH session log. One report decompressed the archives of four local sessions frame by frame and searched them; the only exit code appearing in tool returns was 1, and 0xC0000142 / 3221225794 appeared zero times — the error happens at the subprocess-creation stage, the upper layer only gets "no output / exit code 1", and the real exit code is dropped during formatting. The authoritative source is therefore the Windows system event log (source Application Popup, event ID 26), but it cannot be treated as a reliable signal either: of the same failures, some record an event and some do not; the truly reliable criterion is the exit code (#6930).

The third criterion is single-variable. First narrow the environment down to one variable with a minimal probe:

const { spawnSync } = require("child_process");

// fails
spawnSync("cmd.exe", ["/c", "exit"], { stdio: "ignore", windowsHide: true  });
// => status 3221225794  (0xC0000142)

// succeeds
spawnSync("cmd.exe", ["/c", "exit"], { stdio: "ignore", windowsHide: false });
// => status 0

With stdio fixed to ignore and detached unset, the only remaining variable is the single boolean windowsHide. This is the foundation for every conclusion in the next two sections (#6930).

Cause one: creating a subprocess with CREATE_NO_WINDOW under a restricted token

Root cause: DSH launches managed subprocesses unconditionally with windowsHide: true on Windows; Node's windowsHide: true is implemented by CREATE_NO_WINDOW; and creating a subprocess with the console-isolation flag under a restricted token makes it die during DLL initialization — a limitation the project's own sandbox docs already recorded.

The code fact (packages/subprocess/subprocess-local/src/spawn.ts):

windowsHide: platform === 'win32'

On win32 it is unconditionally true, and this layer has no environment variable or config switch. The helper processes are the same: spawn.ts:120 (the taskkill cleanup), windows-inspector.ts:155, windows-job.ts:141 (the last one added in alpha.2, which puts windowsHide: true even on the sandbox runner's spawn) (#6930).

The project docs had long since written down this failure mode (packages/sandbox/sandbox-windows-acl/README.zh.md, the "console isolation unavailable" section):

Subprocesses created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED (0xC0000142); subprocesses share the host console, and pipe-based stdio redirection is unaffected.

The reporter used a set of single-variable matrices to pin "restricted token + CREATE_NO_WINDOW" as a sufficient condition (all within one session, using whoami's exit code as the token criterion):

Three conclusions come straight off this table: under an ordinary token, hide=true returns 0 across the board; under a restricted token, the same row deterministically returns 0xC0000142; and windowsHide=false succeeds under both tokens. On that basis the reporter corrected his own earlier judgment that this was "an intermittent defect" — that was an illusion from two measurements landing under different file policies; under identical conditions it is deterministic (#6930).

There is a finer boundary worth copying down: what actually causes the disease is not the intent of "hiding the window" but the single flag CREATE_NO_WINDOW.

So "hide the window with SW_HIDE" is safe under a restricted token. This also explains why the upstream direction is correct: commit f8b1309fe5 in 0.1.6-alpha.2 ("hide Windows shell console windows at creation") adds windowsHide: true to the Node Job runner's launch, but the native process creation deliberately does not add CREATE_NO_WINDOW, using STARTF_USESHOWWINDOW | SW_HIDE instead; the comment in win32-process/src/process.ts says it plainly: "Preserve console inheritance: CREATE_NO_WINDOW can fail restricted-token DLL initialization", and that commit's description lists "remove consoles from every process" as a rejected alternative (#6930).

Cause two: the desktop GUI host and a failed integrity downgrade

The second chain appears on the double-click-launched desktop app, with a different mechanism yet the same exit code. Two independent findings together explain it: (1) the host binary itself is the decisive variable — a GUI-subsystem process does not own a console; (2) the "lower the restricted token's integrity level to Low" step introduced in newer versions fails on the default account (missing SeRelabelPrivilege), so the token stays at Medium while carrying WRITE_RESTRICTED.

Finding one: swap the host and the result changes. The reporter ran a decisive A/B — same machine, same official ACL runner, same subprocess, same argv, changing only the host binary that carries the runner:

And he measured "does the host own a console" directly (launching both hosts from the same console-bearing parent process with the same stdio, each calling kernel32!GetConsoleWindow() via koffi):

There is a logic trap worth remembering on its own here: "launching the desktop exe from a terminal that has a console still fails" cannot be used to refute the console hypothesis — on Windows a GUI-subsystem process does not attach to the parent's console, and it was measured that even started from a console-bearing parent it still has GetConsoleWindow() == NULL. To isolate the variable correctly, fix everything else and swap only the host binary — that is the table above (#6822).

Finding two: the integrity downgrade fails, with no fail-closed. Another reporter compared a local source checkout against the installed app.asar and found a function that exists only in the released binary and not at all in the source tree:

// present in the installed 0.2.0-rc.2; entirely absent from token.ts in source
function restrictTokenIntegrity(api, token, lowLabelSidPtr) {
    ...
    api.setTokenInformation(token, 25, info, info.length)
    // "Lower the restricted token's integrity level to Low (S-1-16-4096) ...
    //  a token left at Medium would ignore them"
}

TokenIntegrityLevel appears 0 times in that source checkout and 1 time in the released package — because the checkout was too old (0.1.2-alpha.4) to contain this critical path. And this step is failing on that machine: lowering a token's integrity level requires SeRelabelPrivilege, and the measured account state was IsInRole(Administrator) = True, integrity level High, with SeDebugPrivilege present but SeRelabelPrivilege entirely absent (that privilege is not granted by default). So:

1. CreateRestrictedToken(..., WRITE_RESTRICTED) succeeds → the token now carries a write restriction;
2. SetTokenInformation(TokenIntegrityLevel, Low) fails, returning Win32 998 (ERROR_NOACCESS);
3. the token therefore stays at Medium integrity yet already carries WRITE_RESTRICTED;
4. the downgrade that was supposed to reconcile the two never happened;
5. the subprocess dies during DLL initialization → 0xC0000142, and because it dies before executing the command, stdout/stderr are empty.

This also explains why cmd.exe is as affected as pwsh — it takes the same restricted path, independent of the shell (#6822).

A reproducible decisive experiment (same session, no DSH restart, no config change, only switching the file policy):

The only variable is the file sandbox policy: under workspace-write it fails every time, under danger-full-access it passes every time. This simultaneously rules out three alternative explanations: "the troubleshooting broke DSH" (it reproduces after switching back), "it needs a restart to recover" (there was no restart between the three rounds), and "the session state went bad" (it reproduces immediately after switching, with no cumulative effect) (#6822).

A self-contradiction worth pointing out: a neighboring call in the same file, SetTokenInformation(..., TokenDefaultDacl, ...), is fail-closed — on failure it throws throwWin32; whereas restrictTokenIntegrity()'s own comment claims it "fails closed before any child is spawned", yet it did not stop that spawn. This contradiction looks like exactly where the defect lies.

It should be said that these two findings may be two coexisting mechanisms: a failed relabel would make the sandbox boundary differ from the docs, while a console-less host determines whether a low-integrity subprocess can start at all. One reply states explicitly that the missing SeRelabelPrivilege cannot alone explain the swap-the-host A/B — same account, same privileges, same runner, and merely swapping the host yields "success / silent failure" (#6822).

Fixes and workarounds

There are three layers of things you can do: switch in-library scripts to SW_HIDE; use the documented one-shot escalation to danger-full-access when you need interactive commands; and on desktop, use the isolation-preserving runnerCommand workaround until upstream fixes it.

Layer one: replace CREATE_NO_WINDOW with SW_HIDE. This is the correct fix for cause one and does not sacrifice the "hide the window" effect. In .NET that means ProcessStartInfo with UseShellExecute=false, CreateNoWindow=false, and WindowStyle='Hidden'. DSH's own tool path has done this since 0.1.6-alpha.2 — the reporter ran 10+ consecutive pwsh calls in a restricted-token session with no 0xC0000142 and no popup.

Layer two: use a one-shot escalation when you need real console interaction. The documented escalation path in the project is workspace-write → danger-full-access. Measured: it succeeds immediately after switching and reproduces immediately after switching back. But be clear this is an operation that turns the sandbox off, and should not be a daily solution; the docs also state that "pipe-based stdio redirection is unaffected", so most ordinary commands can stay in the default mode.

Layer three: on desktop, use the isolation-preserving runnerCommand workaround. The idea is to specify "a console-subsystem node.exe + a bwrap→ACL adapter script":

- id: sandbox
  name: "@deepseek-ai/dsh-sandbox-local"
  config:
    runnerCommand:
      - "<console-subsystem node.exe>"
      - "<bwrap-to-acl>.mjs"
    runnerFailureSignatures:
      - "windows-acl-run:"

What the adapter does: the seam appends bwrap-dialect arguments to a custom runner (--ro-bind / / --dev /dev --unshare-pid --proc /proc --die-with-parent, plus --tmpfs /tmp --bind <root> <root> under workspace-write), translates them into the ACL runner's --workspace/--temp/--mode, then rewrites process.argv in the original process and imports the official runner — copying no isolation logic, and reusing the official implementation for fd, exit-code semantics, and the windows-acl-run: failure signature. Measured (under workspace-write): commands execute normally, TEMP is rewritten to …\Local\Temp\dsh-xxxx (showing the runner really is wrapping it), writes inside the workspace succeed, and writes to C:\Users\… and ~/.dsh are both Access denied (isolation preserved). Note that runnerCommand by documentation skips the built-in runner selection and probes; it is an operator-side assertion, not an officially recommended config (#6822).

This was not introduced by 0.2.0. Comparing dsh-base's cordis.patch.yml: 0.1.5-rc.1, 0.1.7-rc.2, and 0.2.0-rc.2 all three mount pwsh-sandbox, and sandbox-policy.mode defaults to workspace-write in all of them. So this is an old limitation exposed by the new host, not a version regression.

Troubleshooting and notes

• 0xC0000142 does not mean "the command failed", it means "the process did not start". Empty output is its signature. When you see that combination, suspect the process-creation path first, not the command itself.
• Do not look only in the DSH session log. The real exit code is dropped during formatting and the log will only ever have exit code 1. Look at the Windows event log (source Application Popup, event ID 26), but it does not always record — the reliable criterion remains the exit code. When checking the event log, remember to filter by provider and read EventData, or you will wade through a pile of unrelated records.
• "Launching the desktop exe from a terminal" is not a valid control experiment. A GUI-subsystem process does not attach to the parent's console, so it still fails, yet this is easily misread as "the console hypothesis has been refuted". To isolate the variable, fix the runner, the subprocess, and argv, and swap only the host binary (node.exe vs DeepSeek Harness.exe).
• Two PowerShell traps that are easy to fall into (both measured under a restricted token): (1) Start-Process -WindowStyle Hidden also fails — PowerShell internally turns it into CreateNoWindow, and all three targets gave 0xC0000142; to hide a window, use .NET's ProcessStartInfo + UseShellExecute=false + CreateNoWindow=false + WindowStyle='Hidden'. (2) Reading a native command's output through a PowerShell pipe ($x = & native ..., ... 2>&1, -RedirectStandardOutput) likewise makes the subprocess die under a restricted token, and may leave you with neither output nor exit code — looking exactly like "the command succeeded but printed nothing". To verify a side effect, have the subprocess write a file and read the file.
• When citing the docs, cite the text, not the line number. The "console isolation unavailable" note is at :117 in sandbox-windows-acl/README.zh.md (0.1.5-rc.1 / 0.1.6-alpha.2), but moved to :129 by 0.2.0-rc.2.
• There is still residue: two taskkill cleanup paths in runner-launch-*.js still pass windowsHide: true on 0.2.0-rc.2, so under a restricted token that taskkill dies with 0xC0000142 — you can see a taskkill.exe popup event right after a tool call finishes. The code tolerates the non-zero status, so it is harmless but noisy; routing those two spots through the same SW_HIDE helper would clear the last trace.

The lesson from this kind of problem is clear: when the only failure information left is an exit code, what you need is a set of ways to manufacture evidence yourself. If you want environment-side changes (plugins, versions, config, logs) to be easier to inspect in one place, install DSH Plugin Hub — the official plugin marketplace built into the DeepSeek Harness desktop app, for browsing, installing, uninstalling, and updating plugins. Its "System logs" page lists the operational trail of installs, uninstalls, settings changes, and diagnostics in one place, and also lets you jump straight to the log file:

When troubleshooting host-level failures, looking at environment changes and system logs together saves far more trouble than retrospectively reconstructing things from empty output.

Source: Discussion #6822, Discussion #6930.