[Bug] workspace-write sandbox: every confined pwsh command exits with 0xC0000142 (STATUS_DLL_INIT_FAILED), no stderr

[kaganoxcw]

Summary

On Windows 11 (22631, x64), any command run through the pwsh tool while the
file policy is workspace-write fails with exit code 3221225794
(0xC0000142, STATUS_DLL_INIT_FAILED) and produces no stdout and no stderr.
Even a pure no-op such as exit 0 fails.

Switching the file policy to danger-full-access makes the identical command
work immediately, with no restart.

The failure is independent of the PowerShell version and of PATH. It
reproduces on Windows PowerShell 5.1 and on PowerShell 7.6.6, including a run
where DSH's own shell had already resolved to pwsh 7.6.6.

Environment

• DSH: 0.2.0-rc.2 (desktop, win-x64, update channel nightly)
• OS: Windows 11 家庭中文版 23H2, build 10.0.22631.5335, AMD64
• PowerShell: 7.6.6 Core (also reproduced on 5.1.22621.4391)
• Failing component: dsh-sandbox-local (Windows ACL restricted-token
  backend), consumed via dsh-pwsh-sandbox
• Sandbox mode when failing: workspace-write

Reproduction

1. Set the session or deployment file policy to workspace-write.
2. Run any command through the pwsh tool, for example exit 0.
3. Observe: no output, exit code 3221225794.

Current behavior

$ pwsh -Command "exit 0"
(no output)
[exit code: 3221225794]

No stderr, no runner diagnostic, no SandboxUnavailableError. The user only
ever sees a bare Windows NTSTATUS number.

Expected behavior

Either the command runs confined under workspace-write, or the failure is
classified as a sandbox runner failure (per runnerFailureRules) and surfaced
as a sandbox-infrastructure error with a readable diagnostic — not a raw
0xC0000142.

Evidence

All four runs below are on the same machine:

#   file policy         PowerShell                                 result
1   workspace-write     5.1  (no pwsh installed yet)               FAIL 3221225794
2   workspace-write     5.1  (PS7 installed, DSH not restarted)    FAIL 3221225794
3   workspace-write     7.6.6 (DSH restarted)                      FAIL 3221225794
4   danger-full-access  7.6.6                                      OK

Row 3 is the decisive one. At that point DSH's own shell was already
PowerShell 7:

PSVersion = 7.6.6
PSEdition = Core
PSHOME    = C:\Program Files\PowerShell\7

...and the confined call still died with 0xC0000142. So this is neither a
"PowerShell not found, fell back to 5.1" problem nor a PATH staleness problem.

Separately: the Windows Application event log contains no Application Error
or Windows Error Reporting entry matching c0000142, powershell, pwsh or
DeepSeek. Windows does not record this as an ordinary application crash.

Root cause (hypothesis, not verified against source)

The workspace-write path is wrapped by dsh-sandbox-local's Windows ACL
restricted-token runner. A bare NTSTATUS exit code with zero stderr suggests
the runner process itself dies at load time (DLL initialization), rather than
the confined command being denied. A denial would be reported through
denialSignatures; a runner refusal through runnerFailureRules. Neither
reaches the user, so this failure path appears to bypass the documented
classification entirely.

The sandbox reference also notes that the Windows ACL runner already reports
partial enforcement with known gaps (hard links, unrestricted reads, and the
AppContainer ACL boundary), so this backend may be the least-exercised one on
the affected configuration.

Workaround

Set the file policy to danger-full-access. The pwsh tool then works
immediately, with no restart.

Asks

1. Is the Windows ACL restricted-token runner expected to work on Windows 11
   23H2 (build 22631) non-Enterprise / consumer SKUs? Are there prerequisites,
   such as SeAssignPrimaryTokenPrivilege, a specific UAC configuration,
   AppContainer support, or particular ACL/ownership on the workspace directory?

2. If the runner cannot start, please surface a classified runner-failure
   diagnostic (or SandboxUnavailableError) instead of a raw 0xC0000142, so
   that the failure is self-diagnosing.

3. If an environmental condition makes the ACL backend unusable, consider
   falling back to danger-full-access with a visible warning, rather than
   failing every command with no expla

[kaganoxcw]

Independent corroboration: #8990 reports the same 0xC0000142 on a different machine.

Comparing the two reports narrows the scope considerably:

• OS: `[Bug][Windows 11] pwsh tool spawns fail with 0xC0000142 (STATUS_DLL_INIT_FAILED) — no output, any command, reproducible` #8990 is Windows 11 build 26100 (24H2); this report is build 22631 (23H2).
• Install layout: `[Bug][Windows 11] pwsh tool spawns fail with 0xC0000142 (STATUS_DLL_INIT_FAILED) — no output, any command, reproducible` #8990 is a per-user install under %LocalAppData%\Programs; this report is a machine-wide install on D:.
• PowerShell: `[Bug][Windows 11] pwsh tool spawns fail with 0xC0000142 (STATUS_DLL_INIT_FAILED) — no output, any command, reproducible` #8990 has no pwsh on PATH at all; this report has PowerShell 7.6.6 resolved as DSH's own shell (see Evidence, row 3).

So the failure is not tied to a specific Windows build, a specific install layout, or the presence/absence of PowerShell 7.

Both reports independently converge on the same signature — any command, any PowerShell version, no stdout, no stderr, fixed exit code 3221225794. That is consistent with the runner-process-death hypothesis above, not with a confined command being denied.

Upvoting both threads so they can be triaged together.

[clover-supply]

I have the same error when using file deleting. Win10.

[argszero]

Cross-referencing this with #9186 (posted today), which reports the same signature on a fourth build and narrows it to a single input — worth folding into the triage here, and one line of this report's framing needs correcting against the source.

The runner is not the process that dies. This report's hypothesis is that the runner fails at load time, but the backend's failure contract says otherwise: the windows-acl runner reports every runner-side failure as windows-acl-run: <detail> on stderr and exits 127 (packages/sandbox/sandbox-local/src/index.ts: RUNNER_FAILURE_RULES['windows-acl'] = [{ allowedExitCodes: [127], fatalSignatures: ['windows-acl-run: '] }]). A bare 0xC0000142 with no such line means the runner completed normally and the confined child was killed by the loader — which is also why no denialSignatures output appears: nothing was denied, nothing ran.

The same rule explains the missing diagnostic. Because only exit 127 is admitted as a runner failure, 0xC0000142 passes through as an ordinary nonzero exit status, and the renderer reports nonzero exits without erroring. So the bare NTSTATUS is not a swallowed sandbox error — it is this code never entering the classification at all. On the PTY path it is worse: the shell layer throws the fixed string PTY shell exited during startup and the status is dropped entirely. Both of this report's expectations ("classify it per runnerFailureRules" and "surface a readable diagnostic") are upstream-fix shaped, and they are a separate defect from the root cause.

On the root cause. #9186 varies one input — the restricting SID list — with manageDacls: false, and gets read-only (0 capability SIDs) working while workspace-write (≥1 capability SID) dies, on any command and any stdio shape. That matches the source's list assembly, where the capability SIDs join only under workspace-write. One caution for whoever hunts this: 0xC0000142 is the restricted-token layer's generic early-init death in both directions — the same createRestrictedToken docstring records that omitting the logon-SID/EVERYONE keep-alive group also produces it (with pwsh's CNG path failing as 0xE0434352). The status code cannot identify which mistake was made; the mode split can.

I maintain a plugin that recognizes this family at the tool-result seam and emits a durable advisory (@argszero/cordis-plugin-sandbox-grant-advisor); the next release carries #9186's discriminant. Nothing user-side repairs the token — the restricting list is rebuilt by the harness on every spawn — so read-only and danger-full-access remain the only two consistent ways out, the latter by removing the sandbox rather than fixing it.

[kaganoxcw]

Correction accepted — the runner does not die at load; the failure contract (windows-acl-run: on stderr, exit 127 allowed) means a bare 0xC0000142 shows the runner exited normally and the confined child died in the loader, which is also why no denialSignatures fired. I'll fix that line and split the classification gap out as a separate defect: only 127 is admitted, so the NTSTATUS never enters classification at all. Agreed the #9186 mode split (0 capability SIDs works, >=1 dies) is the real discriminant and that 0xC0000142 is generic in both directions. Extra data point: today, workspace-write, plain node.exe -e dies the same way — not PowerShell-specific. Noted on the plugin and on there being no user-side repair.

[Evan80238023]

我也遇到了 在win10上

[Windows] workspace-write 沙箱下所有受限子进程以 0xC0000142 (STATUS_DLL_INIT_FAILED) 失败

环境

项	值
DSH 版本	desktop 0.2.0-rc.2
系统	Windows 10 x64 (10.0.19045)
Electron / Node	44.0.0 / 24.21.0
宿主权限	以管理员身份运行（High 完整性级别）
工作区	E:\WorkSpace（NTFS）
涉及包	@deepseek-ai/dsh-sandbox-windows-acl（位于 app.asar 内 dsh/node_modules/）
pwsh 工具实际调用的可执行文件	C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe（本机未安装 PowerShell 7）

---

一、问题现象

在文件权限预设为 workspace-write 的会话中，pwsh 工具调用任何命令都以同一个退出码失败，包括最简命令：

命令：echo ok
输出：(no output)
退出码：3221225794  (0xC0000142 STATUS_DLL_INIT_FAILED)

特征：

1. 与被执行程序无关。 pwsh、cmd /c "echo ok"、以及用绝对路径调用的 node.exe -e "..." 全部以 3221225794 退出，无一例外。
2. stderr 完全为空，工具结果只有 (no output)，且宿主标记 isError: false —— 说明子进程已经被成功创建，是在加载器/DLL 初始化阶段死亡的，而非 CreateProcess 失败或沙箱 fail-closed。
3. Windows 事件查看器没有任何记录。 在刚复现故障后立即查询 Application 日志（全级别），无 DeepSeek Harness.exe / pwsh.exe / cmd.exe / node.exe 相关错误，也没有"错误模块名称"可查。这类加载器阶段失败不会写事件日志。
4. 对照组正常。 手动打开「管理员：Windows PowerShell」执行 echo ok 正常输出，说明可执行文件与系统 DLL 完好；故障只出现在"由 DSH 派生"这一环。

模式相关性（实测）：

文件权限预设	pwsh / cmd / node	退出码
danger-full-access（完全权限）	✅ 正常	0
read-only	✅ 正常	0
workspace-write	❌ 全部失败	3221225794

即：只有 workspace-write 必然失败，其余两种模式正常。因此该问题与系统 DLL、杀毒软件、环境块、profile 配置、插件均无关。

---

二、根本原因

2.1 定位到的代码

文件：dsh/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/lib/types-Cl_DXjhk.js

AclSandbox.init()（1248–1316 行）在构造受限令牌后，最后一步调用：

// 第 1293 行
setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);

setTokenDefaultDaclGrant() 定义在 801–823 行，其文档注释（785–800 行）自述目的：

Merge one full-access allow ACE for sidPtr into the token's DEFAULT DACL — the DACL every NEW object the token holder creates (without an explicit security descriptor) takes. … The merged ACE names a RESTRICTING SID (the write SID under workspace-write, Everyone under read-only), so each new object's own DACL passes pass-2 …

令牌构造见 884–897 行 createRestrictedToken()，标志位为 13 = DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED；restricting 列表为：

• read-only：[logonSid, Everyone]
• workspace-write：[logonSid, Everyone, writeSid, (tempWriteSid)]

2.2 逻辑缺陷

setTokenDefaultDaclGrant() 把 ACE 合并进令牌默认 DACL——即该令牌持有人新建内核对象（事件、互斥体、管道、节等）时自动继承的那份 DACL。加载器在 DLL 初始化期间会创建这类对象。

Windows 对被 WRITE_RESTRICTED 令牌访问的对象执行两次访问检查：

• pass-1：针对令牌的常规 SID 列表；
• pass-2：针对 restricting SID 列表（只对写类访问生效）。

文档注释只考虑了 pass-2，遗漏了 pass-1。而 workspace-write 传入的是能力 SID（S-1-4-…）——一个只存在于 restricting 列表、令牌常规 SID 列表里并不持有的 SID。于是：

• pass-2 通过（它在 restricting 列表里）；
• pass-1 不通过（令牌常规 SID 里没有它）。

结果：进程无法访问自己在初始化期间创建的对象，加载器随即以 STATUS_DLL_INIT_FAILED (0xC0000142) 结束进程 —— 表现为无输出、无 stderr、无事件日志。

2.3 二分实验证据

用 AclSandbox 直接构造沙箱（writableDirs: []、tempDir: null，因此 grantWrite() 从未执行，不产生任何磁盘/ACL 副作用），逐个排除变量：

实验	配置	结果
V1	read-only	✅ 0
V2	workspace-write + 私有 temp 目录	❌ 0xC0000142
V3	workspace-write，tempDir: null（排除 TMP/TEMP 改写）	❌ 0xC0000142
V5	workspace-write，manageDacls: false（不编辑 ACL）	❌ 0xC0000142
V4	workspace-write，writableDirs: []（完全不做任何 ACL 编辑）	❌ 0xC0000142

→ ACL 授予、Low 完整性标签、私有 temp 目录、TMP/TEMP 改写全部排除。 这些变量都不改变结果。

随后固定 workspace-write、只改写入默认 DACL 的 SID 本身：

writeSid	令牌是否持有该 SID	结果
S-1-1-0 (Everyone)	是	✅ 0
S-1-5-11 (Authenticated Users)	是	✅ 0
S-1-5-18 (LOCAL SYSTEM)	否	❌ 0xC0000142
S-1-5-21-1-2-3-4000 (任意 NT SID)	否	❌ 0xC0000142
S-1-4-0 / S-1-4-11 (NON_UNIQUE 权威)	否	❌ 0xC0000142
workspaceWriteSid(<路径>) → S-1-4-<派生值>	否（真实路径）	❌ 0xC0000142

唯一决定成败的变量：写入令牌默认 DACL 的 SID 是否为进程令牌自身持有的 SID。

补充：把同样的失败在 lib/runner.js 的 CLI 层复现时，指向一个全新创建的空目录同样以 0xC0000142 失败 —— 因此与本机 E:\WorkSpace 上任何既有的 ACL / 完整性标签残留无关（diagnose-windows-sandbox-acl 技能修不了此问题，它修复的是 ACL，不是令牌）。

2.4 为什么 read-only 侥幸正常

因为第 1293 行的 ?? 回退链：

this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid

read-only 模式下 writeSid 与 tempWriteSid 都未定义，于是回退到 worldSid（Everyone）——这恰好是令牌持有的 SID，pass-1 与 pass-2 双双通过，所以正常。

workspace-write 模式必然命中 writeSidPtr = S-1-4-…，于是必然失败。这是一个 100% 可复现的确定性缺陷，不是竞态或环境相关问题。

2.5 为什么是静默失败

没有 stderr、没有 windows-acl-run: 前缀（那是 runner 侧 fail-closed 的签名，说明沙箱自身并未报错）、没有事件日志。宿主只能看到一个裸的 NTSTATUS 退出码，因此从应用层完全看不出是沙箱导致的 —— 这也是该问题容易被误判为"系统 DLL 损坏 / 杀软 / 环境变量超限"的原因。