[win32][sandbox] 打包桌面端（GUI 子系统宿主）下，受限令牌子进程 100% 以 0xC0000142（STATUS_DLL_INIT_FAILED）死亡

[maozhuoshushu]

English TL;DR

Symptom. On the packaged Windows desktop app (GUI-subsystem host), every shell call under the workspace-write / read-only ACL sandbox dies with exit code 3221225794 = 0xC0000142 (STATUS_DLL_INIT_FAILED) and zero output, while the same session works immediately under danger-full-access.

Root cause. The process that creates the restricted child must itself own a console. In the packaged desktop the mediator interpreter is the app image (a PE Subsystem = 2 GUI binary run with ELECTRON_RUN_AS_NODE=1), so CreateProcessAsUserW has no console to hand down and the restricted child dies during DLL initialization. Swapping only the mediator interpreter for a console-subsystem (Subsystem = 3) node.exe — same token, same runner script, same argv — returns exit 0.

Decisive evidence. Mediator = GUI-subsystem image: 4/4 crash. Mediator = console-subsystem node.exe: 2/2 exit 0. GUI-subsystem mediator plus an AllocConsole() before the spawn: 3/3 exit 0. The exit code and the zero output are the whole user-visible symptom.

Relevant source.

• @deepseek-ai/dsh-sandbox-local/lib/index.js:539-553 — windowsAclRunnerInvocation() returns [process.execPath, runner.js] (line 543; dev fallback at line 548), i.e. the mediator is whatever binary runs the app.
• @deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js:157 — the sandbox.spawn(...) that issues CreateProcessAsUserW (main() at line 113).
• @deepseek-ai/dsh-sandbox-windows-acl/lib/types/index.d.ts:26-31 — the package documents this boundary itself: "console isolation is unavailable — children share the host console (CREATE_NO_WINDOW / CREATE_NEW_CONSOLE children die with STATUS_DLL_INIT_FAILED under the restriction)".

Two measured fixes (either one works).

1. In runner.js, call AllocConsole() (window hidden via STARTF_USESHOWWINDOW) in main() before sandbox.spawn, so the mediator owns a console it can pass down.
2. In dsh-sandbox-local/lib/index.js:543, resolve a console-subsystem interpreter instead of process.execPath.

Independent second cause of the same exit code. discussion #8497 reports the same 0xC0000142 from AclSandbox.init() setting the restricted token's Default DACL to a capability SID (this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid) instead of worldSid. The two are not mutually exclusive, so both need checking — fixing only one still leaves some users broken.

Cross-check on the second cause (Windows 11 26200). The capability-SID ACE is appended to the ambient Default DACL by SetEntriesInAclW, not substituted for it, and a workspace-write restricted child on this reporter's 26200 machine starts cmd.exe and returns 0x00000000 (restriction verified enforced: workspace write allowed, C:\Windows\Temp write denied with EPERM, system reads allowed). So the capability-SID substitution is not by itself sufficient on current builds; what differs on the failing Windows 10 19045 machine is still open, and the decisive datum is the Default DACL of a restricted child on that machine.

---

一、摘要

在 Windows 上，只要「创建受限令牌子进程」的那一层是 GUI 子系统镜像（打包桌面端正是这种情形：应用主程序以 ELECTRON_RUN_AS_NODE=1 充当 node 解释器），ACL 沙箱在 workspace-write 下运行的 shell 工具就会 100% 以 exit code 3221225794（0xC0000142 = STATUS_DLL_INIT_FAILED）失败，且 stdout / stderr 全空（连 Get-Date 都没有输出）。

把同一份代码路径的解释器换成 console 子系统的 node.exe —— 同样的令牌、同样的 runner 脚本、同样的命令 —— 立刻 exit 0。由此可排除：

• 受限令牌本身不是原因：同样的令牌在 console 子系统宿主里完全正常；
• pwshPath 与 PowerShell 版本不是原因：pwsh.exe 就是 7.6.6，而且该故障在 danger-full-access 下不出现；
• 唯一决定性变量 = 创建受限子进程的那一层自己有没有控制台。

准确机制：dsh-sandbox-windows-acl 用 CreateRestrictedToken（flags = 13 = DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED）加 Low 完整性标签创建受限令牌子进程。控制台子系统的早期初始化发生在被创建进程内部、DLL 初始化期，此时该进程必须能自持或继承一个控制台。GUI 子系统镜像不会被 Windows 自动分配控制台，也不会继承父进程的控制台；而 dsh-subprocess-local 创建 runner 时带 windowsHide: true（等价于 CREATE_NO_WINDOW）。于是处于末端的受限子进程既无处继承、又只能自行申请控制台，就在 DLL 初始化期死亡。

二、环境（脱敏）

• 操作系统：Windows 11 专业版，build 26200（x64）
• 宿主：打包桌面端（asar 内 12,967 个文件项），Electron 44.0.0；宿主本体 Subsystem=2（GUI）
• 沙箱包：@deepseek-ai/dsh-sandbox-local / @deepseek-ai/dsh-sandbox-windows-acl / @deepseek-ai/dsh-win32-process / @deepseek-ai/dsh-subprocess-local 均为 0.2.0-rc.2
• 目标 shell：PowerShell 7.6.6（%ProgramFiles%\PowerShell\7\pwsh.exe，Subsystem=3）
• 对照运行时：随 DSH 分发的 node.exe（Subsystem=3）

三、用户可见症状

1. 沙箱策略为 workspace-write（或 read-only）时，shell 工具每一次调用都返回 exit code 3221225794，无任何输出；
2. 同一会话把策略切到 danger-full-access，shell 工具立即正常（返回 7.6.6 与 %ProgramFiles%\PowerShell\7\pwsh.exe）；
3. 与 pwshPath 配置、用户 PATH 均无关 —— 解析链本来就已选中 PS7（%ProgramFiles%\PowerShell\7\pwsh.exe 存在，stat.isFile() 成立）；
4. 只有打包桌面端（GUI 子系统宿主）会出现；同一台机器上 CLI / 普通 node 宿主不受影响。

四、最小重现

真链的 argv 契约（方括号内为占位符）：

[interpreter] [sandbox-windows-acl/lib/runner.js] \
  --workspace [workspace] --temp [private-temp] --mode workspace-write \
  [--write-sid [S-1-4-...] --temp-write-sid [S-1-4-...]] \
  -- [target argv...]

1. 对照组（正常）：解释器 = console 子系统的 node.exe

node.exe runner.js --workspace [workspace] --temp [temp] --mode workspace-write -- pwsh.exe -NoProfile -Command 1

→ exit 0，受限 pwsh 正常输出（自报完整性 Low / rid=4096）。

2. 复现组（失败）：解释器 = GUI 子系统镜像 + 环境变量 ELECTRON_RUN_AS_NODE=1

"[install]\DeepSeek Harness.exe" runner.js --workspace [workspace] --temp [temp] --mode workspace-write -- pwsh.exe -NoProfile -Command 1

→ 0xC0000142，stdout / stderr 全空。

两者除解释器镜像外完全相同：同一份 runner.js、同一份令牌构造代码、同一个目标命令。

五、决定性证据

最小 C# 驱动（CreateRestrictedToken(..., 0x13, ...) + Low 完整性 + CreateProcessAsUserW），同一份源码分别以 /target:winexe（GUI 子系统，PE=2）与 /target:exe（console 子系统，PE=3）编译，2x2 矩阵（父有控制台 / 父无控制台，每格两次）：

• winexe（PE=2，等同打包桌面端性质）：父有控制台 → 0xC0000142 零输出（2/2）；父无控制台 → 0xC0000142 零输出（2/2）
• exe（PE=3）：父有控制台 → exit 0 + stdout 7（2/2）；父无控制台 → exit 0 + stdout 7（2/2）

因果隔离（决定性）：在同一个 winexe 镜像里，让驱动在创建受限子进程之前自己调用一次 AllocConsole()，同样代码、同样令牌，得到 4/4 exit 0 + stdout 7。所以 GUI 镜像本身不是原因，「创建者有没有自己的控制台」才是。

真链上的同一结论（只换中介解释器，其余全同）：

• 中介解释器 node.exe（console 子系统）→ 2/2 exit 0，并生成探针文件
• 中介解释器应用主程序（ELECTRON_RUN_AS_NODE=1，GUI 子系统）→ 4/4 0xC0000142，零输出

补充：在 GUI 中介进程内显式 AllocConsole() 后，该中介确实继承到控制台（GetConsoleProcessList 返回 2 且含自身），但受限子进程仍然 0xC0000142（2/2）。所以「给宿主 / 中介一个控制台」不是充分修法；充分条件是创建受限子进程的那个进程在本进程内自持控制台。

两条容易误判的边界（供维护者避坑）：

• AttachConsole(ATTACH_PARENT_PROCESS) 的返回值与 GetLastError 不能用来判断「有没有控制台」：确无控制台的格也会返回 err=5（ERROR_ACCESS_DENIED）。可靠判据是 GetConsoleProcessList 的条数与成员。
• 从带 Mandatory Label\Low Mandatory Level:(I)(NW) 的目录（例如用户工作区）启动的中介进程会被降为 Low，此时 AttachConsole 会被真实拒绝。所以走 attach 路线的实现不能从带强制 Low 标签的目录启动。

六、建议补丁（两个方向均已实测有效）

补丁一（推荐：最小、无 API 变更）—— @deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js：在 main() 创建受限子进程之前调用 AllocConsole()，随即用 ShowWindow 与 STARTF_USESHOWWINDOW 隐藏新控制台窗口（避免闪黑窗）。runner 进程本身不受限，AllocConsole() 必然成功；之后受限子进程以继承方式拿到该控制台。实测：同一格由 0xC0000142 变为 exit 0（3/3）。

补丁二（等价方向，保留 runner 一跳不动）—— @deepseek-ai/dsh-sandbox-local 的 windowsAclRunnerInvocation()（lib/index.js:539-553 附近，返回值是 [process.execPath, sandbox-windows-acl/runner.js]）：不要把 process.execPath 当解释器，在 Electron 宿主下它是 GUI 子系统镜像。改用 console 子系统的解释器（随 DSH 分发的 node.exe，或一个 console 子系统的 stub 再 exec 原 runner）。实测：2/2 与 4/4 exit 0。

不要做的事（会主动制造死亡条件）：给受限子进程或其父加 CREATE_NO_WINDOW 或 CREATE_NEW_CONSOLE，或者为 shell 接 ConPTY。这与包内 README 已有的 “Console isolation is unavailable” 记录一致；缺的那一环是中介自身必须持有控制台。附注：@deepseek-ai/dsh-win32-process 已经正确地不对子进程加这两个标志。

七、旁证：同一缺陷已被第三方独立复现

Astral-Dream/dsh-windows-sandbox-0xC0000142-workaround（2026-10-02 创建，MIT）针对 DSH 0.2.0-rc.2 Windows workspace-write，报告完全相同的症状（exit code 3221225794，沙箱内 shell 完全不可用；切到 danger-full-access 后正常），并把根因定位到「托管沙箱程序的那个运行时」：普通 node.exe → exit 0，应用主程序（Electron-as-node）→ 0xC0000142，其余条件相同。它的修法是检测 process.versions.electron 后用自带普通 node 从磁盘副本重执行沙箱启动程序（沙箱核心 JS 零改动）。

本报告的增量：把 Electron-as-node 这个黑盒变量下钻到控制台 / 子系统机制，给出「创建者自持控制台」这一充分条件，并给出两个改产品源码的最小补丁点（第六节补丁一 / 补丁二）。

相关（同类但不同 bug）：

• masknull/dsh-acl-sandbox-patch：DSH 0.1.7，非系统盘工作区下 grantWrite / SetNamedSecurityInfoW 返回 Win32 5；
• anne43983959/dsh-sandbox-legacy-acl：把 Windows ACL 授权保持在 0.1.5 形态（去掉 Low 完整性标签等）；
• sjh9714/dsh-win32 issue #91：Windows CI 中步骤 shell 反复 0xC0000142，根因未定（该 issue 也提示「不要仅凭退出码断言」）。

其它项目里的同族证据（说明这是进程创建 / 控制台初始化类的共性坑）：openai/codex 的 Windows 沙箱相关 issue（session 0 与 session 1、USER32、Winsta0\Default）、microsoft/terminal 中默认终端接管时并发控制台应用 0xc0000142。

八、结论与诉求

1. 请在 dsh-sandbox-windows-acl / dsh-sandbox-local 的 win32 路径上引入「中介必须自持控制台」这一不变量（第六节补丁一或补丁二，任选其一即可修复）；
2. 建议在 win32 沙箱文档中显式记录该约束（GUI 子系统宿主 + windowsHide 会导致受限子进程无控制台可继承，进而 0xC0000142），并补一条「宿主为 GUI 子系统镜像」的自检告警，避免用户只能靠切 danger-full-access 绕过。

九、未证实 / 已知不确定项（如实标注）

• 未取得 0xC0000142 的 loader / Procmon 级证据（无 dump、无 App Hang 事件）；
• 未直接抓取真宿主内受限子进程的 dwCreationFlags（仅由矩阵与源码路径推断）；
• 全部实验均在单机 Windows 11 build 26200 上完成，未跨机器 / 跨版本复验；
• 「从终端启动桌面端即可修复」这一早期猜测已被否证（父进程有控制台也不能救，见第五节）。

[sshnuke3]

?????? OS????????????,??????????

??

• ????:Windows Server 2022,build 20348(x64) -- ?? Win11,???????? SKU ??
• ??:????? 0.2.0-rc.2(???? DeepSeek Harness.exe,Subsystem=2 GUI,? ELECTRON_RUN_AS_NODE=1 ?? node ???)
• ?? shell:PowerShell 7.6.6(%ProgramFiles%\PowerShell\7\pwsh.exe,? candidatePwshPaths() ????)? Windows PowerShell 5.1(System32 ??)--?????
• ???? workspace-write / read-only ??? shell ??:stdout/stderr ?? + [exit code 3221225794](0xC0000142);????? danger-full-access ????

????

1. ?"?????????"??? ?????(??? cmd.exe,RunLevel=Limited,???)??????? CLI(...\resources\runtime\cli\bin\dsh.cmd,???? GUI ???? Electron ??),?? 100% ?????????????"???????????????? Subsystem=2",????????????? Electron ?????????
2. ?? provisioning ??,??? shell ?????? ????????????(%TEMP%\dsh-XXXXXX)??????? dsh-sandbox-windows-acl ?????????:
   S-1-4-<...>:(OI)(CI)(W,D,DC)(?? SID ???)+ Everyone:(CI)(DENY)(S,DC) + Mandatory Label\Low Mandatory Level:(OI)(CI)(NW);
   runner ????????(?????????????),?????????? DLL ???;? shell(5.1 ? 7.6.6)???
   ??? [Bug][Windows 10] workspace-write 沙箱下所有子进程 0xC0000142（连 cmd.exe 都起不来）— Default DACL 使用 capability SID 所致 #8497(????? Default DACL ?? capability SID)??,????????????????
3. A/B ??(???????????):a5f2199f-.(workspace-write)? (no output) [exit code 3221225794];746abdd6-.(danger-full-access)? SANDBOX_SHELL_CHECK?
   ???:%TEMP%\dsh-qXXH2y(???????????,??? SID ACE + Low ??,????)?%TEMP%\dsh-acl-locks?

??

?????,?????? console ???? node.exe ????;???????? GUI ?????,????????????? DSH_PERMISSION_MODE=danger-full-access ??(??????????????)?

[maozhuoshushu]

Thanks @sshnuke3 — the Windows Server 2022 / build 20348 datapoint and the ACE string are genuinely useful, and they extend this beyond Windows 11.

Two clarifications, because your "cannot reproduce" is actually consistent with this report.

1. The layer that must own a console is the mediator, not the target.

The cmd.exe in your control was the target (RunLevel=Limited, no window) — its starting fine does not contradict anything. In the real chain the mediator is whatever windowsAclRunnerInvocation() picks as process.execPath, and in the packaged desktop that is the GUI-subsystem image:

• @deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js:157 → sandbox.spawn(...), the CreateProcessAsUserW call that creates the restricted child (async main() at line 113)
• @deepseek-ai/dsh-sandbox-local/lib/index.js:539-553 → windowsAclRunnerInvocation(), returning [process.execPath, runner.js] (lines 543 and 548)

The path where you see 100% success — …\resources\runtime\cli\bin\dsh.cmd — is exactly the console-subsystem interpreter, i.e. the control group of the matrix. Your CLI result and this failure are the two cells of the same experiment, not a contradiction.

2. There is a second, independent root cause on this same exit code: #8497 — AclSandbox.init() sets the restricted token's Default DACL to a capability SID (this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid) instead of worldSid. Both can be present at once, which is why "it works for me via CLI" and "it always fails in the packaged desktop" can both be true.

Proposed 2×2 to separate them — if you can run this on your box (Server 2022 / 20348) it would settle both threads:

	Default DACL = capability SID	Default DACL = worldSid
mediator = GUI-subsystem image (ELECTRON_RUN_AS_NODE=1)	?	?
mediator = console-subsystem node.exe	?	?

If the GUI row still fails under worldSid, that isolates the console-ownership mechanism; if the console row fails under the capability SID, that isolates #8497. The scriptable harness is the one already posted in #8497 ($env:ELECTRON_RUN_AS_NODE='1' + Start-Process the app image with the runner argv), swapping only the interpreter.

Note that your suggested workaround — run via a plain node.exe — is exactly fix option 2 in this report, so we already agree on the direction. Fix option 1 is a one-liner in the same runner.js: call AllocConsole() (hidden via STARTF_USESHOWWINDOW) in main() before sandbox.spawn, so the mediator holds a console it can pass down. Both were measured working here.

Related threads: #8497 (independent root cause, same exit code) · Astral-Dream/dsh-windows-sandbox-0xC0000142-workaround#1 (independent reproduction + workaround) · sjh9714/dsh-win32#91 (CI-side occurrence of this exit code).

中文摘要：他复测时"沙箱里 cmd.exe 能起来"不构成反证——cmd.exe 是目标，必须自持控制台的是中介；中介由 dsh-sandbox-local/lib/index.js:539-553 的 windowsAclRunnerInvocation() 决定，打包桌面端下它就是 GUI 子系统镜像，而他说 100% 正常的 CLI 路径正好是 console 子系统解释器，即本报告矩阵里的对照组。另请把 #8497（Default DACL 用 capability SID）当作一条独立根因，建议用上表的 2×2 把两者分开。

[maozhuoshushu]

Follow-up with new measured data on this thread, directly relevant to the exit code under discussion.

1. The initial post now carries an English executive summary at the top (symptom / root cause / decisive evidence / the two measured fixes), so the mechanism is readable without the Chinese body.

2. I ran #8497's A/B on Windows 11 26200 — and could not reproduce it.
Registry Windows 10 Pro, DisplayVersion 25H2, CurrentBuild 26200, UBR 8524, elevated administrator token, @deepseek-ai/dsh-sandbox-windows-acl 0.1.7-alpha.2, instantiating the shipped AclSandbox and changing only the mode:

Trial	cmd.exe (pipe)	cmd.exe (inherit)
read-only (Everyone)	0x00000000	0x00000000
workspace-write (capability SID), temp=null	0x00000000	0x00000000
workspace-write (capability SID), temp=yes	0x00000000	0x00000000

The restriction was genuinely enforced (workspace write allowed; C:\Windows\Temp write denied with EPERM; system reads allowed), so this is not a no-op sandbox.

3. Why the capability-SID substitution is not the whole story: setTokenDefaultDaclGrant() merges via SetEntriesInAclW (types-DxezulnA.js:806). The restricted child's Default DACL on 26200 has 4 ACEs in every mode — the new 0x001F01FF ACE for the capability SID (S-1-4-801027725-1051640001), plus the ambient S-1-5-18 (SYSTEM), S-1-5-32-544 (Administrators) and logon SID still present. Both SYSTEM and Administrators are groups the restricted token still holds and are absent from the restricting list, so the default-DACL check passes here.

4. Correction to my own earlier reply on this thread. I described #8497 as "an independent root cause of this same exit code". After the 26200 run I would phrase it more carefully: it is an independent reported root cause on Windows 10 19045 that does not reproduce on 26200, so it is platform-specific rather than universal. The two remain non-exclusive in practice — a machine whose ambient Default DACL lacks SYSTEM/Administrators, or a host process that owns no console, will still fail for its own reason.

5. Therefore: both fixes are still warranted, because they close different failure modes — (a) AllocConsole() in runner.js (or a console-subsystem mediator interpreter) for the GUI-subsystem host, and (b) adding Everyone to the default DACL for machines whose ambient Default DACL carries no usable trustee. Fixing only one of them leaves the other class of machine broken.

Measured 2×2, for anyone who wants the table filled in — on 26200, both rows of the Default DACL = capability SID column already succeed, which is the point: the GUI-subsystem host row was the one that failed here, and it fails for the console-ownership reason rather than the DACL one.

Probe sources and the full readout are in this thread's repository-adjacent notes; happy to re-run any cell with different parameters if the team wants a specific configuration characterized.

[maozhuoshushu]

New measured data that fills in all four cells of the 2×2 and refines the root-cause statement in the initial post. All runs are on Windows 11 26200 (registry CurrentBuild 26200, UBR 8524, elevated administrator), using the shipped @deepseek-ai/dsh-sandbox-windows-acl 0.1.7-alpha.2, changing only one variable per run.

The matrix (target always cmd.exe /c echo SANDBOX_SHELL_CHECK)

Mediator interpreter	read-only	workspace-write (capability SID)	workspace-write + temp SID
GUI-subsystem image (DeepSeek Harness.exe + ELECTRON_RUN_AS_NODE=1)	✅ 0x00000000 SANDBOX_SHELL_CHECK	❌ 0xC0000142, no output	❌ 0xC0000142, no output
console-subsystem node.exe	✅	✅	✅

So the failure needs both conditions at once — a mediator with no console and workspace-write. It is not "every sandbox mode under a GUI host", and that matters for the fix's scope and for anyone reproducing this: a plain node.exe mediator never shows it.

Where exactly it dies

spawn() returns normally every time (spawn() returned pid=20700, then the wait failed) — the child is created and dies during DLL initialization, so this is STATUS_DLL_INIT_FAILED inside the child, not a failure of the spawn call.

Variation (GUI mediator, workspace-write unless noted)	Result
baseline workspace-write	❌ 0xC0000142
AllocConsole() in the mediator before spawn	✅ 0x00000000
read-only baseline	✅
read-only + FreeConsole()	✅ still succeeds
workspace-write with tempWriteSid set to the workspace SID	❌ still fails
workspace-write with stdio: 'inherit'	❌ still fails

Two of those are worth stating plainly:

• Giving the mediator a console fixes it (AllocConsole() before the spawn, 1/1 here and consistent with the earlier 3/3).
• Discarding the mediator's console does not break read-only — so "a console is required" is too simple. The real shape is that the workspace-write token/DACL path is unsafe when the mediator has no console; read-only's path is safe either way.

The tempWriteSid and stdio variants rule out the specific SID value and the stdio mode as the trigger.

Consequence for the proposed fix

Both fixes in the initial post remain correct, but the scope should be stated as workspace-write rather than all modes: (1) AllocConsole() (hidden via STARTF_USESHOWWINDOW) in runner.js main() before sandbox.spawn, or (2) resolve a console-subsystem interpreter at dsh-sandbox-local/lib/index.js:543 instead of process.execPath.

Relation to the Default DACL thread

This also separates cleanly from #8497. In this run the read-only ACE[0] is Everyone and the workspace-write ACE[0] is the capability SID — yet read-only succeeds and workspace-write fails with the same console state. So on 26200 the capability SID is not the trigger; the workspace-write token path under a console-less mediator is. #8497's machinery is still relevant on machines whose ambient Default DACL lacks a usable trustee, but it is a different mechanism from this one.

Probe sources for anyone who wants to re-run: probe-dacl-mediate.mjs (mediator-agnostic), probe-dacl-stepwise.mjs (the variations above), plus the token dumper posted earlier.