Windows 桌面版：「工作区内修改」(workspace-write) 沙箱下所有命令以 0xC0000142 (STATUS_DLL_INIT_FAILED) 退出

[Mashen-123]

Windows 桌面版：「工作区内修改」(workspace-write) 沙箱下所有命令以 0xC0000142 (STATUS_DLL_INIT_FAILED) 退出

环境

• DSH Desktop 0.2.1-rc.3（Windows x64，中文 UI）
• 安装路径：D:\Program Files\DeepSeek Harness（非默认盘符）
• Windows x64，powershell.exe 版本 5.1.26100.9444（build 26100）
• 运行用户：BIELNB1094\Administrator（SID S-1-5-21-2189205611-531090084-720113286-500），完整性级别 High
• 未安装 PowerShell 7：C:\Program Files\PowerShell\7\pwsh.exe 不存在，PATH 中也没有可用的 pwsh.exe，shell 解析落回系统 WindowsPowerShell\v1.0\powershell.exe
• 随包 Node 运行时：resources\runtime\primary-runtime\dependencies\node\bin\node.exe（v24.21.0）

现象

会话权限设为「工作区内修改」时，任何 shell 调用都在启动阶段以退出码 3221225794（0xC0000142，STATUS_DLL_INIT_FAILED）结束，且没有任何输出。多次重试、换命令、换工作目录均一致，模型侧表现为 "pwsh is broken entirely"。

同一会话改为「完全权限」或「自动审查」后一切正常；「仅可查看」实测也正常。

复现步骤

1. 打开桌面版，新建会话，把会话权限切换为「工作区内修改」。
2. 让 agent 执行任意一条命令，例如 Get-ChildItem "$HOME\.dsh"。
3. 观察工具结果：退出码 3221225794，无 stdout/stderr。

预期：命令被沙箱约束执行，正常返回输出。
实际：子进程从未完成 DLL 初始化，直接以 0xC0000142 终止。

根因分析

1. 沙箱 runner 由 process.execPath 启动

packages/sandbox/sandbox-local/src/index.ts 的 windowsAclRunnerInvocation() 返回 [process.execPath, builtEntry]。桌面版中 process.execPath 是 Electron 可执行文件本身。

进程列表可以确认当前 DSH 服务与子进程层都跑在 Electron 二进制上：

DeepSeek Harness.exe --expose-internals "...\app.asar\dsh\node_modules\@deepseek-ai\dsh-desktop-host\lib\index.js" ...
DeepSeek Harness.exe "...\app.asar\dsh\node_modules\@deepseek-ai\dsh-subprocess-local\lib\runner.js" -- C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe ...

因此 ACL 沙箱的 runner 同样是 [DeepSeek Harness.exe, <asar>\...\dsh-sandbox-windows-acl\lib\runner.js, ...]。

2. 从 app.asar 解出真实 runner 做宿主对照

从安装目录的 app.asar 中提取真实的 dsh-sandbox-windows-acl runner（同一份 0.2.1-rc.3 产物，补齐 koffi 原生模块），用不同宿主进程启动同一条 argv，目标为 powershell.exe，参数与 DSH 实际调用一致（--workspace、--temp 为会话的私有 temp 目录、--mode、--write-sid、--temp-write-sid，并保留 DSH_SUBPROCESS_CONTROL=pipe 的第 7 号控制管道）：

宿主进程	模式	结果
node.exe（随包 Node v24.21.0）	workspace-write	0，输出正常
node.exe	read-only	0，输出正常
DeepSeek Harness.exe（ELECTRON_RUN_AS_NODE=1）	read-only	0，输出正常
DeepSeek Harness.exe	workspace-write	0xC0000142

结论：runner 逻辑与 token 构造本身没问题，故障只在「Electron 作为 runner 宿主」且「模式为 workspace-write」时出现；把宿主换成随包 node.exe 后两种模式都正常。

3. 失败点在 runner 派生的受限子进程，而非 runner 自身

在 runner 入口插入一行 console.error('RUNNER-START ' + process.execPath) 后重跑：两种宿主都打印了该行，说明 runner 已正常启动并执行到 CreateProcessAsUserW；0xC0000142 来自被沙箱包裹的子进程。

4. 已排除的变量

逐项做了对照，均与本问题无关：

• ACL 授权、Everyone 的 DeleteSubdirectoriesAndFiles 拒绝项、Low 完整性标签（工作区上这些常驻项符合设计，不是损坏）
• 私有 temp 目录 + 两个能力 SID（--write-sid / --temp-write-sid）
• TEMP/TMP 改写到私有 temp（在 runner 中临时关闭改写，问题依旧）
• 第 7 号控制管道（DSH_SUBPROCESS_CONTROL=pipe）
• Job 对象、控制台可用性（无控制台父进程下用 node.exe runner 依然成功）
• 环境变量（node.exe 与 Electron 进程的 process.env 逐项比对完全一致）
• 目标程序（cmd.exe 同样失败；GUI 目标在只读模式下成功）
• 手动重建 CreateRestrictedToken + Low 完整性 + default DACL 授权 + kill-on-close Job + TEMP 改写的独立探针，全部成功

5. 尚未定位

Electron 作为父进程时，受限子进程为何在 loader 初始化阶段失败，本轮没有定位到具体机制（控制台、Job、process mitigation、环境块均已排除）。现象本身是确定性、可稳定复现的。

影响

• 只要会话权限为「工作区内修改」，桌面版在 Windows 上完全无法执行任何命令，该模式不可用。
• 「完全权限」「自动审查」「仅可查看」不受影响（自动审查按设计不使用沙箱）。

建议修复

1. 在 Electron 宿主下不要让沙箱 runner 走 process.execPath：windowsAclRunnerInvocation() 检测 process.versions.electron，改用随包的 Node 运行时（resources/runtime/primary-runtime/dependencies/node/bin/node.exe）。同一台机器上该改动已验证可使 workspace-write 恢复正常。
2. dsh-subprocess-local 的 runner 也通过 process.execPath 启动（见上方进程列表）；虽然它派生的子进程不受限、目前未出错，建议一并统一到同一 Node 运行时，避免同类问题。
3. 若短期无法发布修复，可考虑在 Windows 桌面版对「工作区内修改」给出明确提示或兜底，而不是让每条命令都以 0xC0000142 结束。

补充说明

复现过程中未修改安装目录、未手工改动任何 ACL；实验用的解包 runner 与探针脚本已清理。工作区上残留的 S-1-4-… 授权项、Everyone deny 与 Low 标签是沙箱的常驻授权缓存，属预期行为，不属于本问题。

[PerryLink]

你这条环境里有个决定性字段：运行用户是 ...-500，也就是内置 Administrator。

CreateRestrictedToken 之前带着 LUA_TOKEN 标志。仓库里 2026-10-26 的追记写得很直接：「带上该标志时，内置 Administrator 用户无法启动任何进程，受限启动全部失败」。这正好解释「任何 shell 都在 DLL 初始化阶段以 0xC0000142 退出、且没有任何输出」——进程根本没起来，所以和 pwsh 版本、工作区 ACL 都无关。

修复是 bdd75ca1a0c（feat(windows): Remove LUA_TOKEN from Windows ACL sandbox）：token.ts 现在只传 DISABLE_MAX_PRIVILEGE | WRITE_RESTRICTED，写限制仍来自 restricting SIDs 与 Low 标签。

版本口径很重要：rc.4（504a01a9）的 token.ts:232 仍然带 LUA_TOKEN，这个修复只进了 f3803c96（0.2.2-alpha.2）及之后的 alpha 线。所以在 rc.3 上换 pwsh 7、反复重装、改 ACL 都不会有用。

现阶段的绕过办法：换一个非内置 Administrator 的账户（普通管理员账户就行）跑桌面端；或者等下一个 alpha。

我只读了源码和追记（f3803c96、504a01a9），没有在 Windows 上跑。