Windows 10: shell tool fails with 0xC0000142 in workspace-write mode

[LZhi1228]

Environment

• OS: Windows 10 Pro 22H2, build 19045
• DSH: desktop app 0.2.1-rc.2 (@deepseek-ai/dsh-desktop-runtime 0.2.1-rc.2), account = Administrator (elevated)
• PowerShell: 7.6.7 at C:\Program Files\PowerShell\7\pwsh.exe (also reproduced with cmd.exe)
• Session permission preset: workspace-write

Symptom

Every pwsh tool call in a workspace-write session fails with exit code 3221225794 = 0xC0000142 (STATUS_DLL_INIT_FAILED) and completely empty stdout/stderr. Switching the session to danger-full-access makes the same commands work immediately. Reboot, reinstalling PowerShell 7, and fixing PATH all change nothing.

What the spawned chain looks like (from Security 4688 with command line auditing)

DeepSeek Harness.exe  ...\dsh-subprocess-local\lib\runner.js --
  DeepSeek Harness.exe  ...\dsh-sandbox-windows-acl\lib\runner.js
    --workspace <ws> --temp %TEMP%\dsh-XXXX --mode workspace-write
    --write-sid S-1-4-... --temp-write-sid S-1-4-... --
    "C:\Program Files\PowerShell\7\pwsh.exe" -NoLogo -NoProfile -NonInteractive -Command "..."
-> exit status 0xC0000142

Isolation (same argv, same workspace/temp, same elevated console)

runner process	mode	child	result
DeepSeek Harness.exe (Electron, process.execPath)	workspace-write	pwsh 7	0xC0000142
DeepSeek Harness.exe	workspace-write	cmd.exe	0xC0000142
DeepSeek Harness.exe	read-only	pwsh 7	OK (exit 0)
bundled node.exe	workspace-write	pwsh 7	OK (exit 0)
DeepSeek Harness.exe	workspace-write, seam-managed ACEs (--write-sid given)	pwsh 7	0xC0000142
bundled node.exe	workspace-write, seam-managed ACEs	pwsh 7	OK (exit 0)

Also ruled out: workspace path (C:\dshws fails too), TMP/TEMP rewrite (patched out, still fails), ACE granting (seam-managed still fails), pwsh/.NET (cmd.exe fails identically).

Instrumenting dsh-sandbox-windows-acl/lib/runner.js shows the runner itself survives:

sandbox-inited     <- token created
before-spawn       <- about to create the child
runner-exit:-1073741502   <- mirrors the child's 0xC0000142

Suspected cause

Fails only when the runner is the Electron binary and the token carries the extra workspace-write capability SIDs (S-1-4-...); read-only (same Electron parent, no capability SIDs) works, and the bundled node with capability SIDs also works. The source comment in dsh-sandbox-windows-acl says the token design was "verified on Win11 26200" — this machine is Win10 19045. Looks like a CreateProcessAsUserW + WRITE_RESTRICTED/Low-IL interaction that differs by parent process and/or OS build on Windows 10.

Impact

workspace-write — the default confinement level — is unusable on Windows 10 for any tool that spawns a process; users must either grant danger-full-access or fall back to read-only.

Ask

Could you confirm whether Windows 10 (19045) is a supported target for the ACL sandbox, and whether using the bundled node.exe instead of process.execPath for the subprocess supervisor/runner is intended to work on Win10?

Minimal reproduction

A self-contained PowerShell script that drives dsh-sandbox-windows-acl/lib/runner.js directly with the bundled node.exe vs DeepSeek Harness.exe and prints the exit codes; I can attach it if useful.

[LZhi1228]

Follow-up: process-creation trace of the failure (Security 4688/4689, command-line auditing)

Method: enabled auditpol Process Creation + Process Termination (including ProcessCreationIncludeCmdLine_Enabled=1), switched the session to workspace-write, then issued two trivial commands. Both failed identically. Timeline below is from the Security log; paths shortened, account/SIDs redacted.

Run 1 — Write-Output "sandboxed-probe" (22:28:21.876 → 22:28:22.201)

time	event	process (PID)	parent	integrity	exit
21.876	4688	DeepSeek Harness.exe (0x41b8) — supervisor, argv = dsh-subprocess-local/lib/runner.js -- <Electron> <sandbox runner.js> …	0x1bbc (app)	High (S-1-16-12288)	—
22.007	4688	DeepSeek Harness.exe (0x1764) — sandbox runner, argv = dsh-sandbox-windows-acl/lib/runner.js --workspace <ws> --temp %TEMP%\dsh-cJkZOK --mode workspace-write --write-sid S-1-4-<redacted> --temp-write-sid S-1-4-<redacted> -- pwsh …	0x41b8	High	—
22.165	4688	pwsh.exe (0x1270)	0x1764 (sandbox runner)	Low (S-1-16-4096)	—
22.174	4688	conhost.exe (0x1a1c)	0x1270 (pwsh)	Low	—
22.177	4689	pwsh.exe (0x1270)	—	—	0xC0000142
22.183	4689	DeepSeek Harness.exe (0x1764) — sandbox runner	—	—	0xC0000142
22.201	4689	DeepSeek Harness.exe (0x41b8) — supervisor	—	—	0x0

Run 2 — Write-Output "second-probe" (22:28:23.083 → 22:28:23.404): identical chain 1.3 s later — supervisor 0x2764 → sandbox runner 0x1330 → pwsh.exe 0x858 (Low IL) + conhost.exe 0x24a4 → pwsh exit 0xC0000142 → runner exit 0xC0000142 → supervisor exit 0x0.

What the trace shows

1. CreateProcessAsUserW itself succeeds — the child exists as a real process; it dies ~12 ms later, inside loader/DLL initialization. So this is not a token-creation or privilege failure, and not a "cannot find executable" failure.
2. The child runs at Low integrity (S-1-16-4096) while both of its parents are High. The workspace-write capability SIDs are present as expected.
3. The console attaches first, then it dies: conhost.exe is created at 22.174 and pwsh exits at 22.177 — the failure is after console/CRT setup, not at process creation.
4. The capability SIDs are byte-identical across runs (S-1-4-394286496-659018422 and S-1-4-562910384-446517017-1 in both invocations), so the failure is not caused by non-deterministic or malformed capability SIDs.
5. Control sample in the same second: at 22:28:21.023 the same app spawned git.exe rev-parse --show-toplevel … without the sandbox — High integrity, exit 0. Same process, same user, same moment: unsandboxed children work, sandboxed Low-IL children don't.
6. Both attempts produced no stdout/stderr at all, consistent with the child never reaching its -Command payload; the tool surface only reports the mirrored exit code.

I can attach the redacted 4688/4689 extract (two invocations, ~14 events) and the reproduction script if that helps.

[feixiongdaoren003]

环境

Windows 10 家庭中文版，build 19045（10.0.19045），x64
DSH 桌面版 0.2.1-rc.5（Electron 44.7.0），profile 为 desktop
系统只有 Windows PowerShell 5.1，未安装 PowerShell 7
会话沙箱 workspace-write，审批策略 ask
PATH 里有 8 条 Intel 相关路径（Management Engine / WiFi / DAL / IPT）
系统 PATH 中没有 node/npm/npx/dsh
现象

workspace-write 下每一次 pwsh 工具调用都返回退出码 3221225794 = 0xC0000142（STATUS_DLL_INIT_FAILED），stdout 和 stderr 都是空的。

不是命令本身的问题：Write-Output ok 这种最小命令也一样失败，而且每次必现。

把同一个会话切到 danger-full-access 后，同样的命令立刻返回 ok、退出码 0。文件类工具（read / write / glob / grep）在两种模式下都正常。

复现步骤

启动桌面版，新建会话，沙箱设为 workspace-write
让 Agent 执行任意命令，例如 Write-Output ok
结果：[exit code: 3221225794]，无任何输出
同一会话切到 danger-full-access，重复同一条命令 → ok，退出码 0
已排除

命令本身：一条 Write-Output 就复现，与脚本内容无关
shell 缺失：powershell.exe 在 C:\Windows\System32\WindowsPowerShell\v1.0\，普通控制台里运行正常
PATH 解析：失败发生在解释器产生任何输出之前；同样的绝对路径在 full-access 下可用
关联报告

现象与 #10329、#7523、#9779、#10165 一致：同一个退出码、同样的空输出、桌面版 Electron 宿主、Windows 10。

按 #7523 的分析，probeWindowsJob() 只做静态检查、从不真正拉起 runner，所以受限子进程在 DLL 初始化阶段死掉时没有回退到普通 spawn 的路径。按 #9779 的分析，打包后的 Electron 宿主没有 console，可能是触发条件之一——但这一条我无法验证：#9779 提到的 windows-acl-run: 判别行需要 stderr 有输出，而我这里 stdout/stderr 全为空。

诉求

希望给 probeWindowsJob() 加一次真实启动探测，失败时回退到 spawnSubprocess（#7523 提出的方案）。在此之前，桌面版用户只能用 danger-full-access，这等于默认的受限级别在 Windows 10 上不可用。

[feixiongdaoren003]

补一条对照，同一台机器（Win10 19045，桌面版 0.2.1-rc.5）：

read-only：Write-Output ok → 正常输出 ok，exit 0
workspace-write：同一条命令 → exit 3221225794（0xC0000142），无任何输出
所以不是“沙箱整体不可用”，而是只有 workspace-write 追加 capability SID 之后子进程才在初始化阶段死掉，与你的隔离实验结论一致。

另外 read-only 下 stderr 会出现 ConstrainedLanguage 报错（[System.Text.UTF8Encoding]::new() 被拒），但不影响命令执行，只是非 ASCII 输出可能乱码。