[Windows] 沙箱化子进程启动失败并弹出 0xC0000142 气泡提示（无害，但持续造成误导）

[KrebsBF]

摘要

在 Windows 上，每当 DSH 执行命令类工具时，经常（非必现）弹出 Windows 对话框：

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

点确定关闭后，DSH 本体完全不受影响，可以继续正常使用。这个对话框是纯噪音。

值得注意的是它看起来像致命错误，实际不是——它只是某个子进程没能启动。

环境

项	值
dsh 版本	0.1.7-rc.2（通过 dsh plugin / runtime\bundle 安装）
Node	v24.21.0
Windows	10.0.26200
运行形态	桌面客户端（WebView2 宿主 + 内置 node 运行时）
沙箱模式	workspace-write
触发时机	DSH 执行命令类工具（pwsh / bash / 子进程）期间

复现

复现频率：经常出现，但不是每次必现
触发操作： 让DSH调整插件时，偶尔弹出警告弹窗
<img width="1280" height="800" alt="屏幕截图 2026-09-27 225310" src="https://github.com/user-attachments/assets/99957589-14fa-4c31-8dba-990f05cb50a8" />

期望：静默失败或仅记录日志；实际：弹出系统级对话框

影响

• 无功能性影响：子进程失败会被正常归类为命令失败，DSH 主进程不受影响，可继续使用
• 但是：弹窗文案是"应用程序无法正常启动"，会让人误判为 DSH 即将崩溃或环境损坏
• 需要人工点击"确定"才能关掉，属于持续性的干扰

已定位的代码路径（供参考）

1. Windows 上所有子进程都走 launchWindowsJob，且无条件带 windowsHide: true

packages/subprocess/subprocess-local/lib/index.js：

// 第 1368 行附近：Windows 走这条分支
handle = bindManagedProcess(spec, containmentMode === "linux-scope"
  ? launchLinuxScope(spec, env)
  : launchWindowsJob(spec, env));

// 第 588-604 行
function launchWindowsJob(spec, targetEnv, internals = {}) {
  const invocation = internals.runnerInvocation ?? spawnRunnerInvocation();
  const [command, ...prefix] = invocation;
  ...
  child = (internals.spawn ?? spawn)(command, [...prefix, "--", ...spec.argv], {
    cwd: process.cwd(),
    windowsHide: true,          // <-- 此处
    env: runnerEnvironment(WINDOWS_RUNNER_SELECTION, invocation),
    stdio: runnerStdio(spec, true, ignoredStdinFd ?? "pipe")
  });

command 来自 spawnRunnerInvocation()，即沙箱 runner 包装器（由
dsh-sandbox-windows-acl 负责创建受限令牌）。

2. 同一仓库的文档已把这条路径标记为会以 0xC0000142 死亡

packages/sandbox/sandbox-windows-acl/README.zh.md：

• 第 119 行（"已知限制"）：

  控制台隔离不可用。 以 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE
  创建的子进程在 DLL 初始化期间以 STATUS_DLL_INIT_FAILED（0xC0000142）死亡；
  子进程共享宿主控制台，基于管道的 stdio 重定向不受影响。

• 第 94 行：

  保活组（登录 SID + Everyone）在两种模式下都存在：没有它，早期 DLL 初始化会以
  0xC0000142 死亡、CNG 会让 pwsh 以 0xE0434352 崩溃。

英文版 README.md 同位置亦有相同表述。

3. libuv 对"隐藏窗口"提供的是三个独立标志，而非单一开关

libuv/include/uv.h：

UV_PROCESS_DETACHED             = (1 << 3),  /* 自成进程组 */
UV_PROCESS_WINDOWS_HIDE         = (1 << 4),  /* 隐藏子进程窗口 */
UV_PROCESS_WINDOWS_HIDE_CONSOLE = (1 << 5),  /* 隐藏控制台窗口 */
UV_PROCESS_WINDOWS_HIDE_GUI     = (1 << 6),  /* 隐藏 GUI 窗口 */

我的疑问（可能的修复方向）

1. launchWindowsJob 里的 windowsHide: true 是否必要？如果沙箱 runner 本身
   不需要隐藏窗口，去掉它是否能避免该路径？
2. 如果确实需要隐藏，是否能改用 libuv 的
   UV_PROCESS_WINDOWS_HIDE_CONSOLE / _GUI（对应 Node 的
   windowsHideConsole / windowsHideGUI，若可用），而不是会触发
   CREATE_NO_WINDOW 语义的通用 windowsHide？
3. 文档说"控制台隔离不可用"，但代码仍在走这条路——这是遗漏，还是
   windowsHide 与 CREATE_NO_WINDOW 其实并不等价？

我无法确认的一点：我没有在本地验证 Node 的 windowsHide 究竟映射为哪个
UV_PROCESS_* 组合（受测试环境限制，无法可靠地 spawn 进程验证），所以第 3 点
是我的推断，请以源码为准。

补充说明

• 这个报错不会写进 Windows 应用程序事件日志（0xC0000142 是进程创建阶段失败，
  近 30 天该日志中没有任何 node.exe 或 c0000142 记录），所以用户侧很难自查
• 我最初的怀疑对象是另一个程序（Rapoo 的 A HUB.exe，它确实有独立的
  Qt5Core.dll 崩溃），已排除；Codex 沙箱服务也用受限账户拉起自己的
  cua_node\node.exe，但机制不同，亦已排除

[1zyao]

Cross-link: same symptom on the desktop build, reported as #8142 — plus one extra data point that pins the mechanism down.

We drove the sandbox package directly (same machine, same package, only the host process differs). AclSandbox (workspace-write) spawning cmd /c echo hello:

host process	has a console	result
node.exe (started from a terminal)	yes	exit=0, "hello\r\n"
DeepSeek Harness.exe with ELECTRON_RUN_AS_NODE=1	no	exit=3221225794 (0xC0000142)
the same Electron process after AllocConsole()	yes	exit=0

init() succeeds in all three cases — only the confined child dies during DLL init. Identical result on the 0.1.7-rc.2 and 0.2.0-rc.1 packages.

So the trigger is simply that the host/runner has no console: the confined child must share an existing one (the README cite is exactly right — CREATE_NO_WINDOW / CREATE_NEW_CONSOLE children die with STATUS_DLL_INIT_FAILED). The desktop app's Electron host is a GUI process with no console (Chromium also frees an inherited console), which is why it fails on every confined command, while the web/CLI build (node.exe started from a terminal) is unaffected — we have an old web-era session log with 283 pwsh calls and zero 0xC0000142.

This is consistent with your windowsHide: true note: whatever hides or (re)creates a console for the runner / the runner's child sits on the failing path. Either give the host/runner a real console (AllocConsole()), or make sure the spawn does not create/replace one.

Full report + minimal repro script: #8142

（中文一句：#8142 的直接对照实验——宿主有控制台就正常、没有则全部 0xC0000142、手动 AllocConsole() 后立即恢复，可作为定位参考。）

[nailong823]

补充一个与 README「已知限制」不同的触发路径，见 #11223。

帖子里引的 sandbox-windows-acl/README.zh.md 第 119 行把 0xC0000142 归因于 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程。但实际排查中发现：走普通的 stdio: "inherit" 路径同样会以 0xC0000142 死亡，触发条件是限制性 SID 列表里挂了一个对 C:\Windows\System32 没有读 ACE 的 SID。

保持 flags = 0xD 和其余一切不变，只替换 write SID：

• S-1-5-32-545 BUILTIN\Users（System32 上 0x1200a9 读+执行）→ exit 0
• S-1-5-18 LOCAL SYSTEM（System32 上 0x1301bf 完全控制）→ 0xC0000142
• S-1-4-<hash> 工作区 capability SID（System32 上无 ACE）→ 0xC0000142

即限制性 SID 需要在 System32 上有只读权限；有写权限和无权限一样致命。第 94 行提到的保活组（登录 SID + Everyone）大概就是这条规律的一个实例，不过它不够——capability SID 本身仍会拖垮 loader。完整对照表和修复建议在 #11223。