Windows 沙箱下 pwsh 无法启动，退出码 0xC0000142（STATUS_DLL_INIT_FAILED）

[ShenAnjun]

DSH Windows 沙箱导致 pwsh 无法启动（0xC0000142）问题报告

• 报告日期：2026-10-17
• DSH 版本：0.2.0.0（安装器标记 0.2.0-rc.2，channel nightly，win-x64）
• 操作系统：Microsoft Windows 10 专业版，Build 19045（10.0.19045），x64
• 主机 / 用户：JSMAN / Jsman（机型单一账户）
• PowerShell：7.6.7（.NET 10.0.13，CoreCLR 10.0.1326.46716）
• DSH 主目录：C:\Users\Heart\.dsh（DSH_PROFILE=desktop）

---

1. 摘要

文件策略为 workspace-write 时，DSH 的 pwsh 执行工具无法启动任何 PowerShell 进程：无 stdout、无 stderr，退出码 3221225794（0xC0000142，STATUS_DLL_INIT_FAILED）。

同一条命令在 danger-full-access 下正常。因此故障不在 PowerShell 安装、系统文件或 PATH 解析，而在 DSH 创建沙箱子进程的实现。

根因（已由决定性实验证明）：沙箱 runner 使用 CreateProcessAsUserW + CreateRestrictedToken 启动子进程。该组合产出的进程在加载 .NET 运行时之前即于 DLL 初始化阶段死亡；改用 CreateProcessW + PROC_THREAD_ATTRIBUTE_TOKEN 后完全正常。

---

2. 现象（GUI 层复现）

| 命令 | 工作目录 | 输出 | 退出码

-- | -- | -- | -- | --
1 | $PSVersionTable.PSVersion.ToString(); ...; Get-Date | 默认 | 空 | 3221225794
2 | echo ok | 默认 | 空 | 3221225794
3 | "probe" | workspace | 空 | 3221225794
4 | $PSVersionTable...; (Get-Command pwsh).Source; ... | 默认 | 空 | 3221225794
5 | echo ok | 默认 | 空 | 3221225794
6 | "probe2" | C:\Users\Heart | 空 | 3221225794
7 | $PSVersionTable...; [Environment]::UserInteractive; echo ok | 默认 | 空 | 3221225794

现已修复并验证：启用 WerSvc、清零上述三个值、为 pwsh.exe 配置 LocalDumps（DumpType=1、DumpCount=5、目录 %LOCALAPPDATA%\CrashDumps、DontShowUI=1）。用 [Environment]::FailFast() 制造真实崩溃验证通过——退出码 0x80131623，成功产出 pwsh.exe.<pid>.dmp（6.3 MB）及 Application Error 1000 + .NET Runtime 1025 事件。

复现本问题请先确保 WER 可用，否则拿不到 dump。

---

7. 一处已纠正的误判（留档，避免重复踩坑）

早期曾将一条 System.AccessViolationException（at Nt.IsLogonSid(IntPtr)，2026-10-17 12:50:27，.NET Runtime / 1026）当作沙箱注入代码的罪证。

该判断错误：IsLogonSid 实为本地诊断脚本 acl-diagnosis/probe-restricted-token.ps1:90 中的自定义 P/Invoke，崩溃原因是该探针在受限令牌（本就不含 logon SID）场景下解引用了 GetSidSubAuthority 返回的无效指针。与 DSH 实现无关，不应作为本 issue 的证据。

---

8. 最小复现步骤

1. Windows 10 19045，安装 DSH 0.2.0-rc.2（win-x64 nightly）。
2. 将 DSH 文件策略设为 workspace-write。
3. 通过 GUI 执行任意 shell 命令，例如 echo ok。
4. 观察：无输出，退出码 3221225794。
5. 将策略切换为 danger-full-access，重复同一条命令 → 正常输出。

9. 复现材料

• acl-diagnosis/repro-cpau.ps1 —— CreateProcessAsUserW 路径（失败）
• acl-diagnosis/probe-restricted-token.ps1 —— CreateProcessW + 令牌属性（成功）
• acl-diagnosis/runner-extracted.js、runner.mjs —— 从 app.asar 提取的 runner 相关代码
• 本文件

[argszero]

Thanks — the dump evidence is what this failure shape has been missing. Two corrections and three arms that would separate the causes, all from source.

The two creators in the tree are not interchangeable. packages/subprocess/win32-process/src/process.ts:532 spawnInheritedJobProcess is the CreateProcessAsUserW path and the only entry point that accepts a restricted primary token (createRestrictedProcess, CREATE_SUSPENDED + CREATE_UNICODE_ENVIRONMENT, resolved at :537). :554 spawnCurrentTokenJobProcess is the CreateProcessW path — and it runs as the current token: it passes neither a token nor an attribute list, so in-tree "CreateProcessW works, CreateProcessAsUserW dies" reads as "the child is no longer running under the restricted token". Your probe keeps the token by passing PROC_THREAD_ATTRIBUTE_TOKEN, which is a genuinely different implementation — but the arm then varies three things at once: creator API, token delivery, and the stdio block, which also differs between the two in-tree paths (inheritedStandardHandles at :537 versus targetCarrierHandles at :560).

0xC0000142 is child-side. Creation succeeded in both of your arms; the child died inside DLL initialization. So the deciding variable is what the child can reach at init — console, window station/desktop, and the default DACL it receives — not which function created it. The console half is already written down in the tree, at packages/subprocess/win32-process/src/process.ts:454: "Preserve console inheritance: CREATE_NO_WINDOW can fail restricted-token DLL initialization."

Arms that separate the causes (same restricted token, same inherited handles in all three):

1. Spawn cmd.exe /c echo ok instead of pwsh. If it also dies at init, the .NET runtime is irrelevant and the fault is the process environment.
2. Start DSH from a console-attached parent. Every measurement collected so far has this failure requiring no console in the parent — the desktop host is an Electron GUI process, exactly that case — and danger-full-access sidesteps it because no restricted token is involved at all. If a console-attached parent flips your run, the fix is "keep or provide a console", not "change the creator".
3. Add a universal trustee to the token's keep-alive groups (Authenticated Users, S-1-5-11) and re-run. The measured shape for this exit code is (no console) ∧ (the default DACL names no universal trustee); when the second half holds, the child survives even without a console. If arm 3 flips your run, the creator is not the variable.

Honest boundary: we have no Windows machine; the above is this repository's source plus the account accumulated in prior reports of 0xC0000142, not runs of our own. Arms 2 and 3 are the hypotheses to test, and your dump is the artifact that can settle which one holds.

Same shape elsewhere: #9916 reports the same 0xC0000142 on pwsh (Windows 10 22H2). Its body did not load from here — the attachment URL does not resolve on our side — so this thread is the readable one, and the two probably belong together.

Related asset: argszero/cordis-plugin-sandbox-grant-advisor collects this family — the failure shape, its preconditions, and a diagnostic that reads back the restricted token's groups and the target DACL (public repository; the 0.27.0 publish is still pending against the registry, so install from the repository or use the published 0.26.0).

Addendum — two of the three arms are already measured on this build. A measurement on Windows 10 22H2 build 19045, posted to argszero/cordis-plugin-sandbox-grant-advisor issue #1 (public repository), already contains them:

• mediator = packaged GUI-subsystem host, GetConsoleWindow() = null, child = cmd.exe /c "echo ok", merged default-DACL ACE naming the capability (temp) SID → 0xC0000142;
• same everything, ACE naming Everyone → 0x00000000; capability ACE kept and Everyone added → 0x00000000; the same arm with PowerShell 7.6.6 → ps7-ok;
• AllocConsole() before the spawn, capability SID unchanged → 0x00000000; a console-attached node.exe mediator → 0x00000000;
• dump of the restricted child's default DACL: the merged Everyone ACE plus ambient Administrators, SYSTEM and the logon SID — the merge extends rather than replaces, so "the ambient DACL is missing SYSTEM/Administrators" does not apply there.

So on 19045 the conjunction is measured and either half recovers on its own. That makes your CreateProcessW + PROC_THREAD_ATTRIBUTE_TOKEN arm a third recovery which touches neither half — a new data point rather than a contradiction, and the one worth chasing next.

Where a third recovery could come from. CreateProcessAsUserW performs the window-station/desktop association for the new process itself; the attribute-list path leaves the child to inherit the parent's. Under a restricted token exactly one of those two can fail the access check. Cheap discriminator: in both arms have the child report GetProcessWindowStation(), GetThreadDesktop(GetCurrentThreadId()) and GetConsoleWindow() (or simply attempt to open winsta0), and compare the failing arm with the working one. If they land on different stations/desktops, then the creator is the variable because it changed the association — and the remedy is the same root either way: keep the association the parent already holds, or make the DACL name a trustee the station admits.

Record the builds separately. On 19045 the conjunction is measured; #8721 reports 26200 failing even with Everyone, so "not measured to be identical across builds" is the honest edge rather than one rule for both.

[SteelUnion]

Same failure here, and one data point the source analysis doesn't cover.

Starting dsh web from a console-attached terminal still hit 0xC0000142.

I reproduced this on the same machine, same install, changing only the launch path:

Launch	Session policy	Result
Terminal (dsh.cmd web, console attached)	workspace-write	0xC0000142, no output
Desktop GUI (Electron, no console)	workspace-write	0xC0000142, no output
Desktop GUI	danger-full-access	works

Not a contradiction of the analysis above - most likely the other half of the conjunction (keep-alive groups / default DACL trustee). Just noting that console inheritance alone was not sufficient in my case, so "start it from a console" is not a reliable workaround to hand out.

---

Unrelated but probably saves someone an hour: even with full access enabled in Settings, the agent can still fail every command. There are two separate switches:

1. Settings ? Permissions (profile default)
2. The session-level permission toggle under the chat box

The session one is what actually governs the running session. If the agent reports permission errors or dies on pwsh while Settings clearly says full access, check the session toggle before assuming it's a bug.

This cost me several wrong hypotheses today.

[SteelUnion]

A genuine question rather than a data point, because I hit a wall the suggested arms don't address.

The three arms (cmd.exe instead of pwsh, console-attached parent, keep-alive group) all require running something, and in workspace-write I can't run anything - every pwsh call returns 0xC0000142 with no output, which is the failure being investigated. Chicken and egg: to test the sandbox I have to leave the sandbox, and leaving it changes the variable under test.

How did you collect the DACL/keep-alive measurements you quoted (the capability SID ? 0xC0000142 vs Everyone ? 0x00000000 arms)? Specifically:

1. Did you run them from a separate, non-sandboxed process on the same machine - a script outside DSH that builds the restricted token and spawns the child itself?
2. Or from inside DSH in a mode that still confines but is not workspace-write?
3. If (1), is that harness published anywhere? Reading it would be faster than rebuilding it, and it's the piece that would let someone with only a Windows box actually test these arms instead of reasoning about the source.

What I have so far, in case it's useful: starting dsh web from a console-attached terminal still failed in workspace-write on my machine, so console inheritance alone didn't flip it. That leaves the DACL/keep-alive half, which I can't test the way things stand.