[Windows] workspace-write 沙箱下受限子进程启动即 0xC0000142，且被当作普通退出码上报

[sunwtGitHub]

Summary

Windows 10 22H2 上，默认 workspace-write 沙箱下任何受限子进程（cmd、PowerShell 7.6.6、Windows PowerShell 5.1）都在加载阶段以 0xC0000142 (STATUS_DLL_INIT_FAILED) 终止。pwsh 工具因此每次只返回空输出 + [exit code: 3221225794]，模型和用户都看不出这是沙箱故障。

同一台机器上：read-only 模式正常；同一沙箱 runner 的完全相同调用从普通用户进程链启动时，workspace-write 也正常，且越界写入被正确拒绝。

Reproduction

1）桌面应用内最小复现

任何 pwsh 调用（例如 pwsh -Command "'hello'"）→ 空输出 + [exit code: 3221225794]；同一条命令加 sandbox_permissions: danger-full-access 单次重试 → 正常返回。会话当前权限模式即默认的 workspace-write。

2）绕开 harness，直接调用沙箱 runner

<node> "<install>/resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js" \
  --workspace <workspace> --temp <temp> --mode <read-only|workspace-write> -- <command...>

在桌面应用的进程链里运行，得到：

模式	子进程	结果
read-only	cmd /c echo	exit 0
read-only	pwsh -Command	exit 0
workspace-write	cmd /c echo	3221225794
workspace-write	pwsh -Command	3221225794
workspace-write	powershell.exe（5.1）	3221225794

即 cmd 同样死亡 —— 与 PowerShell、与 .NET 无关。

3）启动链对照（关键）

同为 explorer → cmd → pwsh 这条普通用户进程链，用同样的 argv 调同一个 runner：

模式	结果
read-only	exit 0
workspace-write	exit 0（连跑两次）
workspace-write，子进程写工作区之外的文件	exit 1，文件未生成（沙箱确实在强制执行）

结论：失败需要「桌面应用的启动链」与「workspace-write 令牌」同时成立；两者单独都不复现。

Current behavior

• 退出码 3221225794 / 0xC0000142 表示进程在加载阶段就失败，所以连 echo 都没有输出；不是超时、不是被杀（被杀在本仓库表现为 exit 1），也不是策略拒绝（那会带 [sandbox: file access denied under <mode> mode]）。
• 该失败被当成普通命令结果上报：只有 退出码 127 + stderr 带 windows-acl-run: 前缀才被判定为 runner 失败（packages/sandbox/sandbox-local/src/index.ts 的 RUNNER_FAILURE_RULES；signature 由 packages/sandbox/sandbox-windows-acl/src/runner.ts 打印）。子进程在加载期死亡既不满足退出码、也没有输出，于是用户只看到一个无法解释的退出码。
• read-only 不能作为通用替代：该模式下 pwsh 会进入 ConstrainedLanguage，[System.IO.File]::*、Get-CimInstance 等被拒（与包 README 记录的 AppLocker 探针行为一致）。

Expected behavior

• workspace-write 下受限子进程应能正常启动（其令牌构造仅比 read-only 多两个写 SID）；
• 若确实无法启动，应归类为沙箱不可用（runner failure / SANDBOX_UNAVAILABLE）并给出原因，而不是裸退出码。

Environment

• Windows 10 Pro 22H2，build 19045.3930；主机进程为 High 完整性（提权运行）；域内机器。
• PowerShell：7.6.6（Program Files MSI 安装，非 Store 版）与 Windows PowerShell 5.1.19041.3930，表现相同。
• DeepSeek Harness 桌面应用 0.2.0.2；源码为公开仓库 master（源码树未构建，复现全部使用安装版自带的 built runner）。
• 第三方安全套件（Tencent PC Manager）注册为系统防护，内核 minifilter 在线。退出其托盘 UI 后实时防护进程与两个内核驱动仍在线；把 DSH 安装目录与 PowerShell 目录加入其信任区不改变现象。因此安全软件是否参与尚未定论（防护从未被真正停止）。

已排除的变量

以下每一项都单独改过并且不改变结果：

变量	结果
命令内容（cmd /c echo 亦失败）	排除
子进程 cwd（工作区 / 用户目录）	排除
TMP/TEMP（新建普通目录 / 打了低完整性标签的目录）	排除
ACL、FILE_DELETE_CHILD deny、低完整性标签全部不施加（manageDacls: false 的 seam-managed 调用）	排除
runner 的 windowsHide（true/false）	排除
runner stdio（libuv 管道 / 继承）	排除
PowerShell 版本（7.6.6 / 5.1）	排除
提权（两条对照链都是 elevated）	排除
登录 SID（两条链同一值）	排除
AppContainer（本仓库不使用：无 CreateAppContainerProfile）	排除
作业对象 UI 限制（受限子进程只被放入 KILL_ON_JOB_CLOSE 作业）	排除

尚未定位（请求帮助的方向）

workspace-write 相比 read-only 唯一剩下的令牌差异是 packages/sandbox/sandbox-windows-acl/src/workspace-sid.ts 派生、经 token.ts::createRestrictedToken 进入限制列表、并经 index.ts 的 setTokenDefaultDaclGrant 进入令牌默认 DACL 的两个合成 S-1-4-… SID。按写限制令牌的语义，往限制列表增加 SID 只会放宽写权限；因此更可疑的是默认 DACL 中那条指向合成 SID 的 ACE。但为何必须叠加"桌面应用启动链"才复现，我们无法在本机定位到内核环节，需要内核级跟踪或干净的对照机器。

旁证一条，可能有助于判断 CI 为何未覆盖：仓库的 Windows 检查在终端驱动的普通用户进程链里运行，而本次实验显示那条链恰好是能正常工作的配置。

附带的可诊断性缺陷

建议把"受限子进程以加载器状态码死亡（如 0xC0000142）且自身无输出"归类为 runner failure / SANDBOX_UNAVAILABLE，让用户看到的是"沙箱不可用：受限子进程加载期失败（0xC0000142）"，而不是一个裸退出码。这条与主问题独立，改动小、收益直接。

[argszero]

Thank you for the control arms — the exclusion table and the "which chain" table are what make this usable, and the last line of your report is the part I want to pick up first.

The diagnosability ask already has a user-facing answer, and it is a plugin

Classifying "a confined child died in the loader with no output of its own" as a sandbox failure rather than a bare exit code is exactly what @argszero/cordis-plugin-sandbox-grant-advisor@0.17.0 does (npm · source, MIT). It watches tool results, and on 0xC0000142 it names the code rather than passing it through:

0xC0000142 is STATUS_DLL_INIT_FAILED: the Windows loader terminated the process while it was initializing its DLLs and C runtime, which is BEFORE the program's entry point. A command that ran and then failed exits with its own status and prints its own output; this one produced neither. The number is also not a portable exit status — those are 0-255, and this is a 32-bit NTSTATUS.

That is the "sandbox unavailable" sentence, said next to the call that failed instead of in place of it.

It also carries the honest part, which your report independently confirms: the status alone cannot name its own cause. The advice states that producers on both sides of the restriction land on this code, and it prints the one comparison that separates them rather than guessing — hold the command and the tool fixed, change only the mode, and see whether read-only starts what workspace-write kills. That is your first table.

So the plugin covers the user-facing half (what the operator reads) for every mode and both stdio shapes; what stays upstream is the core half you asked for — RUNNER_FAILURE_RULES in packages/sandbox/sandbox-local/src/index.ts only fires on exit 127 with the windows-acl-run: prefix, and a loader death has neither, so the tool result is structurally unable to say "sandbox unavailable". The plugin is a stopgap over a reporting gap, not a fix for it.

Two things your report changes, and one of them is a correction to that plugin

The mode switch is necessary here but not sufficient — and the plugin currently presents it as sufficient. Its native-init advice says that if read-only starts the command that workspace-write kills, you have found the producer. Your second and third tables show that check passing while a second precondition is also required: the same runner, the same argv, the same mode, started from explorer → cmd → pwsh, exits 0. So for your case the two-step procedure is mode first, then launch chain, and the plugin only teaches the first step. I will correct that text.

The mechanism you name is not the one the plugin attributes. The plugin currently frames this producer as the workspace-write restricting list carrying a capability SID. Your reasoning points elsewhere, and I think you are right: adding a SID to a write-restricting list can only widen write access, so the suspect is the ACE in the token's default DACL — the path you cite, workspace-sid.ts deriving the synthetic S-1-4-… SID through createRestrictedToken and into setTokenDefaultDaclGrant. The plugin never names that path today. I will add it, with your control arms as the evidence.

The coverage note is worth separating from the bug

the repo's Windows checks run in the terminal-driven ordinary user process chain, and this experiment shows that chain is exactly the configuration that works

That is a statement about why CI cannot catch this, and it is independent of the root cause you are still hunting: the checks exercise the one chain where the confined token behaves. Whoever ends up doing the kernel-level tracing you asked for may want the reproduction to come from the application's own chain, which is the opposite of what the terminal-driven harness naturally provides.

One boundary I would hold in the meantime: your point that read-only is not a general substitute is the right caveat to keep attached to any "switch the mode" workaround — it starts the process, and then the language itself changes underneath it (Get-CimInstance, [System.IO.File]::*). A workaround that trades a dead shell for a shell without the cmdlets is not a fix, and it is easy to recommend one without saying so.

[argszero]

Both corrections promised in my earlier comment are now shipped, and your report changed the check itself rather than just its wording. @argszero/cordis-plugin-sandbox-grant-advisor@0.18.0 is on npm (the advisory is unchanged in how it is recognized; what moved is what it hands the reader).

1. The mode switch is now step one of two, and your experiment is the reason.

The plugin already covered this code with a producer whose discriminator was "hold the command and the tool fixed, change only the MODE". Your second table falsifies that as a complete answer: from the desktop chain, cmd, PowerShell 7.6.6 and PowerShell 5.1 all died under workspace-write and all three reached exit 0 under read-only — while the same runner under the same argv, started from your explorer → cmd → pwsh chain, returned 0 in both modes. That is exactly what the restricting-list producer looks like from outside, and the rest of your report says it is not that producer. A reader who stops at step 1 is sent to repair the wrong half.

So the advisory now runs the check in two steps: step 1 is the mode switch (which confirms the sandbox is the difference), step 2 asks whether the runner owns a console — because a console-less host separates the two modes the same way. That second step is a separate report filed the same day, #9238, which did the experiment the earlier threads only inferred: a ~90-line Win32 launcher that varies only the runner's console topology, six arms, one machine, everything else held constant — DETACHED_PROCESS died with 0xC0000142 and zero output, while CREATE_NO_WINDOW on the runner, CREATE_NEW_CONSOLE, inheriting an existing console, and a hidden-console wscript → cmd carrier all reached the program with stdout intact, and the same DETACHED_PROCESS launch without the restricted token was fine. The same report records your CI observation as a general fact worth keeping: the repository's Windows checks run in a console-bearing chain, which is the one configuration that works.

One honest note where the two reports do not agree: #9238 concludes the switch is "host owns a console × restricted token", and under that rule read-only should have died on your desktop chain too — it did not. Nothing here has a root cause, so the advisory states the intersection your table measured (console-less host and confining token) and does not promote either rule to a mechanism.

2. The default-DACL ACE you suspected is now named — as a candidate, not as a finding.

Your reasoning was right about the asymmetry and it is now stated precisely in the advisory, with the source it rests on. setTokenDefaultDaclGrant (sandbox-windows-acl/src/token.ts) merges one full-access ACE for a restricting SID into the token's existing default DACL — SetEntriesInAclW, GRANT_ACCESS, FILE_ALL_ACCESS, extended rather than replaced — and the SID it names is tempWriteSid ?? writeSid ?? Everyone (src/index.ts:304): the private temp SID under workspace-write when a temp directory exists, otherwise the workspace SID, and Everyone under read-only. The workspace SID is a sha256 of the canonical workspace path, so workspace-write is the only mode whose default DACL names a synthetic S-1-4-x-y identity at all — a genuine second difference between the modes, exactly where you pointed.

What the advisory does not do is promote it: it says the candidate is unmeasured, and it says why the obvious experiment is unsafe — every new object the confined process creates takes its DACL from that default, so an ACE removed to test the theory takes every piped grandchild spawn down with it (spawn EPERM). That merge is load-bearing, not incidental.

3. read-only is not a general substitute — stated, with the backend's own reason.

Your point is now in the text with the authority it deserves rather than as a remark: the backend's README states that under read-only PowerShell cannot create its AppLocker probe files in temp and conservatively starts in ConstrainedLanguage, where Add-Type, non-core .NET static calls, COM and reflection fail (packages/sandbox/sandbox-windows-acl/README.md:192), while the shipped workspace-write path lets the probe complete and keeps FullLanguage unless the machine carries a host-wide WDAC/AppLocker policy. Your [System.IO.File]::* and Get-CimInstance observations are carried alongside it. The advisory now says outright that a command which "works" after the mode switch may be a command that no longer runs at all — the switch is a diagnostic, not a repair.

On your appendix (the diagnosability defect): agreed, and it is upstream's to fix — the plugin cannot reclassify a success into a runner failure, because RUNNER_FAILURE_RULES['windows-acl'] admits only exit 127 with the windows-acl-run: signature and the classification happens in classifyRunnerFailure before any plugin sees the result. What the plugin does instead is give the model the explanation beside the bare number, which is the part the retry loop was costing you. The SANDBOX_UNAVAILABLE reclassification still needs the code change you describe.

Install: npm i @argszero/cordis-plugin-sandbox-grant-advisor@0.18.0, then mount the entry as documented (the advisory is off by default; the optional enforceAfter blocking half is ACL-only and not part of this family).

[Firefly0619sec]

来自第二台机器的独立复现（Win10 19045 / 桌面版 0.2.0-rc.2）

先说有用的部分：同一症状、不同机器、不同安全软件、宿主控制台状态直接可测 ——
这三点各能帮你排掉或收窄一个变量。

1. 环境与现象

• Windows 10 Pro 19045（x64），DeepSeek Harness 桌面版 0.2.0-rc.2（Electron 44 / Node 24.18.1）
• PowerShell：7.6.6（官方 MSI 装到 Program Files，非 Store 版）；另有系统自带 5.1
• 桌面版默认 workspace-write 下，任何 pwsh 调用 → 空输出 + [exit code: 3221225794]
• 同一条命令改用 danger-full-access → 正常
• 失败被当成普通命令结果上报（与你报告里的可诊断性缺陷一致）

2. ★ 本机只有 Windows Defender（没有第三方安全套件）

你报告里"安全软件是否参与尚未定论"，我这里可以当一条对照：
本机无 Tencent/360 之类套件、无第三方内核 minifilter，只有 Microsoft Defender
（实时防护开启），症状与你的完全一致。

→ 第三方安全套件不太可能是必要条件（当然不能反过来完全排除 Defender 参与）。

3. ★ 宿主进程确实没有控制台 —— 这是直接测量，不是推断

判据：FreeConsole() 之后 AttachConsole(pid) 成功 ⇔ 该进程确实持有控制台
（由内核判定，比"看 conhost 的父进程"可靠 —— 后者我验证过不可靠）。

先用"我自己带控制台的 pwsh"验证判据有效，再逐个测桌面版的进程：

进程	有控制台
对照：调用方自己的 pwsh（有控制台）	True
桌面版 DSH 的全部 8 个进程	全部 False
对照：普通启动的记事本（GUI）	False

也就是说：#9238 里"宿主是否拥有控制台"这个变量，在本机能直接观测到答案是没有。

4. ★ 但这个宿主无法从外部补上控制台（三种办法都实测失败）

尝试给 GUI 进程一个控制台	结果
CreateProcessW + CREATE_NEW_CONSOLE + STARTF_USESHOWWINDOW/SW_HIDE	记事本仍无控制台
conhost.exe <exe>（老写法）	仍无控制台
conhost.exe --headless <exe>	命令本身起不来
对照：同样用 CREATE_NEW_CONSOLE 启动控制台程序（pwsh）	True → 说明启动器写法无误

结论：只有进程自己调 AllocConsole() 才能获得控制台；外部注入没有受支持的做法。

5. 对"控制台拓扑"这条线的具体建议

#9238 已经测出：隐藏控制台的 wscript → cmd 载体可用，而 DETACHED_PROCESS 必死。
那么 DSH 侧有一个低风险修法：

不要依赖"宿主碰巧有控制台"，而是在受限 runner 外面套一个自带隐藏控制台的载体
（wscript.exe → cmd.exe /c <runner> …，或宿主启动时 AllocConsole() + SW_HIDE），
让受限子进程永远有一个可继承的控制台。

桌面版是 GUI 子系统程序，它自己永远不会有控制台（本机 8/8 实测），
所以"靠宿主继承"这条路在桌面版上结构性地不成立。

6. 一个我无法回答的不一致（但本机正好是干净实验台）

#9238 的规则是"宿主有控制台 × 受限令牌"，但你的实验里
read-only 在同一个无控制台宿主下是好的 —— 两者对不上。

我这台只测了 workspace-write（会话策略如此），没有测 read-only。
但第 3 节已经证明：本机宿主确实无控制台。
→ 如果要收窄这个交叉条件，最有价值的一步是：
在无控制台的桌面宿主下，分别跑 read-only 与 workspace-write，只变这一个变量。
本机正好是现成的实验台。

7. 一句旁证（关于可诊断性）

你们建议把"受限子进程以加载器状态码死亡且自身无输出"归类为
SANDBOX_UNAVAILABLE / runner failure。我在自己项目里吃过同一类亏，
最后立的规矩是：不许静默吞异常、不许静默 return ——
把异常写进日志之后，下一次运行日志就直接点名了真凶，比任何猜测都省时间。
所以这条改动（把裸退出码换成可读原因）我也认为收益直接、值得优先做。