[Windows] 托管子进程以 windowsHide: true 启动时失败 (0xC0000142) 并弹出模态错误对话框

[5m1le71ger]

DSH-issue-windowsHide-0xC0000142.md

环境

• OS: Windows 10.0.19045 (x64)
• DSH 核心: 0.1.5-rc.1
• 启动方式: npx @deepseek-ai/dsh + dsh web --port 3080
• Node: 22.x
• 涉及工具: pwsh

问题描述

在 Windows 上,dsh-subprocess-local 以 windowsHide: true 启动托管子进程时,子进程无法完成初始化,以退出码 0xC0000142 (STATUS_DLL_INIT_FAILED) 失败。

失败进程会弹出系统级模态对话框:

xxx.exe - 应用程序错误
应用程序无法正常启动(0xc0000142)。请单击"确定"关闭应用程序。

同一可执行文件、同一参数,仅把 windowsHide 改为 false 即稳定成功。唯一变量是这一个布尔值。

最小复现

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

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

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

[5m1le71ger]

补充交叉引用：

本报告与以下既有报告高度相关，怀疑为同一根因（windowsHide: true 导致托管子进程
DLL 初始化失败）：

• powershell 调用一直不成功。 且会弹出调用框。 插件没有便捷的安装的地方。添加模型默认全选只能一个一个取消。全是问题 #409《powershell 调用一直不成功。且会弹出调用框。》—— "弹出的框" 即本文所述的
  0xC0000142 模态对话框
• Windows 子进程/shell：终止无优雅阶梯、后台孙进程输出截断、spill 文件权限不生效等 #717 Windows 子进程/shell 系统性问题清单
• windows环境鬼打墙 #121 / 执行任务中所有和 Powershell 相关的调用都会触发 unknown_tool 报错 #225 / 在 Windows 下调用 pwsh 会导致 DSH 假死 #663 / 所有工具调用失败：Error: unknown tool ""（name 字段丢失为空字符串） #615 pwsh 调用失败家族（症状不同，疑同源）

其中 #409 的"弹框"现象与本文完全对应，但当时未能定位到根因。本文给出了可复现的
最小用例与代码位置。

[5m1le71ger]

Cross-reference:

This appears to share a root cause with existing reports (managed subprocess failing
DLL initialization due to windowsHide: true):

• powershell 调用一直不成功。 且会弹出调用框。 插件没有便捷的安装的地方。添加模型默认全选只能一个一个取消。全是问题 #409 "powershell calls never succeed, and a dialog pops up" — that popup is the
  0xC0000142 modal dialog described here
• Windows 子进程/shell：终止无优雅阶梯、后台孙进程输出截断、spill 文件权限不生效等 #717 Windows subprocess/shell systemic issue list
• windows环境鬼打墙 #121 / 执行任务中所有和 Powershell 相关的调用都会触发 unknown_tool 报错 #225 / 在 Windows 下调用 pwsh 会导致 DSH 假死 #663 / 所有工具调用失败：Error: unknown tool ""（name 字段丢失为空字符串） #615 the pwsh-call failure family

#409's "popup" symptom matches exactly, but its root cause was not identified at the
time. This report provides a minimal reproduction and the exact code location.

[5m1le71ger]

补充证据

1) DSH 会话日志中没有这条记录(已确认)

我把本机四个会话的存档(~/.dsh/sessions/**/session.v3.jsonl.zstd,逐帧解压后按行解析)
全部检索了一遍,统计所有工具返回里的退出码:

出现过的 [exit code: N] : 只有 "1"
0xC0000142 / 3221225794 : 0 次

结论:该失败不会进入 DSH 会话日志。 原因应该是错误发生在子进程创建阶段,
上层只拿到"无输出 / 退出码 1",真实退出码在格式化时就被丢弃了。
因此这条记录不在 DSH 日志体系里,权威来源是 Windows 系统事件日志
(来源 Application Popup,事件 ID 26)。

2) 复现矩阵(单变量)

环境:Windows 10 10.0.19045、Node v22.22.2、PowerShell 5.1

target	stdio	detached	windowsHide	result
cmd.exe /c exit	ignore	unset	true	3221225794 (0xC0000142)
cmd.exe /c exit	ignore	unset	false	0
node -e 0	ignore	unset	true	3221225794
powershell -c exit	ignore	unset	true	3221225794
notepad.exe(GUI 子系统)	ignore	unset	true	正常启动

• 每行 stdio 都是 ignore,所以唯一变量就是 windowsHide
• detached 全程未设置
• 当父 pwsh 本身就是由 DSH 以 windowsHide: true 拉起时,同样复现

3) 事件日志:受影响的全是控制台程序

近 30 天 Application Popup(事件 ID 26),已剔除排查期间的压测批次:

total events: 12
  node.exe       5 times
  cmd.exe        4 times
  WMIC.exe       1 times
  taskkill.exe   1 times
  rg.exe         1 times

五个可执行文件全部是控制台子系统程序,GUI 程序(explorer / 浏览器 / IDE)全程未受影响。

4) 注意:该缺陷是间歇的,不是稳定复现

同一探针在较宽松的文件策略下重跑时,每一行都返回 0 且无对话框。
所以它依赖进程创建时的上下文与时序,不能靠"跑一次没复现"来否定。

附件 01-environment.txt / 02-popup-events.txt 为原始采集结果。
01-environment.txt
02-popup-events.txt

[5m1le71ger]

附注:证据来源与核查边界

本报告的排查过程在一个 DSH 会话内完成,报告人为非专业开发人员。

• 可直接复现的:复现矩阵、代码位置、事件日志查询 —— 维护者可独立验证,
  不依赖本报告的叙述。
• 属于推断的:从 windowsHide: true 到 DSH 内部调用链的因果归属,
  是排查得出的假设,尚未经 DSH 侧插桩证实。
• 报告人能够确认的是现象层面:错误对话框确实反复出现、确实由控制台程序触发;
  技术细节未由报告人独立验证。

[PerryLink]

先给结论：你的因果链方向是对的——托管子进程在 Windows 上确实无条件以 windowsHide: true 启动，而 0xC0000142（STATUS_DLL_INIT_FAILED）正是本项目 Windows ACL 沙箱文档里已记录的已知限制，属于“控制台隔离不可用”的预期行为，不是新发现的意外。

证据（HEAD = ddefc45，v0.1.6-alpha.2）：

• packages/subprocess/subprocess-local/src/spawn.ts:466：windowsHide: platform === 'win32'——win32 上托管子进程无条件为 true，该层没有任何环境变量/配置开关（我搜过 subprocess-local 源码，无相关 env）。辅助进程同样：spawn.ts:120（taskkill 清理）、windows-inspector.ts:155、windows-job.ts:141（后者是 alpha.2 新增，commit f8b1309，给沙箱 runner 的 spawn 也加了 windowsHide: true）。
• 项目文档明确记录了这个失败模式：packages/sandbox/sandbox-windows-acl/README.zh.md:117——“控制台隔离不可用。 以 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程在 DLL 初始化期间以 STATUS_DLL_INIT_FAILED（0xC0000142）死亡；子进程共享宿主控制台，基于管道的 stdio 重定向不受影响。”Node 的 windowsHide: true 就是用 CREATE_NO_WINDOW 实现的，与你最小复现的单变量矩阵完全吻合。
• 你观察到的“宽松文件策略下全部返回 0”也与该文档把它列为 ACL 沙箱已验证边界一致：触发组合是受限令牌 + 无窗口创建，取决于进程创建时的令牌与时序，所以间歇复现、且“跑一次没复现不能否定”都说得通。

一点需要补充区分：你的裸 spawnSync 复现（无 DSH、无沙箱）在普通令牌下通常不该失败，所以你的机器上可能还叠加了宿主环境因素（注入 DLL、安全软件等）。建议在完全脱离 DSH 的干净 shell（比如新开 cmd，非 DSH 拉起的 pwsh）里重跑同一行：若稳定返回 0，根因就锁定在沙箱受限令牌路径。

临时可用选项（都有源码依据）：

• 需要真实控制台交互的命令，按文档化的一次性升级路径跑在 danger-full-access 下：packages/sandbox/sandbox/src/escalation.ts:28-31 写明 workspace-write 只能升级到 danger-full-access。README.zh.md:117 同时说明基于管道的 stdio 重定向不受影响，所以多数普通命令继续用默认模式即可。
• 源码层无开关可改；把 spawn.ts:466 改成 false 只能当本地实验，升级即失效，不建议当长期方案。
• HEAD 相对 0.1.5-rc.1 没有改掉默认值：git log -S windowsHide -- packages/subprocess 只有三个“hide Windows console”提交，全部是开启而非关闭。

如果方便，把“默认策略 vs 宽松策略”下同一条探针的结果（并注明是否在 DSH 拉起的 pwsh 内执行）贴出来，能进一步圈定是受限令牌还是宿主注入问题。

[5m1le71ger]

@PerryLink Thanks — I checked your source citations and your "this is a documented
boundary, not a new finding" judgement one by one, and they hold. I also completed
the comparison half of the matrix you asked for. Two corrections are needed, one of
them to my own original report.

1) The comparison matrix you asked for (single session)

Environment: Windows 10.0.19045, Node v22.22.2, DSH 0.1.5-rc.1 (the reported version),
dsh web. Probe is the one you saw: spawnSync(target, args, { stdio: 'ignore', windowsHide: X }). Token criterion is the whoami exit code (it fails under the
restricted token — sandbox-windows-acl/README.zh.md:120).

file policy	whoami	cmd.exe /c exit hide=true	node -e 0 hide=true	both hide=false	Application Popup
workspace-write (run 1)	Access denied (exit 1)	3221225794	3221225794	0 / 0	none
danger-full-access (one-shot escalation)	sk-notwo\administrator (exit 0)	0	0	0 / 0	none
workspace-write (run 2, auto-reverted)	Access denied (exit 1)	3221225794	3221225794	0 / 0	none

The escalation is per-command and the session reverted to the default policy afterwards
(whoami fails again), so all three rows are a clean within-session control.

2) Correction one: this is not a "bare spawnSync"; no host-injection hypothesis needed

You wrote that my bare spawnSync reproduction (no DSH, no sandbox) should not normally
fail under a normal token, so host factors (injected DLLs, security software) may be
stacked on top. In fact the failing rows were executed inside a pwsh started by the DSH
sandbox, with the restricted token (whoami → Access denied proves it), and my rerun
was the same. The matrix shows "restricted token + CREATE_NO_WINDOW" is sufficient:
under a normal token hide=true returns 0 in all four rows; under the restricted token
the same four rows deterministically return 0xC0000142. "Returns 0 in a clean shell" is
therefore the expected result of that combination and does not indicate a host anomaly.
I suggest downgrading that item from "suspect the host" to "explained by the sandbox token".

3) Correction two: my own report — it is not intermittent

In item 4 of the original report I wrote that the defect is intermittent rather than
deterministic. With the comparison done, that should read: deterministic under the
restricted token (2/2 in each of two workspace-write runs; windowsHide=false
succeeded 2/2), non-triggering under a normal token. The "intermittent" impression came
from the two runs sitting under different file policies, not from timing randomness under
identical conditions.

One more observation: neither policy produced any Application Popup (event ID 26) entry.
So the exit code and the modal dialog are two separable symptoms — 0xC0000142 appears
deterministically first, and the dialog depends on the parent process error mode / GUI host
context. That is also consistent with node.exe appearing in the 30-day popup list.

4) Additional evidence you did not mention, which supports your conclusion

At HEAD (ddefc45, v0.1.6-alpha.2), commit f8b1309 "fix(subprocess): hide Windows shell
console windows at creation":

• adds windowsHide: true to the private Node Job runner launch
  (subprocess-local/src/windows-job.ts, the place you cited);
• but native process creation deliberately does not add CREATE_NO_WINDOW; it uses
  STARTF_USESHOWWINDOW | SW_HIDE. The comment in win32-process/src/process.ts reads
  "Preserve console inheritance: CREATE_NO_WINDOW can fail restricted-token DLL
  initialization";
• win32-process/README.md states it does not add "CREATE_NO_WINDOW or
  CREATE_NEW_CONSOLE, which can fail DLL initialization under the restricted token";
• the commit's agent note lists "remove consoles from every process" as a rejected
  alternative precisely because restricted-token creation with console-isolation flags has
  a recorded DLL initialization failure.

So the maintainers already implemented 0.1.6-alpha.2 under exactly the constraint you
described. That is also good news for the upgrade surface: the runner windowsHide spawns
a Node runner under a normal token, and native targets use SW_HIDE, so 0xC0000142 is
not carried into the restricted path.

5) One question I would like you to confirm

Given that restricted token + CREATE_NO_WINDOW is a deterministic failing combination,
when does spawnSubprocess in subprocess-local/src/spawn.ts (with
windowsHide: platform === 'win32') ever land inside the restricted token? In other words:
is there any DSH path that spawns a managed subprocess from the confined (in-sandbox)
context, rather than going through the ACL runner's native SW_HIDE creation? If the
answer is "no", the popups I saw on 0.1.5-rc.1 need a different source, and this line of
questioning would either pin the exact call site or show it is host residue.

Probe script and both runs attached.
probe-windowshide.js
Uploading probe-windowshide-result-danger.txt…

[5m1le71ger]

windowsHide-matrix.md
probe-windowshide-result-workspace-write.txt

[5m1le71ger]

The danger-full-access attachment kept failing to upload, so here is that result
inline. Same probe, same session as the matrix above; whoami returned exit 0
(normal token) for this run.

cmd.exe windowsHide=true status=0 signal=null error=none
node windowsHide=true status=0 signal=null error=none
cmd.exe windowsHide=false status=0 signal=null error=none
node windowsHide=false status=0 signal=null error=none

All four rows succeed, windowsHide=true included. That is the control set behind corrections 1 and 2 above: the same windowsHide: true line that fails with 0xC0000142 under the restricted token returns 0 under a normal token.