# [Windows] workspace-write 沙箱下受管子进程以 0xC0000142 死在 DLL 初始化，桌面弹出 Application Error

[taibailee]

[Windows] workspace-write 沙箱下受管子进程以 0xC0000142 死在 DLL 初始化，桌面弹出 Application Error

Summary

Windows 上使用默认的 workspace-write 权限模式时，经 pwsh-sandbox 执行的命令会间歇性地在
DLL 初始化阶段以 STATUS_DLL_INIT_FAILED(0xC0000142) 退出，并在用户桌面弹出模态
Application Error: 应用程序无法正常启动 (0xc0000142) 对话框。弹窗由 CSRSS 的硬错误机制弹出，
必须人工逐个点掉，工具调用同时失败。

同一台机器、同一时段，切到 danger-full-access 后跑完全相同的任务，零弹窗。
唯一变量是受限 token，因此这是 ACL 沙箱在 Windows 上的行为，不是 Node / Python / 被测命令的问题。

Reproduction

1. Windows 11，桌面版（Electron 壳 + dsh-desktop-host sidecar，自带 resources/runtime/node/node.exe）。
2. 保持默认权限模式（workspace-write，即 Windows 上的 pwsh-sandbox）。
3. 让 agent 连续执行若干条 pwsh 命令；并行工具调用时命中率显著更高。
4. 观察桌面弹出 python.exe / node.exe / curl.exe - Application Error: 应用程序无法正常启动 (0xc0000142)。

对照实验（同一台机器、同一任务、同一时段）：

DSH_PERMISSION_MODE=danger-full-access   # 受管链路被绕开
→ 0 次弹窗

Current behavior

• 系统日志 System → provider Application Popup → 事件 ID 26，30 天内 59 次。
  故障时段内没有任何其它系统事件（无服务重启、无更新、无桌面堆告警）。

• 只有控制台子系统程序受影响：node.exe、python.exe、curl.exe、claude.exe。
  explorer.exe、msedge.exe、dwm.exe 等 GUI 进程从未出现。

• 呈突发形态：同一秒内 3–5 个进程一起失败，随后按约 6s / 8s / 12s 递减的间隔再失败几批，
  然后自愈。典型样本：

  15:20:50  node.exe ×3, python.exe ×2
  15:20:56  node.exe ×3, python.exe ×2
  15:20:57  curl.exe ×2
  15:21:04  node.exe ×1, python.exe ×1
  15:21:16  node.exe ×1
  

• 已排除：物理内存/提交内存压力（16 GB 总量，故障时空闲 4.8 GB）、句柄泄漏（长驻进程句柄数正常）、
  全局注入（AppInit_DLLs 为空、LoadAppInit_DLLs=0）、桌面堆配置（SharedSection=1024,20480,768，
  系统默认值）。

Expected behavior

受管子进程正常执行，不产生任何 Application Error 对话框；即使沙箱拒绝某次执行，
也应由工具层返回结构化错误，而不是让用户在桌面上手动点掉弹窗。

Environment

• Windows 11 Pro 26100
• dsh 0.1.5-rc.2，commit fb2c4b9e698e30edb738bca4cf0618587db7d203（tag dsh-v0.1.5-rc.2）
• 桌面版 Electron 壳 + @deepseek-ai/dsh-desktop-host sidecar
• 权限模式：workspace-write（默认）

补充：该机器同时装有 360 安全卫士（进程注入型 HIPS，ZhuDongFangYu.exe 主动防御在运行），
它可能在每次 DLL 加载的关键路径上放大命中率。但上面的对照实验中 360 全程不变，
唯一变量是权限模式，因此它不是成因。

---

补充分析（供参考）

该失败模式在仓库内已被记录

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.

packages/sandbox/sandbox-windows-acl/src/token.ts:167-169
  The logon SID + EVERYONE keep-alive group is shared by both modes: early
  DLL init dies with 0xC0000142 and CNG (`\Device\CNG` write trustee —
  pwsh crashes 0xE0434352) fails without them.

.../src/token.ts:181-183
  INTERACTIVE/LOCAL are absent from BOTH lists too — the host's Public tree
  grants write to INTERACTIVE, so removing it closes that escape.
  S-1-2-1 (console logon) is intentionally absent: the package README's
  "Console isolation is unavailable" entry records the verified failure modes.

也就是说：为了堵住 C:\Users\Public 对 INTERACTIVE 的写逃逸，restricting list 移除了
S-1-5-4 / S-1-2-1；而这两个 SID 恰好也是访问窗口站 / 桌面（WinSta0 /
WinSta0\Default）所需的。README 记录的症状因此不是偶发异常，而是这个取舍的直接后果。

与 MS KB 184802 吻合

KB 184802 (“User32.dll or Kernel32.dll does not initialize”) 列出的第一条 0xc0000142 成因就是：

The process does not have the correct permissions to access the window station and desktop.

（第二条是桌面堆耗尽，本机已排除。）

受管子进程完全依赖控制台「继承」

受管目标由原生层以如下 flags 创建，不带任何控制台 flag：

packages/subprocess/win32-process/src/process.ts:509, 534
  abi.CREATE_SUSPENDED | abi.CREATE_UNICODE_ENVIRONMENT

正常情况下它继承父 runner 的控制台，因此可以工作；但一旦链路中某一环需要新建控制台
（而非继承），受限 token 下就会在 DLL init 阶段死亡——正是 README:115 记录的那条边界。
突发形态与并行工具调用（maxParallelSubCalls 默认 10）成对 spawn 的节奏一致。

为什么 f8b1309fe5 没有覆盖这个

f8b1309fe5 fix(subprocess): hide Windows shell console windows at creation 处理的是
控制台窗口闪现，并且明确避免对受限目标使用 CREATE_NO_WINDOW
（该提交注释：Preserve console inheritance: CREATE_NO_WINDOW can fail restricted-token DLL initialization.）。
它只改变窗口可见性，不改变控制台的分配 / 附着，因此这条边界依然存在。

建议方向

不要通过把 INTERACTIVE 放回 restricting list 来修——那会重新打开 token.ts:181 明确要堵的
C:\Users\Public 写逃逸。更对症的做法是：把沙箱已经为每次运行物化的 SID
（workspace SID / temp SID）额外授予 WinSta0 与 WinSta0\Default 的访问权
（窗口站/桌面是对象管理器对象，需对句柄调用 SetSecurityInfo，icacls 无法处理），
从而在不放大文件写权限的前提下恢复桌面访问。

现有变通

• 短期：danger-full-access（已实测消除弹窗）。
  注意该模式在 packages/bundle/base/cordis.patch.yml:231-240 中还会把
  approval 一并置为 never，可用 profile patch 覆盖 permission 行找回审批。
• 未验证：本 issue 未尝试修改沙箱本身。