Bug Report — Windows 受限沙箱中启动 curl.exe 触发 0xC0000142 错误弹窗

[Qz-zhong]

• 标题 / Title: Confined Windows sandbox (WRITE_RESTRICTED token) + hidden-console child spawns die with STATUS_DLL_INIT_FAILED (0xC0000142) and pop an "Application Error" dialog — e.g. curl.exe
• 组件 / Component: @deepseek-ai/dsh — Windows 文件沙箱 / tool 执行层（@deepseek-ai/dsh-sandbox-windows-acl 及使用其 spawn 的工具，如 dsh-tool-pwsh、dsh-native-command）
• 优先级 / Severity: P2（不破坏数据；但每次受限沙箱内调用原生控制台程序都会在用户桌面弹出系统错误框，且该命令在工具结果中静默失败）
• 报告日期: 2026-09-05

---

English Summary (paste-ready)

When an agent tool command runs under the Windows file sandbox (read-only / workspace-write), the harness spawns the process under a WRITE_RESTRICTED token (CreateRestrictedToken, restricting SIDs: logon SID + Everyone [+ workspace/temp write SIDs]) via CreateProcessAsUserW. Any native console executable spawned by that process (observed with curl.exe, also where.exe, node.exe) dies before main() with STATUS_DLL_INIT_FAILED (0xC0000142) whenever it is launched without a real console (hidden-console / CREATE_NO_WINDOW pattern), and Windows pops the "Application Error" dialog on the user's desktop. The sandbox package's own docs already state this limitation ("hidden-console children die with STATUS_DLL_INIT_FAILED (0xC0000142) — verified empirically"; "children share the host console (CREATE_NO_WINDOW / CREATE_NEW_CONSOLE children die with STATUS_DLL_INIT_FAILED under the restriction)"). Confirmation: the exact same curl.exe runs fine (exit 0) when the command is escalated to full access (no restricted token). Impact: intermittent OS error dialogs during agent runs + silent failure of native tools in the confined shell. Fix suggestion: suppress the loader error dialog / give confined console children a real console, or route load failures into the tool result instead of a modal dialog.

---

1. 环境 / Environment

项	值
OS	Windows 11 Pro，build 10.0.26100（事件日志 ntdll/ucrt 版本 10.0.26100.8972）
区域	中文（错误框文案：应用程序无法正常启动(0xc0000142)）
DSH	全局安装于 D:\Nodejs\nodev24.15\node_global\node_modules\@deepseek-ai\dsh（含 @deepseek-ai/dsh-sandbox-windows-acl 等）
文件沙箱模式	workspace-write（受限）；对照实验用 danger-full-access（不受限）
复现目标	C:\Windows\System32\curl.exe（8.21.0，静态链接，Authenticode Valid）；D:\git\Git\Git\mingw64\bin\curl.exe（8.11.0，动态 libcurl）

2. 现象 / Symptom

• 用户在 DeepSeek Harness（Web GUI）中运行 agent 任务时，桌面偶发弹出系统错误框：

  curl.exe — Application Error
  应用程序无法正常启动(0xc0000142)。请单击"确定"关闭应用程序。

• 对应地，该次工具调用的命令无任何输出（进程在 main() 之前就死了）。

• 偶发性根因：仅当某次任务里，受限沙箱内的命令去启动原生控制台 exe（本会话中触发点是 curl.exe、where.exe curl、node --version 等）时才发生；纯 cmdlet / pnpm(cmd shim) / 进程内 HTTP（Invoke-RestMethod、node fetch）不受影响。

3. 复现步骤 / Reproduction

1. 在 DSH 会话默认策略（workspace-write）下，通过 pwsh 工具执行任一原生控制台程序：

   curl.exe --version
   # 或
   where.exe curl
   # 或
   node --version

2. 观察：命令返回空输出；用户桌面弹出该进程的 0xC0000142 Application Error 框。
3. 对照：给同一命令传 sandbox_permissions: danger-full-access（无受限令牌）再执行一次：

   curl.exe --version

   → 两个 curl 均正常输出并 exit 0（curl 8.21.0 … libcurl/8.21.0 Schannel / curl 8.11.0 …）。

结论：与 curl 自身、PATH、Git/MinGW、系统文件完整性均无关，差异仅在“是否处于受限令牌沙箱”。

4. 根因分析 / Root Cause

错误码 0xC0000142 = STATUS_DLL_INIT_FAILED，是 Windows 加载器在进程初始化阶段（main() 之前）的失败。

机制链条：

1. DSH 的 Windows 文件沙箱（@deepseek-ai/dsh-sandbox-windows-acl）通过
   CreateRestrictedToken（flags=WRITE_RESTRICTED，restricting SIDs = logon SID + Everyone，workspace-write 再加入 workspace/temp write SID）制造受限令牌，并用 CreateProcessAsUserW 在该令牌下启动命令子进程。
2. 受限令牌下，控制台子进程若没有真实控制台（隐藏窗口启动，宿主工具层存在 windowsHide: true，见 dsh-native-command、dsh-host-directory-picker-native），加载器初始化失败 → 0xC0000142。
3. Windows 把加载失败以模态 “Application Error” 弹窗呈现给交互会话用户；工具侧则表现为“无输出/进程未运行”。

源码内的自述证据（@deepseek-ai/dsh-sandbox-windows-acl）：

• lib/types-CNjZgO4h.js（spawn 模块注释）：

  “Restricted-process spawning … Console isolation (CREATE_NO_WINDOW / CREATE_NEW_CONSOLE) is intentionally absent: under this restriction scheme hidden-console children die with STATUS_DLL_INIT_FAILED (0xC0000142) — verified empirically, see win32-abi.ts.”

• 同文件（token 创建注释）：

  “early DLL init dies with 0xC0000142 and CNG … fails without [the keep-alive group logon SID + EVERYONE].”

• 同文件（Known boundaries 注释）：

  “children share the host console (CREATE_NO_WINDOW / CREATE_NEW_CONSOLE children die with STATUS_DLL_INIT_FAILED under the restriction)”

即：该 0xC0000142 是已知边界，但当前行为把它暴露成了：① 桌面模态弹窗；② 受限 shell 内原生工具静默不可用。真正缺的是“把加载失败优雅地归入工具结果（而非弹窗）”或“给受限控制台子进程真实控制台”。

5. 影响 / Impact

• 用户桌面在 agent 任务运行期间间歇性弹出系统错误框，打断体验、可能让用户误以为是系统/应用损坏。
• 受限沙箱 shell 内 curl 等原生工具完全不可用（每次调用都静默失败）——例如 agent 在默认策略下用 curl 做 HTTP 探测/下载一律拿不到结果，只能靠升级权限或换进程内 HTTP。

6. 建议修复 / Suggested Fix（按优先级）

1. 抑制加载失败弹窗：受限子进程创建前设置 SetErrorMode(SEM_NOGPFAULTERRORBOX) / SetThreadErrorMode（或 spawn 后兜底），使 0xC0000142 类加载失败静默化，并让工具层能拿到退出码/错误文本而非空输出。改动点：dsh-sandbox-windows-acl 的 spawn 封装。
2. 为受限控制台子进程分配真实控制台（或改为共享宿主控制台而非隐藏窗口），消除 DLL-init 失败的触发条件——注意不能简单加 CREATE_NO_WINDOW（正是触发条件）。
3. 更细的取舍：对无文件写需求的纯网络工具（如 curl）可走不受限 spawn 路径；或至少在工具说明/文档中标注“受限沙箱内不得调用原生控制台 exe，需升级执行”。

7. 规避方法 / Workaround（用户侧，已在用）

• Agent 需要 curl 等原生工具时使用 sandbox_permissions: danger-full-access（实测 exit 0）执行，或改用进程内 Invoke-RestMethod / Invoke-WebRequest / node fetch。
• 用户在任务需要真实 curl 时批准升级弹窗即可正常执行、不再报错。

8. 附：无关的旁证（请勿据此排查）

事件日志里 NahimicSvc32.exe、HnTrustCircleService.exe、python.exe(Qt6Core.dll)、DllHost(combase) 等另有崩溃记录，与本问题无因果关系（本问题仅在受限令牌 spawn 路径出现，完整权限下 curl/node 全部正常）。

[argszero]

@Qz-zhong 你的机制链条完全成立, 我在 d347e7039（v0.1.3-alpha.1）源码上逐项核实了。这个 0xC0000142 崩溃本身是"已文档化"的行为（confined 层限制), 但它引出一个更值得修复的独立问题——桌面上的模态错误弹窗。两者要分开看。

1. 崩溃机制: 你判断的没错, 且 sandbox 包的 README 已自述

• packages/sandbox/sandbox-windows-acl/README.md:115 原文: "Console isolation is unavailable — children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED (0xC0000142); children share the host console, and pipe-based stdio redirection is unaffected." —— 与你的引用一字不差, 且这是已在 README 明示的已知限制。
• :94 补充: keep-alive group（logon SID + Everyone）已存在, "without it, early DLL initialization dies with 0xC0000142 and CNG crashes pwsh with 0xE0434352." —— 也就是说, keep-alive 组已经解决了"早期 DLL init"的一部分, 但对"无真实控制台启动原生控制台 exe"这个场景, :115 明确说不可用。
• 触发链与你一致: subprocess-local/src/spawn.ts:387 windowsHide: platform === 'win32' → Node windowsHide:true 映射为 CREATE_NO_WINDOW → 受限令牌下原生控制台 exe（curl.exe / where.exe / node.exe）在 main() 前死 → 0xC0000142。native-command/src/runner.ts:27 同。

所以: 这个崩溃在 confined 层是 known/限定的, 修它意味着要么给 confined 子进程一个真实控制台（违反隔离语义）, 要么接受崩溃并在工具结果层把它转成可读错误。

2. 真正值得修的是: 崩溃不该弹模态框到用户桌面

你的痛点不是"进程死了"（这可由工具返回值承载）, 而是 Windows 弹出模态 "Application Error" 框到用户桌面——这在 agent 运行期间是骚扰性、非预期的 UI。而这在 dsh 侧是独立可修的, 与 confinement 限制正交:

• Node/win32 的 spawn 层没有任何 SetErrorMode(SEM_NOGPFAULTERRORBOX) / WER 抑制。我全仓 grep 了 SetErrorMode/GPFAULT/WER, 零命中——错误框抑制完全没做。
• SetErrorMode(SEM_NOGPFAULTERRORBOX)（C 层, 或子进程的 STARTUPINFO/环境变量 WER 配置）可让加载失败静默、把控制权交还给父进程, 这样工具侧至少能拿到一个"进程启动失败"信号, 而不是一个桌面弹窗 + 静默无输出。
• 或: attachConsole/给予子进程一个挂接的控制台, 或走 dsh-win32-process 的 spawn 原语时对 CREATE_NO_WINDOW 分支显式兼容。

3. 建议分级（供 maintainer 参考）

• P0（用户面, 本轮即可做）: 在 spawn 层抑制"应用错误弹窗"——SetErrorMode(SEM_NOGPFAULTERRORBOX)(传给子进程) 或 CREATE_NO_WINDOW 场景下把加载失败转成工具结果错误, 而非弹模态框。这直接消除作者看到的桌面骚扰。
• P1（confinement 层）: 给 confined 控制台子进程提供真实控制台（attach 到宿主 console / 或 CREATE_NEW_PROCESS_GROUP 变体）, 或把 0xC0000142 作为受限令牌下 spawn 的一个已知可预期失败在工具层显式建模（如返回 [sandbox:…] 风格标记, 让模型能识别"限制导致无法启动原生控制台程序"）。
• P2（文档）: :115 已记录崩溃, 但可补一句"崩溃会以模态 Application Error 框呈现"——把"已知限制"和"已知 UI 骚扰"分开标明。

一个澄清问题: 你观察到的弹窗是只在 workspace-write/read-only 触发, 还是有时即使受限没跑原生 exe 也弹? 如果是前者, 那 P0 的 SetErrorMode 抑制是干净的修复; 如果是后者, 可能还有别的弹窗来源（如 V8/CRT 的 debug box）需要一并处理。

我可以基于这个出一个参考 diff（spawn 层 SetErrorMode 抑制 + 工具结果错误化 + 注入式单测 stub 受限 spawn 抛 0xC0000142 断言不弹窗/转错误）。这个属于 in-tree（subprocess/native-command spawn 层）修复, 非插件面——比造插件价值更高。