Windows 沙箱 workspace-write 档：任何子进程启动即 0xC0000142（DLL 初始化失败）

[uz263]

现象：Windows 沙箱（@deepseek-ai/dsh-sandbox-windows-acl）的 workspace-write 档在本机完全不可用。
它启动的任何子进程都会在 DLL 初始化阶段死亡，退出码 0xC0000142（STATUS_DLL_INIT_FAILED）。
read-only 档正常。故障可在 DSH 之外、用 DSH 自己的 runner 稳定复现。

环境：Windows 11 build 26100；PowerShell 7.6.6；本地管理员（S-1-5-21-224436101-3469062899-2174611767-500，已提权）；
会话模式 workspace-write。

复现："DeepSeek Harness.exe" /dsh/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js
--workspace --temp --mode workspace-write -- cmd /c exit 0
（ELECTRON_RUN_AS_NODE=1）
结果：read-only 全部 0x0；workspace-write 对 cmd、pwsh 7.6.6、powershell 5.1 全部 0xC0000142。
runner 没有打印 windows-acl-run 失败行、也不是退出码 127，说明令牌创建/能力 SID 授权/CreateProcessAsUserW
都成功了，是子进程起来之后死的。事件日志里没有对应 Application Error。

根因（已二分到唯一因素）：该沙箱不是 AppContainer，而是 CreateRestrictedToken 的 WRITE_RESTRICTED
令牌（flags=13）＋能力 SID（S-1-4-<sha256(工作区路径)>）。受限列表：read-only=[logonSid,Everyone]；
workspace-write=[logonSid,Everyone,工作区能力SID,临时能力SID]。
单变量矩阵（在实验室副本里逐个打补丁，已安装的 DSH 未改动）：
基线 cmd/pwsh 都 0xC0000142
去掉 Low IL 仍 0xC0000142
去掉 WRITE_RESTRICTED(13→5) 仍 0xC0000142
受限列表不放能力 SID 仍 0xC0000142
不做 TokenDefaultDacl 合并 仍 0xC0000142
不加能力 ACE 仍 0xC0000142
保留全部特权(flags=12) 仍 0xC0000142
对照组 read-only 0x0 正常
即：本机上只要能力 SID 进入受限列表，任何子进程必崩；与低完整性级别、WRITE_RESTRICTED 标志、
能力 ACE、默认 DACL 合并均无关。去掉能力 SID 不算修复，因为那正是 workspace-write 的意义。

已排除：ACL 损坏（随包技能判定 NOT_THIS_CLASS，granted=0，无需修复）；
AppContainer 相关注册表键缺失（本机确实缺 HKLM...\AppContainer 及 Storage/Mappings，但该沙箱不用
AppContainer，与本例无关，值得单独查）；可执行文件/路径问题；安全软件干扰。

影响：workspace-write 是默认档，且 Windows 上是单候选链、无回退，本机一旦启用沙箱 shell 就完全不可用。
本机临时处置：禁用 pwsh-sandbox、插入 @deepseek-ai/dsh-pwsh-local，恢复可用，代价是 shell 失去文件围栏。

建议：1) Windows 上提供回退档（例如不加能力 SID、仅 Job Object/Low IL 的围栏），避免主档一坏就没有 shell；
2) 子进程在受限令牌下以 0xC0000142 死亡时，作为沙箱失败上报，并带上令牌构成（受限列表 SDDL、
完整性级别、flags），这样这类主机一行日志就能识别。

附件（本机生成、可复现）：sandbox-probe.js（直接驱动 DSH runner 复现上表）、acl-report-*.jsonl
（随包 ACL 技能完整记录）、exp2-run.js/exp3-run.js/extract-asar.js/copy-from-asar.js（二分实验台与
asar 提取工具）、RECOVERY-CONTEXT.md / FINAL-STATE.md（完整取证与被否假设）。需要可随时提供。
可随时配合复现：Windows 11 26100、本地管理员。

[PerryLink]

0xC0000142 在本仓沙箱文档里被写了两处，而且指向两个不同成因

1. 先给最贴你现象的那一处（:127）

packages/sandbox/sandbox-windows-acl/README.md:127（原文）：

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.

⇒ 你的错误码与这条逐字对得上：在 workspace-write 下，用"隔离控制台"方式创建的进程会在 DLL 初始化阶段死掉。这不是未知缺陷，而是记录在案的已知限制。

请据此做一次判别（这是本条能否定案的关键）：

• 你复现时用的是哪种启动方式？CREATE_NO_WINDOW / CREATE_NEW_CONSOLE（例如某些库为了"不弹窗口"而带的标志）⇒ 命中这一条；
• 换成共用宿主控制台 + 管道重定向 stdio（即文档所说的"不受影响"那一种）再跑一次 ⇒ 若正常，则确认是这条。

2. 另一处可能（:102），用于排除

同 README :102：

The keep-alive group (logon SID + Everyone) is present in both modes: without it, early DLL initialization dies with 0xC0000142 and CNG crashes pwsh with 0xE0434352.

⇒ 如果任何创建方式都失败（不只是带隔离标志的），那更像保活组缺失那一类。两处成因不同、修法不同，所以第 1 节的对比实验很有必要。

3. 你已有的两条证据很有价值，建议保留

1. read-only 正常、workspace-write 不可用 ⇒ 把范围压缩到"带 write SID 的那一套授权"上；
2. 在 DSH 之外、用 DSH 自己的 runner 也能稳定复现 ⇒ 这条尤其重要，它把"agent 用法问题"排除掉，让维护者可以直接拿它当最小复现。

4. 版本提醒（本轮基线）

HEAD = origin/master = 5badb15009 = dsh-v0.2.1-alpha.1
npm: alpha = 0.2.1-alpha.1    next = 0.2.0-rc.2    latest = 0.2.0-rc.2

⚠️ 注意：npm 的 latest 不再是旧的 0.1.5-rc.3（那是几周前的情况）。

一条边界

我确认的是这两处文档对 0xC0000142 的记载（足以把你的现象归到已知限制上）。你那次到底是哪一处，取决于第 1 节的启动方式对比——我没有在 Windows 上跑沙箱。

[yuing798]

#9086 这一条是我的讨论，也是关于windows沙箱导致权限受限的问题，这是同一个设计缺口：撤销常驻授权时，缺少清理路径。可以在我的帖子下面汇总，希望这对你有帮助。

[jambolleo]

补充一个决定性数据点：把默认 DACL 合并的 SID 换成 Everyone，workspace-write 全链恢复

我不是原帖作者，但独立复现了同一现象，并补上了原二分矩阵里缺的那一格。

环境：Windows 11 22631 x64；本地管理员（SID 以 -500 结尾，已提权，FilterAdministratorToken 未启用 → 全机进程均为 High 完整性）；DSH Desktop 0.2.0-rc.2；pwsh 7.6.6（Win32 版，装于 C:\Program Files\PowerShell\7）；工作区在 E:\ 数据盘。

1. 对照矩阵（同一条链：subprocess-local/runner（IPC+Job）→ sandbox-windows-acl/runner → 受限令牌 → 子进程）

宿主可执行文件	模式	叶命令	结果
DeepSeek Harness.exe（Electron，node 模式）	workspace-write	cmd / pwsh / node	❌ 3221225794
DeepSeek Harness.exe	workspace-write	wscript.exe / pythonw.exe（GUI 子系统）	✅ 0
DeepSeek Harness.exe	read-only	cmd / pwsh	✅ 0
node.exe	workspace-write	cmd / pwsh	✅ 0

两点值得注意：

• 失败与叶命令的语言无关，与子系统类型有关：python.exe（控制台子系统）同样崩，pythonw.exe（GUI 子系统）正常 → 换 Python 并不能绕开；
• 同一台机器、同一份代码，宿主从 DeepSeek Harness.exe 换成 node.exe 即正常。而 windowsAclRunnerInvocation() 用的正是 process.execPath，桌面版下就是 Electron 二进制。

2. 原帖矩阵缺的那一格

原帖测过「不做 TokenDefaultDacl 合并 → 仍崩」，但没测「换一个 SID 去合并」。我用 asar 提取副本（未改动已安装的 DSH）逐格验证：

index.ts:304 合并所用的 SID	Electron 宿主 + workspace-write
现状 tempWriteSidPtr ?? writeSidPtr ?? worldSid（workspace-write 取到 temp 能力 SID）	❌ 3221225794
改为 worldSid（Everyone）	✅ 0
整段合并不做	❌（与原帖一致）

并在完整生产链上复验（subprocess-local/runner 以 IPC + Job 启动 sandbox-windows-acl/runner，后者建受限令牌后再起 pwsh）：{"type":"target-exit","exitCode":0}。

这条也解释了原帖其余各格为何仍崩：那些改法都没有让「新建对象自身的 DACL」里出现一个在该模式下真正生效的保活 SID——而 packages/sandbox/sandbox-windows-acl/README.md:102 恰好写明 keep-alive 组（logon SID + Everyone）缺失就是 0xC0000142 的成因。index.ts:296-303 的注释显示作者是刻意选 temp 能力 SID（避免把工作区能力泄露进临时树），所以这里可能需要在「不泄露能力 SID」与「保活」之间取一个不含能力 SID 的保活 SID。

3. 一个尚未解释、但可能有用的相关性

目前两例报告（原帖与本机）都是已提权的 RID-500 本地管理员。本机这类令牌的默认 DACL 实测为 Administrators(GENERIC_ALL) + SYSTEM(GENERIC_ALL) + logon SID(READ|EXECUTE)，不含 Everyone、不含用户 SID；普通（过滤令牌）账户通常为 用户 SID + SYSTEM。这可能正是上游自测（普通账户）命不中的原因，建议在非提权账户上对拍一次以确认。

4. 一个反直觉的补充观察

AllocConsole() 给 Electron 宿主显式补一个控制台后，workspace-write 仍崩；而 GUI 子系统子进程（wscript / pythonw）却能存活。也就是说「宿主无控制台」不足以单独解释，但「宿主无控制台 × 控制台子系统子进程 × workspace-write」是稳定判别式，或许能帮定位到具体是哪一步 DLL 初始化被拒。

5. 建议

1. setTokenDefaultDaclGrant 的合并 SID 改为一个保活组的 SID（Everyone 已验证有效），或至少优先验证该路径；
2. packages/sandbox/sandbox-windows-acl/tests/control.spec.ts 现有 "runs without a visible console" 用例，其 runner 是由带控制台、且为 node 的测试进程启动的；建议补「宿主本身无控制台」与「宿主为 Electron 二进制」两个维度；
3. 沙箱失败时把受限令牌构成（受限 SID 列表 SDDL、完整性级别、flags）写进日志，这类主机一行日志即可识别；
4. 与 [Bug] workspace-write 沙箱拦掉 pwsh 7 启动，报 0xC0000135 (3221225794)，工作区内终端不可用 #9134 合并处理：那条报的是同一现象（其 3221225794 即 0xC0000142，不是 0xC0000135）。

复现脚本、逐格日志与单变量补丁可随时提供（补丁仅作用于 asar 提取副本，安装版未改动）。

[jambolleo]

追加：不依赖任何外部产物的最小复现（用已安装的 app 即可），以及一个保留原设计意图的修法

上一条我用的是 asar 提取副本。下面这条不需要抽取、不需要额外工具，直接用已安装的桌面版就能复现（ELECTRON_RUN_AS_NODE=1 让 Electron 以 node 模式执行 runner）：

$exe    = "$env:LOCALAPPDATA\Programs\DeepSeek Harness\DeepSeek Harness.exe"
$runner = "$env:LOCALAPPDATA\Programs\DeepSeek Harness\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js"
$env:ELECTRON_RUN_AS_NODE = "1"

$ws  = "$env:TEMP\dsh-repro\ws"; $tmp = "$env:TEMP\dsh-repro\tmp"
New-Item -ItemType Directory -Force -Path $ws, $tmp | Out-Null

& $exe $runner --workspace $ws --temp $tmp --mode workspace-write -- cmd.exe /d /s /c "exit 0"  # => -1073741502 (0xC0000142)
& $exe $runner --workspace $ws --temp $tmp --mode read-only       -- cmd.exe /d /s /c "exit 0"  # => 0

本机结果：workspace-write -> -1073741502、read-only -> 0。runner 自身没有任何 windows-acl-run: 输出、也不是退出码 127，事件日志里无 Application Error —— 即令牌创建/能力 ACE/CreateProcessAsUserW 都成功，是子进程起来之后死的。

叶子命令的「子系统类型」是关键变量（同一宿主、同一模式、同一 runner）：

叶命令	子系统	结果
cmd.exe / pwsh.exe / node.exe / python.exe	控制台	❌ 0xC0000142
wscript.exe / pythonw.exe	GUI	✅ 0

⇒ 所以「把 shell 换成 Python」并不能绕开：python.exe 一样死，只有 GUI 子系统的 pythonw.exe 能活（但它没有可用 stdio，不能当 shell 用）。

关于修法：我上一条给的是 worldSid（已验证全链 target-exit: 0）。但 index.ts:296-303 的注释说明选 temp 能力 SID 是刻意的（避免默认 DACL 对象拿到共享的工作区能力），所以更贴合原意的候选是合并 logon SID —— findLogonSid 就在上面几行，且两种模式的受限列表都含它：

- setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)
+ setTokenDefaultDaclGrant(api, restrictedToken, logonSid)

需要说明的是：我只端到端验证了 worldSid，logonSid 这条变体没有在受影响主机上跑过，列出来是供优先验证；若两者都成立，建议取 logonSid，因为它不牺牲那条能力隔离性质。

另：本环境的 GitHub 凭据没有 gist 权限，外部产物无法托管，因此复现脚本以内联形式放在这里。