【Windows 缺陷】Electron 桌面宿主无控制台，ACL 沙箱受限子进程全部以 0xC0000142 崩溃（cmd/pwsh 均然）；CLI web 正常

[youkangduan2008-sys]

邮件标题：
【Windows 缺陷】Electron 桌面宿主无控制台，ACL 沙箱受限子进程全部以 0xC0000142 崩溃（cmd/pwsh 均然）；CLI web 正常

Issue title (English):
Windows: Electron desktop host has no console, so every ACL-sandboxed child dies with 0xC0000142 (STATUS_DLL_INIT_FAILED); dsh web from a console works

一、概述（Summary）

在 Windows 桌面版（Electron）DSH 中，只要访问模式为 Workspace Write（工作区内修改，默认沙箱模式），agent 执行的任何子进程命令——包括最简单的 cmd /c echo 和 node -v——都会在进程加载阶段直接崩溃，退出码 3221225794（0xC0000142 / STATUS_DLL_INIT_FAILED），零输出；PowerShell 7 是否安装与此无关。

我们用贵方自带的沙箱源码做了对照实验，确认根因是：ACL 沙箱用受限令牌（WRITE_RESTRICTED）+ CreateProcessAsUserW 创建的子进程必须继承宿主控制台，而 Electron GUI 宿主进程树中不存在任何控制台（无 conhost），子进程在 DLL 初始化阶段死亡。同版本的 CLI web（dsh web）从真实/隐藏控制台启动时一切正常，danger-full-access（完全权限）模式也正常（因为它绕过了受限令牌）。

这不是某台机器的个例，而是桌面宿主与 Windows 沙箱实现之间的结构性兼容缺陷。下文给出源码依据、可 100% 复现/消除故障的最小实验矩阵，以及修复建议。

二、环境（Environment）

• 操作系统：Windows 10 企业版 64 位，Build 19042.928（20H2），系统语言 zh-CN
• DSH：0.2.0-rc.2（桌面 Electron 版与 npm CLI 为同一版本、同一套代码；npm 包 @deepseek-ai/dsh@0.2.0-rc.2）
• 运行时：Node v22.23.2；PowerShell 7.6.6（C:\Program Files\PowerShell\7\pwsh.exe，已加入 PATH）
• 访问模式：Workspace Write（沙箱开启）；模型通道正常，文件读写/搜索等不经子进程的功能正常
• 安全软件：360 安全卫士全程运行，对照实验证明其与本故障无关（同一台机器、同一时刻，仅改变控制台拓扑即可复现/消除故障，未对 360 做任何改动）
• npx dsh-win32 doctor：8 pass / 0 fail（原因见第六节，它在真实控制台中运行，测不到 Electron 的无控制台拓扑）

三、故障现象（Symptoms）

1. Electron 桌面版中执行任意命令，返回形如：(no output) [exit code: 3221225794]
2. 3221225794 = 0xC0000142 = STATUS_DLL_INIT_FAILED：进程已被创建，但在用户代码执行前的 DLL 初始化阶段死亡；
3. 不仅 pwsh，连 C:\Windows\System32\cmd.exe /c echo 也同样崩溃，说明与 shell 本身无关；
4. 首次抓到的 stderr 为 Crashpad 上报失败：TransactNamedPipe: 有更多数据可用。(0xEA)——受限进程连命名管道都无法打开，崩溃上报链路本身也走不通；
5. 改为“完全权限（danger-full-access）”后命令可执行（但这等于关闭沙箱，不应作为常态方案）；
6. 从命令行启动 dsh web（CLI web）后，在网页端 Workspace Write 模式下同样的命令全部退出码 0。

四、根因分析（Root cause，含贵方源码原文）

4.1 沙箱的进程创建方式

Workspace Write 模式下，真实命令不是直接执行，而是加一层 runner 前缀：

node ...@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js --workspace

--temp --mode workspace-write -- <真实命令>

runner 通过 CreateRestrictedToken（含 WRITE_RESTRICTED 等限制，实测 flags=13）生成受限令牌，再以 CreateProcessAsUserW 启动真实命令，子进程继承宿主的 stdio/控制台。danger-full-access 模式则直接 super.execute()，完全不创建受限令牌。

4.2 贵方源码已明确记载该限制

@deepseek-ai/dsh-sandbox-windows-acl/lib/types-Cl_DXjhk.js 第 1171–1173 行（lib/types/index.d.ts 第 29–31 行内容相同）原文：

• 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);

@deepseek-ai/dsh-win32-process/README.md 第 35 行原文：

Process creation sets STARTF_USESHOWWINDOW with SW_HIDE before target code runs. It preserves console inheritance and does not add CREATE_NO_WINDOW or CREATE_NEW_CONSOLE, which can fail DLL initialization under the restricted token. Existing parent console windows are not hidden.

即：受限子进程只能共享宿主已有的控制台；一旦没有控制台可继承，就会以 STATUS_DLL_INIT_FAILED 死亡。这是受限令牌的固有限制，但调用方（桌面宿主）没有满足它的前置条件。

4.3 Electron 桌面宿主恰好不提供控制台

• 桌面宿主进程为 GUI 子系统应用：DeepSeek Harness.exe --expose-internals ... dsh-desktop-host。对运行中的宿主做进程树检查，全树没有任何 conhost.exe / 控制台；
• 从 app.asar 解包检查 dsh-desktop-host/lib/index.js，未见任何 AllocConsole / AttachConsole / ConPTY 相关逻辑；
• 于是 runner“继承宿主控制台”时无控制台可继承，每个受限子进程 0xC0000142；
• 相对地，从 cmd 启动的 dsh web 自身挂在真实控制台上，受限子进程可以继承，故全部正常；这也解释了为什么装好 PowerShell 7、doctor 全绿之后，Electron 版依然 100% 崩溃。

五、最小复现与对照实验矩阵（Reproduction）

我们编写了一个约 90 行的 C# 启动器 DetachedLauncher.cs（源码见附件），仅用 Win32 CreateProcessW，可按四种控制台拓扑启动贵方官方 runner.js，由 runner 再以受限令牌执行 cmd.exe /c echo CMD_SANDBOX_OK，stdout/stderr 重定向到文件。同一台机器、同一时刻结果如下：

#1 DETACHED_PROCESS（完全无控制台，等价 Electron GUI 宿主）｜经过受限令牌｜退出码 3221225794 / 0xC0000142｜输出为空——与桌面版故障逐字节一致
#2 CREATE_NO_WINDOW（Windows 为 runner 分配不可见控制台）｜经过受限令牌｜退出码 0｜输出 CMD_SANDBOX_OK
#3 CREATE_NEW_CONSOLE（新建可见控制台）｜经过受限令牌｜退出码 0｜输出 CMD_SANDBOX_OK
#4 继承已有控制台（等价 cmd 启动的 CLI web）｜经过受限令牌｜退出码 0｜输出 CMD_SANDBOX_OK
#5 DETACHED_PROCESS，但不经过 runner/受限令牌（等价 full-access）｜不受限｜退出码 0｜输出 FULLACCESS_OK
#6 wscript 以窗口样式 0（隐藏）启动 cmd 再跑 runner（无黑窗绕过方案）｜经过受限令牌｜退出码 0｜输出 HIDDEN_CONSOLE_SANDBOX_OK

原始记录（每格均有文件）：

detached.launcher.txt : detached child exit code: 3221225794 (0xC0000142)
detached.out.txt : （空，0 字节）
nonewconsole.launcher.txt: nonewconsole child exit code: 0 (0x00000000)
nonewconsole.out.txt : CMD_SANDBOX_OK
newconsole.launcher.txt : newconsole child exit code: 0 (0x00000000)
newconsole.out.txt : CMD_SANDBOX_OK
inherit.launcher.txt : inherit child exit code: 0 (0x00000000)
inherit.out.txt : CMD_SANDBOX_OK
fullaccess.launcher.txt : detached child exit code: 0 (0x00000000)
fullaccess.out.txt : FULLACCESS_OK
hidden-console-result.txt: HIDDEN_CONSOLE_SANDBOX_OK / runner exit=0

runner 的调用方式（第 6 组实际批处理原文）：

"%NODE%" "%...%\dsh-sandbox-windows-acl\lib\runner.js" --workspace "%ROOT%\ws" --temp "%ROOT%\temp" --mode workspace-write -- C:\Windows\System32\cmd.exe /c echo HIDDEN_CONSOLE_SANDBOX_OK

一个需要澄清的细节：第 2 组外层使用 CREATE_NO_WINDOW 成功，与源码注释中“CREATE_NO_WINDOW children die”并不矛盾——注释指的是给受限子进程本身加 CREATE_NO_WINDOW/CREATE_NEW_CONSOLE 会失败；而第 2 组是给 runner 宿主加 CREATE_NO_WINDOW，Windows 会为 runner 分配一个不可见控制台，受限子进程随后继承该控制台，正好满足注释要求。这也直接指明了修复方向。

结论：故障的唯一开关是“宿主有没有控制台 + 是否套受限令牌”，与 PowerShell、PATH、工作区路径、超时、杀软均无关。

六、为什么 doctor 没有发现

dsh-win32 doctor 在真实控制台（cmd/pwsh 窗口）中运行，自身始终有控制台可继承，因此 8 项全绿，但它无法覆盖“GUI 宿主无控制台”这一拓扑。建议 doctor 增加一项：检测当前进程/进程树是否实际持有控制台（如 GetConsoleWindow()/conhost 归属），并从 GUI 宿主上下文执行一次受限子进程探针。

七、临时绕过方案（已在用户侧验证，仅供参考）

以“GUI 子系统的 wscript 隐藏启动 cmd”的方式承载 CLI web：wscript 以窗口样式 0 启动 cmd /c "npx --yes @deepseek-ai/dsh web --port 3080"，Windows 会为该 cmd 分配一个隐藏控制台，沿 cmd→node 链被沙箱子进程继承。用户看不到黑窗，双击桌面图标即用，沙箱完整保留。

在 3080 网页端、Workspace Write 模式下实测 4 条命令全部退出码 0：Get-Location、node -v（v22.23.2）、cmd /c "echo SANITY_OK"（SANITY_OK）、where.exe pwsh（正确路径）。

八、修复建议（Suggested fix）

1. 首选（最小改动）：桌面宿主启动 runtime/runner 进程时，不要使用无控制台（DETACHED_PROCESS/纯 GUI 继承）方式，改为对 runner 宿主进程使用 CREATE_NO_WINDOW (0x08000000)——Windows 会分配不可见控制台，受限子进程继承它即可正常初始化（对照实验第 2 组已验证）；或在宿主启动早期调用一次 AllocConsole() 并 ShowWindow(GetConsoleWindow(), SW_HIDE) 分配隐藏控制台。
2. 备选：用 ConPTY（CreatePseudoConsole）承载沙箱子进程，同时获得稳定的 stdio 与控制台继承语义。
3. 诊断增强：dsh-win32 doctor 增加“宿主控制台存在性”检查，并在 GUI 宿主上下文中跑一次受限子进程探针。
4. 错误可观测性：当受限子进程退出码为 0xC0000142/3221225794 时，给出明确的人类可读提示（“沙箱要求可继承的控制台，当前宿主无控制台，请改用 dsh web 或更新版本”），而不是仅显示 (no output)。

九、附带问题（P2，建议一并修正文案）

DSH 系统提示中给出的原生模块路径
D:\Program Files\deepseek harness\resources\app.asar\dsh...
是 asar 归档内的虚拟路径（app.asar 是单个文件，并非目录）；物理解包目录实际为
D:\Program Files\deepseek harness\resources\app.asar.unpacked\dsh\。
该虚拟路径会误导 agent 在文件系统中查找不存在的路径，建议提示文案区分“归档内逻辑路径”与“unpacked 物理路径”。

十、附件清单（可提供）

1. DetachedLauncher.cs——四拓扑对照实验启动器源码（C#，约 90 行，仅用 kernel32 CreateProcessW）；
2. 六组实验的完整输出：detached / nonewconsole / newconsole / inherit / fullaccess 的 .launcher.txt 与 .out.txt、hidden-console-result.txt；
3. run-sandbox-hidden.bat——调用官方 runner.js 的原始命令；
4. 完整排查与修复报告 DSH-问题修复报告.md（含进程树证据、Electron 宿主解包分析、用户侧 GUI 验收结果）；
5. Electron 宿主进程树无 conhost 的核查记录、dsh-desktop-host/lib/index.js 解包副本。

[argszero]

Your root cause is correct, and it is worth saying explicitly that the two arms of it — "the restricted token may inherit a console but not create one" and "this host owns none" — are both already written down in the tree, which is what makes your matrix line up with them.

The restriction is documented at both ends

• packages/sandbox/sandbox-windows-acl/src/index.ts:29 — console isolation is unavailable — children share the host console.
• packages/subprocess/win32-process/README.md:35 — process creation preserves console inheritance and does not add CREATE_NO_WINDOW or CREATE_NEW_CONSOLE, which can fail DLL initialization under the restricted token.

Your rows 2/3/4 all supply a console from the parent side (CREATE_NO_WINDOW on the runner host, CREATE_NEW_CONSOLE, or inheriting a real one), and row 6 supplies a hidden one. That is the same distinction the source draws: the flag is fatal on the confined child, benign on the runner host. Row 1 is the Electron case exactly — nothing in the tree owns a console, so there is nothing to inherit and the child asks for one of its own.

The part that is invisible from the outside: why it is silent

The reason the model retries a command that can never start is that 0xC0000142 is never classified as a sandbox failure at all:

const WINDOWS_ACL_RUNNER_FAILURE_EXIT = 127
// packages/sandbox/sandbox-local/src/index.ts:241
'windows-acl': [{ allowedExitCodes: [WINDOWS_ACL_RUNNER_FAILURE_EXIT], fatalSignatures: ['windows-acl-run: '] }],

and classifyRunnerFailure (packages/sandbox/sandbox/src/diagnostics.ts:73) continues to the next rule when the exit code is not in allowedExitCodes — before it ever looks at stderr. So the runner failure path is skipped for this code, SandboxUnavailableError is never thrown, and the result reaches the renderer as an ordinary finished command with a non-zero exit: [exit code: 3221225794]. That is a structural reason, not a missing message, and it is why your point 4 in the fix list is real work rather than a wording change.

This producer was already measured — the packaged desktop is named as its instance

The console-less runner is not a new mechanism in this codebase's history: it was established in the two earlier reports that your matrix re-confirms, and both console-less shapes are already enumerated — a GUI-subsystem host image (which is what the packaged desktop is) and a real node.exe spawned with DETACHED_PROCESS. Your experiments and those reports describe one condition, and your row 6 corresponds to the AllocConsole variant of the remedy.

Existing plugin for exactly this

This is the case @argszero/cordis-plugin-sandbox-grant-advisor was built for. Version 0.16.0 (npm: https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor) reads the canonical tool value — { kind: 'foreground', exitCode }, deliberately omitted from durable events — so 0xC0000142 is recognised structurally rather than by matching rendered text, and it prints the measured producers for that code, this one among them, with the console remedy (CREATE_NO_WINDOW on the runner host, or AllocConsole + hide, or ConPTY) and the note that a console-subsystem host works where a GUI-subsystem one dies.

Mount it by adding the patch to your profile (or applying the cordis.patch.yml it ships), and it annotates the result instead of leaving (no output):

- insert:
    - id: sandbox-grant-advisor
      name: '@argszero/cordis-plugin-sandbox-grant-advisor'

Your fix suggestion 4 ("when the exit code is 0xC0000142, give a human-readable cause") is what it does today, so it can serve as the interim while the host-side fix lands — and it is honest about its own limit: it explains, it does not repair.

On doctor reporting 8 pass / 0 fail

Agreed, and the reason is structural rather than a missing check: doctor runs in whatever console launched it, so the "host owns a console" precondition is always true there. Covering the GUI topology means running one confined-child probe from the desktop host's own context and reporting whether the host process actually owns a console — a probe whose result the host would have to publish, since a CLI cannot observe the GUI process's console state from outside.

The asar path note (your P2)

That one is a separate defect and worth its own thread: resources/app.asar/dsh/... is a path inside an archive, and the physical unpacked root is resources/app.asar.unpacked/.... Mixing the two in a prompt sends an agent looking for a directory that is not a directory. Keeping it in this report would make both harder to track.

Thank you for the four-topology launcher and for recording the negative controls — the isolation you did (same machine, same moment, console topology as the only variable, anti-virus left untouched) is what makes this actionable.