Bug: every command under workspace-write dies with 0xC0000142 (STATUS_DLL_INIT_FAILED) on Windows desktop

[reese1126]

• Component: @deepseek-ai/dsh-sandbox-windows-acl (via @deepseek-ai/dsh-pwsh-sandbox / dsh-bash-sandbox through dsh-sandbox-local)
• Platform: Windows desktop app, win32 x64
• Product version: 44.0.0
• Severity: high — the sandboxed modes are unusable; users must fall back to danger-full-access, which bypasses the file sandbox entirely
• Related: discussion #8130

---

1. Summary

Under the workspace-write file policy, every command-tool call (pwsh, bash, and any native target) fails with:

(no output)
[exit code: 3221225794]

3221225794 = 0xC0000142 = STATUS_DLL_INIT_FAILED.

The same command in the same session under danger-full-access works immediately. read-only also works. So the failure is confined to the workspace-write confinement path and is independent of the command being run.

---

2. Root cause

AclSandbox.init() names a capability SID (the per-workspace / per-session write SID) as the trustee of the restricted token's default DACL.

read-only never does this — it falls through to worldSid (Everyone). workspace-write is the only mode that takes the capability-SID branch.

// packages/sandbox/sandbox-windows-acl/src/... (deployed: lib/types-<hash>.js)
setTokenDefaultDaclGrant(api, restrictedToken, lowLabelSid);   // sets Low IL
this.token = restrictedToken;
setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);
//                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
//                                             failing trustee under workspace-write

The confined child is then created with a console subsystem. Something on the console / loader-initialization path cannot use an object whose default DACL names a capability SID that no other process holds, so the child dies during DLL initialization with 0xC0000142 before any user code runs — which is why there is no output at all and no runner diagnostic.

This is consistent with the limitation already documented in sandbox-windows-acl/README.md:

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.

and with S-1-2-1 (console logon) being deliberately absent from the restricting list.

Subsystem dependence (key evidence)

Probe executable subsystem	read-only	workspace-write
ConsoleApplication	works	0xC0000142
WindowsApplication	works	works

The failing path is console-specific, not process-creation-specific.

---

3. Reproduction

Via the product (end user):

1. Start the Windows desktop app with the default permission (workspace-write).
2. Run any command through the shell tool, e.g. echo hello.
3. Observe (no output) + exit code 3221225794.

Minimal, isolated reproduction (no DSH UI needed):

Load the deployed AclSandbox and spawn a console target under a seam-managed workspace-write token:

import { AclSandbox, workspaceWriteSid, tempWriteSid } from '@deepseek-ai/dsh-sandbox-windows-acl';

const WS = 'I:\\DS工作区';
const tmp = fs.mkdtempSync(path.join(os.tmpdir(), 'dsh-'));

const sb = new AclSandbox({
  writableDirs: [WS],
  tempDir: tmp,
  mode: 'workspace-write',
  writeSid: workspaceWriteSid(WS),
  tempWriteSid: tempWriteSid(tmp),
  manageDacls: false,        // caller owns the ACEs, exactly like the seam
});
await sb.init();
const ch = sb.spawn({ command: 'C:\\Windows\\System32\\cmd.exe', args: ['/c', 'exit 7'], stdio: 'pipe' });
console.log((await ch.wait()).exitCode);   // 3221225794  (expected 7)

The identical snippet with mode: 'read-only' returns 7.

---

4. Control experiments (single-variable)

Bisection performed by loading the delegated chunks through an ESM load hook and changing exactly one thing per run. Argv built the same way as windowsAclRunnerArgv:
--workspace <ws> --temp %TEMP% --mode workspace-write -- cmd /c echo A.

Variant (all workspace-write)	Result
unpatched	no output, -1073741502 (0xC0000142)
ELECTRON_RUN_AS_NODE removed from the runner env	still -1073741502
runner's TMP/TEMP rewrite to the private temp dir disabled	still -1073741502
capability SIDs removed from the restricting list	still -1073741502
default-DACL trustee forced to worldSid	works — prints A, exit 0

Additional independent checks on the same machine:

• Electron-as-Node (DeepSeek Harness.exe + ELECTRON_RUN_AS_NODE=1) started as an ordinary child is viable (-e, --version, plain scripts all return 0). So the problem is not "Electron cannot start" — it is loader initialization under the restricted token.
• CREATE_NO_WINDOW (Node's windowsHide: true) is not the cause: toggling it changes nothing (both variants 0xC0000142).
• AclWriteGrant.add() (the ACL mutation itself) completes fine even under the Electron Node runtime — so the failure is specifically in restricted-token process creation, not in the ACL machinery.
• The ELECTRON_RUN_AS_NODE environment variable does leak into the confined child (the subprocess env scrubber forwards it: it is neither credential-shaped nor DSH_-prefixed). This looks causal but is not: removing it does not change the outcome, and read-only works with the same leak in place.

---

5. Suggested fix

One line, which makes workspace-write behave exactly like the already-working read-only path at this site:

setTokenDefaultDaclGrant(api, restrictedToken, worldSid);

The capability SIDs remain where they carry confinement authority:

• the restricting SID list still names workspace + temp capability SIDs;
• the standing workspace grant and revocable temp grant are untouched;
• the Low integrity label and the grantWrite mandatory labels are untouched;
• the TMP/TEMP rewrite to the private temp directory is untouched.

Only the default DACL of objects created by the confined child changes — which is precisely what read-only has always done.

A more conservative variant, if the capability trustee was intentional for some scenario, is to keep the capability trustee only for non-console targets and use worldSid for console-subsystem targets.

Optional hardening for the leaked selector

The subprocess env scrubber could additionally treat ELECTRON_RUN_AS_NODE as internal plumbing (like the DSH_* prefix), so no confined child inherits it. This is not required for this bug but closes a surprising leak.

---

6. Verification that confinement is preserved

After applying the one-line change, measured inside a confined workspace-write child:

Check	Result
Confined child exit code	0 (was 0xC0000142)
Write inside the workspace	WROTE
Write outside the workspace	DENIED (still confined)
Confined token integrity level	Low Mandatory Level (S-1-16-4096)

cmd, powershell and pwsh all start again under workspace-write, and whoami /all still reports the Low mandatory level.

---

7. Impact

• Affected: Windows desktop, workspace-write (and any confined mode deriving from it).
• Consequence: command tools are completely unusable in the confined mode, and do not self-heal within a session. Users are pushed to danger-full-access, i.e. the file sandbox is bypassed — a security-relevant outcome, not merely an inconvenience.
• Trigger breadth: any desktop install that starts the runtime in Node mode (the default shape) satisfies the precondition.

---

8. Second, likely separate issue (not fixed by the above)

Inside a confined workspace-write shell, schannel/.NET HTTPS clients cannot complete a TLS handshake:

• curl https://example.com → curl: (35) schannel: AcquireCredentialsHandle failed: SEC_E_NO_CREDENTIALS (0x8009030e)
• Invoke-WebRequest https://api.github.com/ → "the connection was closed while receiving"

Both work in an unconfined shell on the same host with the same local proxy. This is not fixed by the default-DACL change and is probably a separate consequence of the restricted token (CNG / \Device\CNG is mentioned in the package README as a write trustee that pwsh needs).

---

9. Environment where reproduced

Item	Value
OS	Windows 11, build 26100
Product	DeepSeek Harness desktop 44.0.0
Install layout	…\Programs\DeepSeek Harness\resources\app.asar (payload under app.asar/dsh/node_modules)
Runtime	DeepSeek Harness.exe (Electron 44 / Node 24) started with ELECTRON_RUN_AS_NODE=1
UAC	EnableLUA=0; host runs at High integrity as a full administrator token
Workspace	I:\DS工作区 (NTFS, non-ASCII path; also reproduced on C:)
Deployed chunks	dsh-sandbox-windows-acl/lib/types-Cl_DXjhk.js, dsh-win32-process/lib/index.js, dsh-subprocess-local/lib/runner-launch-B2zsQ1Dz.js

Note on build layout: in 44.0.0 the sandbox payload lives at app.asar/dsh/node_modules/…, and the sandbox chunk file name is types-Cl_DXjhk.js. Any third-party patcher must therefore be content-addressed, not keyed on a fixed chunk file name — several community plugins hard-code other names (e.g. types-CNjZgO4h.js) and silently skip on this build. Likewise, this build already ships dwFlags: 257 + wShowWindow: 0 at both encodeStartupInfo call sites, so the "console window flash" patch is not needed on 44.0.0 (dwFlags: 256 does not occur at all).

---

10. Minimal-diff patch used to confirm the fix locally

Length-neutral, so archive offsets and every other entry's integrity.hash are unaffected; only the patched entry's own integrity.hash record is re-synced.

- setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);
+ setTokenDefaultDaclGrant(api, restrictedToken, worldSid/*........................................*/);

Both sides are 52 bytes, so nothing downstream moves. After the patch the archive still parses (12 967 entries) and 0 entries mismatch their recorded hashes.

---

11. Credit

The root cause and the one-line fix were identified by a commenter on discussion #8130. This report consolidates that analysis with independent on-machine verification (controls, confinement re-verification, and the build-layout findings in §9).

[PerryLink]

0xC0000142 在这个包里有两个已记录成因——请先分清你撞的是哪一个

1. 文档里的两处（packages/sandbox/sandbox-windows-acl/README.md）

• :102：workspace-write 与 read-only 都会 spawn 一个 Low 完整性令牌；keep-alive 组（logon SID + Everyone）在两种模式下都必须存在——

  without it, early DLL initialization dies with 0xC0000142 and CNG crashes pwsh with 0xE0434352.

• :127：Console isolation is unavailable —— 用 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程会在 DLL 初始化期死掉，错误是 STATUS_DLL_INIT_FAILED（0xC0000142）；因此子进程共享宿主控制台，而基于管道的 stdio 重定向不受影响。

⇒ 同一个错误码，两个触发条件。你在标题里写了 (STA…)，那更像是控制台/STA 相关的那一条（:127），但请用下面的判据分开。

2. 分开它们的判据

若……	则成因是
只有带 CREATE_NO_WINDOW/CREATE_NEW_CONSOLE 的命令失败，普通命令正常	:127 控制台隔离
所有命令都失败（含最简命令）	倾向 :102 keep-alive 组缺失
失败发生在 DLL 初始化期（进程刚起就死）	两者都可能，看进程创建标志

3. 请与 #8534 合并（同一现象、更早的报告）

同在 Q&A 区另有一条：#8534「workspace-write cannot start any child (0xC0000142); read-only works」——同一个错误码、同一个模式对照。我在那边给过同样的建议：列出失败子进程的启动标志，并对照 read-only 的令牌默认 DACL。

⇒ 建议两贴互引并合并为一条（你这条若补充了 STA 这一面，正好是 #8534 缺的那一半）。

4. 请补三样

1. 失败命令的最小例子与它的启动标志（是否带 CREATE_NO_WINDOW/CREATE_NEW_CONSOLE）；
2. read-only 下同一命令是否成功（这是 #8534 已给出的对照，你复现一遍就能确认同源）；
3. 版本：请写版本（当前最新 0.2.1-alpha.1）。

一条边界

我确认的是文档对 0xC0000142 的两处成因描述（足以说明"必须先分开"）。你撞的是哪一条以第 2 节的对照为准——我没有 Windows 受限令牌环境。