[Desktop 0.2.0-rc.2][Windows]Windows 沙箱下 pwsh 全命令 0xC0000142

[Tenxsword]

环境：Windows 11 家庭版 26100 · DSH Desktop 0.2.0-rc.2 (Electron 0.2.0.0) · PowerShell 7.6.6
结论：ACL 受限令牌沙箱 runner 在本机无法创建可初始化的子进程，与 pwsh 安装方式、PATH、缓存、重启均无关。
临时绕过：会话「访问模式」切换为 完全权限 (Full access) 后立即恢复正常。

---

TL;DR

从 Web 端换到官方桌面客户端后，所有 pwsh 工具调用都返回：

[exit code: 3221225794]   # 0xC0000142 = STATUS_DLL_INIT_FAILED

• 失败与命令内容、被调用程序是否存在完全无关（echo hello、cmd.exe /c ver、不存在的程序，全部同一个码）；
• 沙箱的 runner 本身正常启动（否则会按契约打印 windows-acl-run: <detail> 并 exit 127，实测从未出现）；
• 真正死掉的是 runner 内部用受限令牌 + 低完整性（Low IL） 通过 CreateProcessAsUserW 造出的子进程；
• 会话切到 danger-full-access 后，同一台机器、同一个 pwsh 立刻正常（dsh-pwsh-sandbox 在该模式下 return super.execute(spec)，整条沙箱链被绕过）。

---

环境

项	值
OS	Microsoft Windows 11 家庭版 中文版，build 26100
DSH	官方桌面客户端，产品版本 0.2.0.0
DSH 运行时包	0.2.0-rc.2（desktop-runtime.json 内清单）
profile	desktop（此前 Web 端为 web）
客户端权限	管理员 / High Mandatory Level（elevated = True）
会话沙箱模式（失败时）	workspace-write
pwsh	先装 Store 版 7.6.6，后补装 MSI 版 C:\Program Files\PowerShell\7\pwsh.exe
失败期间	系统已整机重启过，客户端进程为重启后新起

---

症状与关键观测

1. 全部命令同一退出码

命令	结果
Get-Date	[exit code: 3221225794]
echo hello	[exit code: 3221225794]
cmd.exe /c ver（绝对路径、真实存在）	[exit code: 3221225794]
notepad-xyzzy /?（不存在的程序）	[exit code: 3221225794]
空命令	Error: invalid command: expected a non-empty string ✅ 参数校验正常

空命令走参数校验、非空命令一律在 spawn 阶段死掉 ⇒ 炸点不在命令、不在工具层，而在进程创建。

2. 同一台机器、同一个 pwsh，不受限时完全正常

在用户自己的窗口（管理员）里：

Get-Command pwsh            -> C:\Program Files\PowerShell\7\pwsh.exe (7.6.6.0)
pwsh --version              -> PowerShell 7.6.6
Start-Process msi  -Command 'exit 7'  -> ExitCode = 7     # ✅
Start-Process alias -Command 'exit 7' -> ExitCode = 7     # ✅
cmd /c "<alias> -NoProfile -Command exit 9" -> 9          # ✅

⇒ pwsh 可执行、别名可解析、PATH 正确。

3. 与 pwsh 安装方式无关

阶段	C:\Program Files\PowerShell\7\pwsh.exe	pwsh 工具
仅 Store 版	❌ 不存在	❌ 0xC0000142
补装 MSI 版 + 整机重启	✅ 存在	❌ 0xC0000142（依旧）

⇒ 排除了"解析到 Store 别名"这一假设：即使解析器首选的 MSI 路径已就绪，故障不变。

4. PATH / 缓存 / 重启全部排除

• candidatePwshPaths() 第 ① 候选位 %ProgramFiles%\PowerShell\7\pwsh.exe 已存在；
• Machine PATH 已含 C:\Program Files\PowerShell\7\；
• 客户端进程启动时间晚于 MSI 安装，且期间整机重启过 ⇒ 不是 dsh-pwsh-local 的 resolvedPwshPath 缓存问题。

---

根因分析

执行链（来自 @deepseek-ai/dsh-pwsh-sandbox + dsh-sandbox-windows-acl 源码）

pwsh 工具
  └─ SandboxPwshExecutor.execute(spec)
       └─ ctx.sandbox.confine(argv, policy)          # 非 danger-full-access 时
            └─ spawn: [node, runner.js,
                       --workspace <dir>, --temp <dir>, --mode workspace-write,
                       --write-sid S-1-4-…, --temp-write-sid S-1-4-…,
                       '--', pwsh, -Command, <cmd>]
                 └─ runner.js:
                      new AclSandbox({ writableDirs:[workspace], mode, manageDacls:false })
                      sandbox.init()
                      sandbox.spawn({ command, args, stdio:'inherit' })
                        └─ CreateRestrictedToken  (WRITE_RESTRICTED + restricting SIDs)
                        └─ SetTokenInformation     (完整性降到 Low, S-1-16-4096)
                        └─ CreateProcessAsUserW
                      return (await child.wait()).exitCode   # 子进程码原样透传

关键源码事实：

• runner.js 的失败契约是 stderr: "windows-acl-run: <detail>" + exit 127；
• dsh-pwsh-sandbox 会把具名 runner 失败归类为 SANDBOX_UNAVAILABLE；
• 而实测得到的是 3221225794（子进程退出码），不是 127、也不是 SANDBOX_UNAVAILABLE。

⇒ runner 正常起来了、也成功造出了子进程句柄，但那个被降为 Low IL 的子进程在 DLL 初始化阶段就死了。

官方报错文案本身已提示该场景

@deepseek-ai/dsh-sandbox 中：

…ensure the ACL restricted-token runner can start (Windows) — otherwise switch the consumer to danger-full-access.

为什么"换客户端"是分水岭

• Web 端 profile 为 web，未挂载 dsh-pwsh-sandbox，命令以 harness 自身权限运行；
• 桌面端 profile 为 desktop，bundles: [@deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app]，挂载了沙箱链（dsh-sandbox-local → dsh-sandbox-windows-acl + dsh-pwsh-sandbox）；
• 于是同一台机器上，"换客户端"等价于"开始用 ACL 受限令牌跑 pwsh"。

未确定的部分（诚实声明）

未能进一步确定受限令牌链在本机失败的具体内部原因，候选包括：

1. 低完整性/受限令牌下，子进程无法完成某些加载期访问（例如 Store 版包 ACL、或工作区 S-1-15-2-* 包 SID 项）；
2. 客户端以管理员（High IL）运行，CreateProcessAsUserW 的令牌构造与降级路径可能与该上下文相关；
3. 本机策略（如代码完整性/AppLocker 类）对受限令牌下的进程生效。

由于 danger-full-access 会整链绕过沙箱，上述候选在受限模式下无法继续复现调试——需要沙箱可用才能在沙箱内验证。

---

绕过方案（已验证）

会话「访问模式」选择器 → 切换为「完全权限 (Full access)」（机器值 danger-full-access）。

切换后立即验证：

shell-alive
2026-09-30 11:38:46 (+08:00)
7.6.6
C:\Program Files\PowerShell\7\pwsh.exe

进程链验证（证明沙箱链已被绕过）：

我 (pwsh, pid 12644) ← DeepSeek Harness.exe (11080) ← DeepSeek Harness.exe

（限制模式下这里应出现 runner.js 中间层；实际没有。）

同时确认：文件写/读/删 ✅、网络 api.github.com → HTTP 200 ✅。

⚠️ 注意：danger-full-access 会同时放宽文件沙箱与审批策略，请自行权衡。

---

复现步骤

1. Windows 11（本机 26100）+ DSH 官方桌面客户端，profile desktop；
2. 会话沙箱模式设为 workspace-write（或 read-only）；
3. 调用任意 pwsh 工具命令（例如 echo hello）；
4. 观察：[exit code: 3221225794]；
5. 把会话切到 danger-full-access，重试同一条命令 ⇒ 正常返回。

---

建议 / 提问

1. 是否有已知的 Windows 受限令牌 runner 兼容性问题清单？ 本机是否命中其中一条？
2. 期望的失败面是什么？ 若 runner 无法创建可用子进程，是否应该以 SANDBOX_UNAVAILABLE 这类具名错误上报，而不是把子进程的 0xC0000142 原样透传给模型/用户？当前表现容易被误读为"pwsh 没装"。
3. 是否有 dsh-sandbox-windows-acl 的自检入口？ 随包发布的 diagnose-windows-sandbox-acl 技能针对的是工作区写入类 ACL 拒绝，与本例（进程创建期 DLL 初始化失败）不匹配，无法据其定位。
4. 管理员权限运行客户端是否是被支持的配置？若会干扰受限令牌链，建议在文档中明确。

---

附：本次使用的诊断手段（可复用）

手段	用途
空命令 vs 非空命令对比	判断炸在参数校验还是 spawn
cmd.exe / 不存在的程序对照	证明与"目标程序是否存在"无关
Start-Process 直接起 pwsh	证明"不受限时正常"
读 dsh-pwsh-local/lib/index.js 的 candidatePwshPaths / resolvePwshPath	确认解析顺序与缓存语义
读 dsh-pwsh-sandbox/lib/index.js、dsh-sandbox-windows-acl/lib/runner.js	还原执行链与失败契约
在 %LOCALAPPDATA%\npm-cache\_npx\*\node_modules\@deepseek-ai\ 找到解包源码树	无需解包 app.asar 即可读源码
自写 asar 读取器（解析 Pickle 头）	从 app.asar 提取工具源码
进程链 ParentProcessId 追溯	验证"沙箱链是否参与本次执行"

---

报告由会话内排障过程整理；SID/用户名为脱敏占位（<USER>），其余数值均为实测原文。

[Tenxsword]

补充：根因已定位（模式对照 + 手工运行真实 runner）

决定性的模式对照

	read-only	workspace-write
pwsh 工具	✅ 完全正常（可起嵌套子进程）	❌ 0xC0000142
子进程完整性	Low (S-1-16-4096)	（子进程起不来）
TEMP	系统 TEMP，不改写	私有目录，被改写
私有 TEMP 的能力 SID 授权	不涉及	❌ 缺失
工作区能力 SID 授权	不涉及	✅ 存在（S-1-4-867134019-587543094）

⇒ 是否改写 TMP/TEMP 就是唯一开关。

已排除项（全部实测）

• 令牌配方：普通 / 降 Low 完整性 / WRITE_RESTRICTED / 禁用 Authenticated Users + INTERACTIVE + LOCAL —— 全部正常；
• 把工作区与 TEMP 的能力 SID 加入 restricting 列表 —— 仍正常（且脚本算出的工作区 SID 与 ACL 中实际 ACE 完全一致）；
• 管道 stdio（复刻 harness 的 spawn 方式）—— 正常；
• 系统级策略：WDAC 用户态=审计、Smart App Control=关闭、AppLocker=无规则；
• 安全软件：火绒 Huorong 取证后排除（ProcGrant_60 / HipsUser_60 均 0 行，只记录不拦截）；
• 手工运行从 app.asar 解包出的真实 runner（12410 文件，含 1497 个 unpacked 原生插件）—— exit 7，完全正常。

根因

让真实 runner 在 workspace-write 下运行一个会写文件的子进程，子进程自报：

TEMP : <私有 temp 目录>                    <- runner 改写后的目录
该目录 ACE：SYSTEM / Administrators / <用户>       —— 没有 tempWriteSid 的能力 SID ACE

  DENIED : <私有TEMP>\wsw-temp-probe.txt   -> Access to the path ... is denied.
  DENIED : 在私有 TEMP 下创建目录           -> Access is denied
  ALLOWED: L:\DSH\...\wsw-ws-probe.txt     <- 工作区授权正常

workspace-write 把 TMP/TEMP 指向一个未授予受限子进程写权限的私有目录，导致 pwsh 在启动阶段无法写自己的临时目录，直接死在 DLL 初始化（STATUS_DLL_INIT_FAILED）。 read-only 不改写 TEMP，因而正常。

为什么此前"手工跑 runner 成功"：手工调用时由复现方自行创建 temp 目录，且子进程只执行 exit 7（不做任何写入）⇒ 暴露不出该缺陷。子进程一旦真的写入被指派的 TEMP，缺陷立刻显形。

建议修复方向

1. spawn 前校验私有 TEMP 是否带有 tempWriteSid 的 Write ACE，缺失即失败关闭并给出具名错误（而不是让子进程以 0xC0000142 神秘死亡）；
2. 或让 runner 以 manageDacls: true 自行授权它即将指派的 TEMP；
3. 或把 TMP/TEMP 重写推迟到确认授权成功之后；
4. 文档补充：受限模式下 %TEMP% 必须带有对应能力 SID 的 Write ACE。

[argszero]

On the follow-up: the private-TEMP grant is the seam's job, and the manual runner is the one invocation that grants nothing

Your localization is checkable against the shipped code, and the measurement in it points at the reproduction rather than at the product. Three facts, then the discriminator they imply.

1. The build you run does contain the private-TEMP grant. @deepseek-ai/dsh-sandbox-local@0.2.0-rc.2 creates a random private temp per live (session, workspace) pair and grants it a capability SID derived from its own path:

const tempDir = mkdtempSync(join(tmpdir(), "dsh-"));
const tempSid = tempWriteSid(tempDir);
grant = AclWriteGrant.create(tempSid);
grant.add(tempDir);          // ← the ACE your probe found missing

(measured in the published lib/index.js; on master it is packages/sandbox/sandbox-local/src/index.ts, materializeAclGrant). The same function is fail-closed: if grant.add throws, the grant is disposed, the directory is removed, and the error propagates — a missing ACE there is not a silent outcome.

2. Who grants depends on the invocation, and one of the three combinations grants nothing.

windowsAclRunnerArgv (sandbox-local/src/index.ts) has exactly two shapes:

invocation	--temp	SID pair	who owns the DACLs	temp ACE
seam (calling session, workspace-write)	the private dsh-* dir, already granted	--write-sid + --temp-write-sid	the seam	granted before the spawn
agentless (no calling session — a runner you launch by hand)	the ambient temp root	none	the runner (manageDacls: true) — per the sandbox-windows-acl README it "creates a random private child, self-manages its temp SID, rewrites TMP/TEMP, and removes the child on exit"	granted by the runner
manual, with a copied SID pair	whatever you passed	present	nobody — the runner sees the pair and sets manageDacls: false, i.e. it "neither grants nor revokes" and only verifies that --temp-write-sid matches the SID derived from --temp	absent, with no error

Your manual run — "手工调用时由复现方自行创建 temp 目录", with SIDs you computed yourself — is the third row. That row is the one combination in which the directory the child is pointed at carries no capability ACE and nothing reports it, and it predicts exactly what you measured: TEMP with SYSTEM / Administrators / <user> only, writes denied, exit 7 fine (it writes nothing), and death at DLL init as soon as something touches TEMP.

3. That does not yet convict production, and the difference is testable. Two checks separate the rows:

• Re-run the manual runner without the pair — --workspace <ws> --temp "%TEMP%" --mode workspace-write and nothing else. The runner then self-manages: a random private child appears under %TEMP% with the capability ACE, and it is removed on exit. If the ACE is there, the manual-repro path is confirmed as the third row and tells us nothing about the desktop failure; if it is not there, the self-grant path is genuinely broken and the spawn should have failed named (see below), which is a different bug with a different owner.
• In the failing session, while it is live, read the DACL of the exact directory the confined child reports as TEMP, and compare that string with the dsh-* directory the seam created. The temp ACE is revocable by design — the provider revokes it on dispose, before deleting the directory, and a removal that fails leaves inert litter (sanitize-less by design: "crash residue is inert litter"). So a dsh-* directory found after the session ends, with no ACE, is the expected corpse and not evidence about the run that failed. Read it live, or the measurement cannot distinguish "never granted" from "revoked on the way out".

One more prediction worth having in hand: if the child's TEMP and the seam's granted directory ever diverge, the runner fails with --temp-write-sid does not match --temp — a named runner failure, not 0xC0000142.

Your four questions

1. A known-issue list. I could not find one in the repository for restricted-token runner compatibility, and I would not claim one exists from outside. What does exist is the sandbox-windows-acl README's own account of the two invocation shapes above (it is where the manageDacls: false contract is stated), and the seam's classification rules.
2. The expected failure surface. Today a child that dies is passed through as the child's own exit code, and that is by design in the current code, not an oversight: RUNNER_FAILURE_RULES for this backend is [{ allowedExitCodes: [127], fatalSignatures: ['windows-acl-run: '] }] and classifyRunnerFailure checks the exit code first (sandbox/src/diagnostics.ts), so 0xC0000142 can never match a runner-failure rule and reaches the model raw. Only the runner's own pre-exec failures are named. Your point stands on the merits — a sandbox that cannot create a usable child is a broken sandbox, not a denial, and the two are currently indistinguishable to the reader — but the gap is in the classification surface, not in the runner's contract.
3. A self-check entry. The bundled diagnose-windows-sandbox-acl is scoped to path ACLs (the standing workspace ACE and the Low label — hasExactDeny() / LOW_LABEL). Process-creation-time failures are outside it, and in the second row above it would be doubly inapplicable: with the pair present the runner does not manage DACLs at all, so it has nothing to self-check beyond the SID-to-path match it already performs. A pre-spawn validation that the private temp actually carries its capability ACE — your suggestion 1 — is the check that does not exist in any form, agentless or seam.
4. Running the client as Administrator / High IL. I can state honestly that it is an untested variable here: this project has no Windows host to measure on, and the report's own token-recipe sweep (ordinary / Low IL / WRITE_RESTRICTED / Authenticated Users + INTERACTIVE + LOCAL disabled) varied the token, not the caller's integrity level, so it does not clear that axis. I have no source-level reason to expect High IL to break the restricted-token chain, and I would not assert either direction.

On your suggested fixes

1. Validate before spawn and fail with a named error — I would support this, and the third row is precisely the case it catches. It is also the only one of the four that a runner-side change cannot express, because the runner is told it owns no DACLs.
2. Let the runner self-grant (manageDacls: true) — this is what the agentless row already does; in the seam row the pair is the contract that says the seam owns the grants (the runner reads the same pair and sets manageDacls: false), so flipping it there would give the run two writers to one DACL. If the row-1 check above shows the seam's grant landing on the wrong path, the fix belongs there, not in the runner.
3. Delay the TMP/TEMP rewrite until the grant is confirmed — no disagreement; note that in the seam row the rewrite is downstream of a grant that already threw on failure, so the ordering is only reachable through the third row.
4. Document that %TEMP% must carry the capability ACE under a confining mode — agreed in substance, and the README already states the contract from the other side ("--temp names the private directory; --temp-write-sid must match the SID derived from it"). What it does not say is what a reader should check when a child dies at init.

On the 0xC0000142 face generally

I maintain a published plugin for exactly this family of Windows sandbox reads: @argszero/cordis-plugin-sandbox-grant-advisor (currently 0.12.0, https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor, source: argszero/cordis-plugin-sandbox-grant-advisor). It turns a confined failure into the advisory the raw exit code withholds, and it already distinguishes several faces of this family — the runner-failure dialect, the workspace-denial shape (a denied write inside the workspace, both the DACL and the mandatory-label variants), the ACL provisioning face that needs WRITE_OWNER, and the console/creation-flag matrix: under a restricted token the console is inheritable but not creatable, so a creation-forcing flag decides (CREATE_NO_WINDOW and CREATE_NEW_CONSOLE die; DETACHED_PROCESS and CREATE_NEW_PROCESS_GROUP do not), while windowsHide is not a cause at all — it appears on the ordinary subprocess path (dsh-subprocess-local), not in the job runner.

Two honest notes about that asset, so nobody installs it expecting more than it does:

• it is a diagnosis surface, not a repair: it explains a failure the model/user is already looking at; it does not grant anything or change how a process is created;
• it does not cover this face. The private-TEMP/localization axis discussed above has no signature in it, and I would not add one I cannot verify — this project has no Windows host, and an unverifiable repair command is exactly the defect that class of plugin exists to answer.

[BIBIMOYU]

Cross-referencing a bisection result that differs from the env-var theory in this thread (details and the full experiment table in #8130):

• Deleting ELECTRON_RUN_AS_NODE from the confined runner's environment does not fix workspace-write on this machine (0xC0000142 remains), and read-only works with the leak present, in the same Electron-as-node host. So the leak looks like a contributing smell rather than the trigger.
• The trigger is the trustee named in the restricted token's default DACL: with this.tempWriteSidPtr ?? this.writeSidPtr (workspace-write only) console-subsystem children die during DLL init; forcing worldSid — what read-only already uses — fixes cmd/powershell while the workspace/temp grants, the Low-IL label, the TMP/TEMP rewrite and the capability SIDs in the restricting list stay unchanged. Writes outside the workspace are still denied and whoami /all still reports Mandatory Label\Low Mandatory Level S-1-16-4096.
• Only console-subsystem children are affected: a -OutputType WindowsApplication probe runs fine under workspace-write, a -OutputType ConsoleApplication probe dies with 0xC0000142.
• The exported AclSandbox API looks fine — this is an internal default-DACL choice, so a one-liner in init() is enough: setTokenDefaultDaclGrant(api, restrictedToken, worldSid);

[yunfengdanger]

补充一条可能对排错文档有用的观察：本仓库自带的 diagnose-windows-sandbox-acl 自检工具，在 0xC0000142 这类故障上会给出假阴性。

本机环境（独立复现）

项	值
DSH_PROFILE	desktop
ELECTRON_RUN_AS_NODE	1（在故障会话环境中存在）
cmd.exe /c echo CMD_WORKS	[exit code: 3221225794]
ACL 自检工具判定	NOT_THIS_CLASS

关键点：自检通过并不能排除本 issue

在同一台机器上，对工作区根目录及其全部祖先运行该自检脚本，输出为：

VERDICT=NOT_THIS_CLASS
{"writeDac":true,"packageObjects":[],"writeOwner":true}
SUMMARY FIXED=0 GRANTED=0 REFUSED=0 RESTORED=0

判定依据是：工作区根及其各级祖先均具备有效的 WRITE_DAC / WRITE_OWNER，且未发现 AppContainer 包权限项，因而未做任何修改。

问题在于该工具的检查面：它只覆盖「文件权限不足」这一类成因，而对本 issue 涉及的链路——受限令牌的默认 DACL（见本线程 comment 8）与私有 TEMP 目录的授权（见 comment 6）——在结构上不可见。

因此建议在排错文档中显式标注：

ACL 自检返回通过，不能用来排除本 issue 的故障模式。

否则排查者很容易在「权限看起来完全正常」这一步被误导，而真正的炸点在进程创建阶段。

明确划定我没能确认的部分

• 本机 ELECTRON_RUN_AS_NODE=1 确实存在于故障会话中，但我没有对该变量做差分实验，因此无法判断它是否参与触发。comment 8 已给出「删除该变量不能修复」的结论，我这边既不证实也不证伪。
• comment 8 提出的判别实验（只有控制台子系统子进程会死、GUI 子系统正常），我尝试复核但首次运行失误（把探针跑在了沙箱外，结果无效），故不提供结论。

供他人复核的最小判别探针

我准备了一个可复用探针，思路是：把同一份托管入口分别编译成两种 PE 子系统，再逐条件运行比对退出码。

• Probe.cs — 最小入口点，会写一个文件以证明 managed Main 确实执行过（避免把「进程起来了但没跑到」误判为成功）
• run-subsystem-probe.ps1 — 用 csc /target:exe 与 /target:winexe 各编一份，并校验 PE Subsystem 字段（3 = CONSOLE，2 = WINDOWS_GUI）以保证两份二进制唯一差异只有子系统

脚本内含一条防呆，这里单独提一下，因为我自己就踩了：

若四个条件全部存活，脚本直接判定 INVALID RUN - 本次几乎肯定未受限，而不是误报成「环境变量无影响」。

也就是说，这个实验必须在受限会话内运行才有意义；在 danger-full-access 下跑会得到全绿结果，与沙箱行为无关。如果其他人要复核 comment 8 的结论，建议先确认自己确实处于 workspace-write。