【Bug】Windows 10 上 workspace-write 沙箱模式下 pwsh 工具 100% 崩溃（0xC0000142）

[lin0306]

反馈：Windows 10 上 workspace-write 沙箱模式下 pwsh 工具 100% 崩溃（0xC0000142）

环境信息

• DSH 版本：0.2.0.0（2026-09-29 18:34 安装/更新）
• 操作系统：Windows 10 21H2（10.0.19044）
• PowerShell：7.6.3（官方 MSI 安装，默认位置 C:\Program Files\PowerShell\7，在系统 PATH 中）
• 会话权限模式：workspace-write（审批 ask）；"完全权限"模式下无此问题

现象

workspace-write 模式下，pwsh 工具执行任意命令均失败：

• 无任何 stdout/stderr 输出；
• 退出码 3221225794（0xC0000142，STATUS_DLL_INIT_FAILED）；
• 100% 复现（最小命令 Write-Output ok 亦崩）。

同一会话切回"完全权限"后，同一 pwsh 命令立即恢复正常（版本 7.6.3、$PSHOME 正常）。

复现步骤

1. 会话权限切换为 workspace-write；
2. 调用 pwsh 工具执行任意命令，例如 Write-Output ok；
3. 观察：无输出，[exit code: 3221225794]；
4. 切回"完全权限"，重试同一命令 → 正常执行。

已做的排除与诊断

1. pwsh 本体无问题：沙箱外（IDE 终端）执行 pwsh -NoProfile -Command 正常；官方 MSI 默认位置，PATH 解析正常（Get-Command pwsh -All 仅此一个）。
2. 非文件 ACL 读取问题：沙箱内 glob 可正常枚举 C:\Program Files\PowerShell\7 全部 827 个文件。
3. runner 本身未报错：输出中无 windows-acl-run: stderr 前缀、无 exit 127；推断 dsh-sandbox-local 成功以受限令牌 spawn 了 pwsh，崩溃发生在 pwsh 进程自身的早期 DLL 初始化阶段。
4. 无崩溃报告可查：Windows 事件日志（Application, Id=1000）与 WER ReportArchive/ReportQueue 均无 pwsh 记录（初始化过早，WER 未介入）。
5. 与 pwsh 安装方式无关：微软商店版已卸载（Get-AppxPackage Microsoft.PowerShell* 为空）；用户先前"商店版可用"的时段对应旧版 DSH（无当前沙箱机制），并非安装方式差异。

与 DSH 文档/源码注释的对照

DSH 打包文档（sandbox-windows-acl）与源码注释中记载：

• 保活组（登录 SID + Everyone）缺失时"early DLL initialization dies with 0xC0000142"，CNG（\Device\CNG write trustee）会让 pwsh 崩 0xE0434352；
• CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程在 DLL 初始化期间死于此码（0xC0000142），并注明"children share the host console"；
• 沙箱仅在 Win11 26200 上验证；本机为 Win10 19044。

怀疑方向：Win10 与 Win11 在控制台子系统及相关内核对象（\Device\ConDrv、conhost 创建路径）或 \Device\CNG 的 DACL 上存在差异，导致 WRITE_RESTRICTED 令牌的 pass-2 检查在 Win10 上失败（例如控制台初始化依赖被有意排除在限制列表外的 S-1-2-1 console logon SID；或 DSH 宿主为无控制台的 GUI 进程时，pwsh 需要新建控制台而触发该路径）。

影响

• workspace-write / read-only 模式下 pwsh 工具在本机（Win10）完全不可用；
• 当前变通：① 会话切回"完全权限"；② 改经 JetBrains IDE 终端 MCP（沙箱外）执行命令。

建议

1. 在 Win10 19044/21H2 环境复现并定位，重点检查控制台初始化路径与 \Device\ConDrv、\Device\CNG 在 WRITE_RESTRICTED pass-2 检查下的行为差异；
2. runner 在受限子进程早亡（尤其是初始化阶段 NTSTATUS）时输出诊断信息——当前仅镜像退出码，现场没有任何线索；
3. 若短期无法修复，请在文档中标注 Win10 兼容性现状与该已知现象。

[ismoss]

补充一组对照实验，把范围从「受限令牌 × 无控制台」再收窄一步。环境与楼主不同：Windows 10 22H2 19045.6332、DSH 桌面版 0.2.0-rc.2、pwsh 7.6.6 商店/MSIX 版。结论一致，且可复现。

相关：#8535 是同一个家族的报告（Win11 25H2），其中已有 argszero 关于「为什么只看到裸 NTSTATUS」的说明 —— 与本帖互为补充。

1. 模式 × 子系统对照（用包内 confinement runner，standalone 模式）

模式	子进程	子系统	结果
read-only	cmd.exe /c echo	控制台	exit 0，输出正常
read-only	pwsh -Command	控制台	exit 0，7.6.6 正常
workspace-write	cmd.exe /c echo	控制台	0xC0000142
workspace-write	Windows PowerShell 5.1	控制台	0xC0000142
workspace-write	商店/MSIX 版 pwsh	控制台	0xC0000142
workspace-write	rundll32.exe	GUI	exit 0

读法：① 受限令牌本身能起进程并正常退出（rundll32）；② 只有 workspace-write 死，read-only 活；③ 所以「控制台子系统」不是充分解释 —— 桌面宿主无控制台是必要背景，但不足以区分两种模式。

宿主侧 CONOUT$ 探测：pwsh 工具进程可打开（有控制台），Electron 宿主 ENOENT（无控制台）。

2. 两种模式在代码里的差异只有三处（dsh-sandbox-windows-acl@0.2.0-rc.2 的 init()）

位置	代码	是不是差异点
L1291	restrictTokenIntegrity(api, restrictedToken, lowLabelSid)	❌ 两种模式都执行（都降到 Low 完整性）
L1293	setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)	✅ read-only 回退到 EVERYONE；workspace-write 回退到工作区/临时能力 SID
L885	mode === "read-only" ? [logonSid, world] : [logonSid, world, ...writeSids]	✅ restricting 列表
runner	workspace-write 把 TMP/TEMP 改写到私有临时目录；read-only 不动	✅

关键悖论：workspace-write 的 restricting 列表是 read-only 的超集（多了工作区/临时 SID），理论上更宽松，实际却更坏。所以问题不在「限制条目多少」，而落在 token 默认 DACL 的受托人（L1293）或 TMP/TEMP 改写 这一层 —— loader 初始化期创建的内核对象走的就是 token 默认 DACL，而 read-only 那一档命名的是 EVERYONE（两种 restricting 列表里都存在），workspace-write 那一档命名的是能力 SID。

3. 已排除项

• 与 shell 选择无关：未装 pwsh 时、商店版 pwsh、系统 cmd.exe、Windows PowerShell 5.1 —— 报错完全一致；
• 与 pwsh 安装形态无关：楼主用 MSI 版同样复现，我用商店版同样复现；
• 与工作区 ACL 无关：包内 diagnose-windows-sandbox-acl.ps1 判定 VERDICT=NOT_THIS_CLASS（writeDac=true、writeOwner=true、零改动）。

4. 请求

1. 确认 workspace-write 的 token 默认 DACL 受托人是否应包含 EVERYONE（或保活组）——若是，L1293 的 ?? worldSid 回退顺序可能需要调整；
2. 在文档中标注桌面端 + Windows 的现状与可行路径（dsh web 从控制台启动）；
3. 让这类早亡至少落一条可读诊断：目前 0xC0000142 既不匹配 RUNNER_FAILURE_RULES['windows-acl'] 的 127，也没有 windows-acl-run: 前缀，于是只是一条普通非零退出，现场没有任何线索。

---

English TL;DR: On Windows 10 22H2 (19045) with the DSH desktop host, workspace-write kills every console-subsystem child with 0xC0000142, while read-only runs cmd.exe and pwsh fine, and a GUI-subsystem child (rundll32) exits 0 even under workspace-write. The two modes differ in exactly three places in AclSandbox.init(): the integrity lowering is shared (L1291), while the token default DACL trustee (L1293: tempWriteSid ?? writeSid ?? worldSid → EVERYONE under read-only vs a capability SID under workspace-write) and the TMP/TEMP rewrite are not. Note the restricting list under workspace-write is a superset of read-only's, so "fewer entries" cannot be the cause here. Workspace ACLs were ruled out (NOT_THIS_CLASS). Repro: drive dsh-sandbox-windows-acl/lib/runner.js directly in both modes and compare exit codes.

[ismoss]

补一条决定性对照（晚于上面那条）。把 dsh-sandbox-windows-acl 从 app.asar 抽出来，只换宿主进程，跑同一个 runner.js：

宿主	\\.\CONOUT$	read-only	workspace-write
Electron（桌面端）	EBADF（无可用控制台）	exit 0	0xC0000142
真 node.exe	OK（可继承）	exit 0	exit 0

有控制台宿主下 workspace-write 确实在拦：区内写 exit 0；写 C:\Windows\Temp 得 Access is denied.；读工作区外允许（读不受限，与文档一致）。
同一 runner、同一份沙箱代码、同一工作区，唯一变量是宿主有无控制台 —— 这把「受限令牌 × 无控制台，两者同时」从必要条件推进为可复现的因果。

一个可能的统一解释（供定位参考，未确认）：AclSandbox.init() 的 L1291 restrictTokenIntegrity(...) 两种模式都执行，而 L1293
setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid) 在 read-only 下回退到 EVERYONE、
在 workspace-write 下回退到能力 SID。于是：

场景	需要创建控制台？	token 默认 DACL 受托人	结果
Electron 宿主 + read-only	需要	EVERYONE	建得起来 → exit 0
Electron 宿主 + workspace-write	需要	能力 SID	建不起来 → 0xC0000142
有控制台宿主 + 任一模式	不需要（继承）	无关	都正常

注意 workspace-write 的 restricting 列表是 read-only 的超集（[logonSid, world] vs +writeSids），更宽松却更坏，所以「限制条目多少」不是这里的解释。

另提醒一个安装形态差异：本机 CLI 入口 resources\runtime\cli\bin\dsh.cmd 是
ELECTRON_RUN_AS_NODE=1 "…\DeepSeek Harness.exe" --expose-internals "…\dsh-desktop-host\lib\cli.js"，
即桌面捆绑版的 CLI 也是 Electron 宿主，同样没有控制台。所以「从控制台启动 dsh web」对桌面捆绑版可能无效，
更可能适用于 node 版安装 —— 如果这是支持路径，建议文档里区分两者，或在桌面宿主里为受限子进程提供控制台。

顺带一个测量坑：探控制台必须用设备路径 \\.\CONOUT$；裸写 CONOUT$ 在任何进程都会 ENOENT，容易误判成「没有控制台」（我第一次就这么误测了）。

[0Sakura721]

我此前全给权限给他也会出现这样的情况，频繁弹窗显示这个报错，似乎是git的报错，win11，npm安装，版本同上

[argszero]

Thanks — this is a well-built report, and the matrix converges with two source facts plus the console/host control another commenter ran. Adding what I can from the shipped code, because the "no readable diagnosis" half of your request is directly actionable.

1. Why you get a bare NTSTATUS and nothing else. That is by construction, not an oversight in the runner. packages/sandbox/sandbox-local/src/index.ts:233-241:

const RUNNER_FAILURE_RULES = {
  // ...
  'windows-acl': [{ allowedExitCodes: [127], fatalSignatures: ['windows-acl-run: '] }],
}

Only exit 127 with the windows-acl-run: signature is reclassified as a runner failure. 0xC0000142 is therefore an ordinary nonzero exit status: the runner succeeded — it built the token, spawned your pwsh, mirrored its exit code — and the death happened inside the child's loader afterwards. Nothing left in the chain has anything to say about it, which is exactly why the session shows only [exit code: 3221225794].

2. The restricting-list rule the third commenter derived matches the source's own construction. workspace-sid.ts:2 and grant.ts:61: the workspace write identity is "a deterministic S-1-4-x-y SID derived" from the workspace path, and the temp one is S-1-4-x-y-1. S-1-4 is the non-unique authority: these are path-derived values, so they can never appear among a token's enabled groups. token.ts:181-185 is then:

read-only:       [logon SID, EVERYONE]
workspace-write: [logon SID, EVERYONE, workspace SID, optional temp SID]

That is the "superset yet worse" paradox in one line: workspace-write grows the list by adding exactly the kind of entry that kills the child, while both entries present in both modes are enabled groups of the token. read-only cannot reproduce the failure for the same reason it cannot write.

3. The console co-factor is already in the repo's own limitation list (sandbox-windows-acl/README.md:127): children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED, and children otherwise "share the host console". That is consistent with the host-swap experiment — a host that owns a console lets the child inherit one, and the failing path is never taken.

4. On your request (2): this failure does become a diagnosis today — in a plugin. @argszero/cordis-plugin-sandbox-grant-advisor (npm; repo argszero/cordis-plugin-sandbox-grant-advisor) carries it as its native-init family. It is read structurally, never from text: the value must be the foreground shell projection (kind: 'foreground') with an integer exitCode whose 32-bit pattern equals 0xC0000142 — so 3221225794 and -1073741502 both match, while a command that merely prints the number in its own output cannot. It enumerates the measured producers and says why the code reaches a successful tool result at all. It will not read a pwsh terminal failure, though: that surfaces as PTY shell exited during startup, which is its own family.

5. Honest boundary. The mechanism behind the denial is not localized upstream either — README.md:189 already marks the AppContainer package-SID entry as an unconfirmed kernel rule, and your observation that it reaches ordinary Program Files and user directories, and survives icacls /reset, is new information rather than a contradiction. And to be explicit about scope: nothing here is a plugin-fixable defect. The failing code is the backend's token construction (core); a plugin can only name the class, quote the guarantee the number does and does not make, and point at the one supported escape (danger-full-access, which bypasses the provider).

[yueziji]

更正:我上一条结论错了,收回。

我上条断言「宿主无控制台」和「L1293 默认 DACL」都不成立,并给出「当且仅当」规则。补做 2×2 后,这是错的:

宿主控制台	restricting 含坏 SID	结果
无	否	exit 0
无	是	0xC0000142
有	否	exit 0
有	是	exit 0

是两项的合取,不是充要条件。我上次测 L1293 时,命令恰好跑在有控制台的 pwsh 里,落在第四格 —— 那一格怎么改都活,于是我把「无论怎么改都 exit 0」误读成了「DACL 无关」。这正是合取条件最容易踩的坑,是我的疏忽。@ismoss 的 L1293 假说、@argszero 的控制台 co-factor 都是对的。

在无控制台宿主里重测,机制就清楚了。 固定用真实的 S-1-4-*,只改默认 DACL 受托人:

默认 DACL 受托人	结果
原生(即能力 SID)	0xC0000142
EVERYONE	exit 0
INTERACTIVE	exit 0

可见与 restricting 列表本身无关,只改 DACL 受托人即可救活。

统一解释:WRITE_RESTRICTED 下访问检查走两遍(pass-1 用令牌普通 SID,pass-2 用 restricting)。S-1-4-* 永远不在令牌普通组里,于是任何 DACL 中命名它的对象都通不过 pass-1,创建即失败。而 L1293 恰好把这个能力 SID 写进了令牌的默认 DACL —— 所有未显式指派的创建都继承它。无控制台宿主里,子进程必须自己创建控制台,正好撞上这一点 → 0xC0000142。

两条独立的逃生路径也由此对齐:1 控制台可继承则无需创建 → 活;2 默认 DACL 受托人换成已启用组(read-only 用的 EVERYONE)→ 创建成功 → 活。read-only 天然安全,正是因为它走第 2 条。

修订后的请求:建议调整 L1293 —— 能力 SID 继续只用于 restricting 列表,默认 DACL 始终命名保活组(或 EVERYONE)。这样 workspace-write 在无控制台宿主下也能起子进程,同时保留写权限。

环境:Windows 10 22H2 19045、DSH 0.2.0-rc.2、dsh-sandbox-windows-acl@0.2.0-rc.2。全部单元在同一 Electron 宿主内测得,宿主控制台状态随启动方式切换(以 \\.\CONOUT$ 判定)。

[argszero]

The analysis above is now shipped as an advisory — @argszero/cordis-plugin-sandbox-grant-advisor@0.20.0.

npm install @argszero/cordis-plugin-sandbox-grant-advisor

Mount it in your dsh profile (the package ships a cordis.patch.yml); there is nothing to configure — it registers on the sandbox/tool seams and stays silent until a value matches.

What 0.20.0 adds because of this thread: the native-init advisory no longer carries this producer as one measurement of the restricting list. It carries the rule these reports established — the child dies exactly when the restricting list holds a SID that is not an enabled group of the token being restricted (16 of 16 arms, measured on Windows 10 19044 rather than the 26200 the earlier reports came from) — together with the structural consequence: the write SIDs are derived from a path (S-1-4-x-y, its temp sibling S-1-4-x-y-1), and a path-derived SID can never be an enabled group of any token, so workspace-write cannot both grant the write and start the child. The one self-rescue — adding the capability SID to the token's own groups — is recorded as refused (SetTokenInformation(TokenGroups) → Win32 error 87).

Two shapes from the same wave are carried as scope, and deliberately not claimed: #9463 (the same backend stalling before any child is spawned at all — no approval event, no process) and #9471 (a child that starts and then dies loading a library at runtime, with a message and a code of its own). Classifying either as this family would be a confident wrong cause; an advisory that names two threads is more useful than one that names the wrong one.

Repo: https://github.com/argszero/cordis-plugin-sandbox-grant-advisor

[yueziji]

@argszero 抱歉，我们此前提供的结论有误，需要进一步更正。

“restricting 列表包含非普通已启用组 SID，就必然发生 0xC0000142”不成立。本次重新使用实际安装包验证：保留真实能力 SID，有控制台时可以启动；无控制台时，仅调整默认 DACL 也可以恢复启动和区内写入。因此，我们之前的证据不能支持“workspace-write 无法同时授予写权限并启动子进程”的判断，建议修正 0.20.0 中这段说明。

我们自己的后续说明也有一处错误：单独把能力 SID 的 ACE 替换成 INTERACTIVE 仍然失败；保留能力 SID、另外追加 INTERACTIVE 才成功。原验证脚本还把整个默认 DACL 替换成了单条 ACE，并不等价于只改 L1293 的受托人；这次已经补做保留其余 ACE、只替换能力 SID 那一条的对照。

本次环境：Windows 10 Pro 22H2 19045.7725，@deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2，Electron 44.0.0 / Node 24.18.1，PowerShell 7.6.6，初始宿主为已提权管理员。直接导入本机 app.asar 内的实际 AclSandbox，并读取令牌确认用户、普通组及其属性、权限列表、restricting SID 及其属性和 Low 完整性在 DACL 对照中不变。

新增的直接证据是：原配置下，受限 GUI 子进程本身能启动，但显式调用 AllocConsole() 返回错误 5（拒绝访问）；调整默认 DACL 后该调用成功。恢复原 DACL 后又失败。有可继承控制台时，原配置下的 cmd 和 pwsh 均正常。保留能力 SID、追加当前用户 SID 授权也能通过，并非只有 EVERYONE 这一种候选。

文件边界测试使用 manageDacls: true，并将 TMP/TEMP 指向私有临时目录。相同用户、普通组、权限和 Low 完整性的非写限制基线令牌能完成所有测试写入；实际受限令牌在上述可启动配置下，可以写工作区和自己的临时目录，但区外新建、覆盖已有文件、写另一会话临时目录和另一工作区均明确返回 UnauthorizedAccessException / 0x80070005。父进程也核对了实际文件结果。

不过完整隔离及正式修复方案仍未验证，尤其不能把 EVERYONE 视为已确认的安全修复；本次也未追踪到控制台子系统内部具体哪一个对象的拒绝。因此这里更正的是旧的绝对化规则及其推论，不将修复候选升级为完整解决方案。

抱歉，之前过早给出的绝对化结论影响了你的分析。