[Windows] 「工作区内修改」档下 pwsh 无法启动（exit 0xC0000142）—— 受限令牌下 .NET 程序初始化失败

[Void-LifeStream]

概要

在 Windows 上把权限档切到「工作区内修改」（workspace-write + ask）后，任何 pwsh 调用都会立即死亡：
没有任何输出，退出码 3221225794（= 0xC0000142 = STATUS_DLL_INIT_FAILED）。

⇒ 结果是该档在 Windows 上对需要跑 shell 的 agent 完全不可用 —— 用户只能退回 danger-full-access
（零沙箱），这与该档"更安全"的设计意图正好相反。

环境

• 宿主：Windows 11 x64 · DSH Desktop 0.2.0-rc.2
• PowerShell：7.6.7（Store/MSIX 版与 MSI 版都复现 —— 见下）
• 档位：workspace-write + ask

复现

1. 把权限档切到「工作区内修改」；
2. 让 agent 执行任意 pwsh 命令（哪怕只是 $PSVersionTable.PSVersion）；
3. 观察：无输出，exit code 3221225794。

已排除的变量（逐项实测）

变量	结果
pwsh 版本太老	❌ 7.6.7 一样死
Store/MSIX 版特有	❌ 换成 MSI 版（C:\Program Files\PowerShell\7\pwsh.exe）一样死
安装位置 / PATH 顺序	❌ 重启宿主让 PATH 刷新、确认已解析到 MSI 版后，一样死
Store 版残留干扰	❌ 卸载 Store 版后，一样死

⇒ 与 PowerShell 侧完全无关（版本 / 打包形式 / 安装位置全部排除）。

定位（读 app.asar 内该沙箱包的 Windows 进程原语注释得到）

• 沙箱实现 = 受限令牌（restricted token）+ CreateProcessAsUserW + 私有 temp SID + null 环境块
  （注释原文：the runner rewrites TMP/TEMP in its OWN environment to the private directory before spawning；
  pass a null environment block … because an explicit block through Koffi fails with ERROR_INVALID_PARAMETER）
• 错误码 = SANDBOX_UNAVAILABLE（SandboxUnavailableError；执行期失败时追加 Runner failure: <detail>）

推断：CreateProcessAsUserW 不会为用户加载注册表配置单元（那需要 LoadUserProfile），
而受限令牌的 SID 集合又与 HKEY_USERS\<SID> 对不上 ⇒ .NET 运行时在初始化阶段失败 ⇒ 0xC0000142。

另一条相关错误（供参考）

sandbox mode "workspace-write" is requested but no sandbox backend is usable on this host;
refusing to run the command unconfined. Runner failure: windows-acl-run:
CreateProcessAsUserW failed (Win32 2): command: C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe,
cwd: <workspace>

Win32 2 = ERROR_FILE_NOT_FOUND —— 那是卸载 Store 版之后出现的：工具使用的路径来自
宿主进程启动时的 PATH 快照，而那个 Store 别名（App Execution Alias）已经不存在了。

建议

1. 为受限令牌加载用户配置（LoadUserProfile）或放宽令牌（保留 SeChangeNotifyPrivilege 等基本特权），
   让 .NET 类程序能够完成初始化；
2. 若短期不修：在档位说明 / 文档里明确写出「Windows 的 workspace-write 档下 .NET 类程序（如 pwsh）不可用」——
   否则用户会以为是自己环境坏了（我们为此排查了两轮，还换装了一次 pwsh）；
3. 顺带：pwsh 工具的路径解析若能在每次调用时刷新（而不是沿用宿主启动快照），会更稳。

附：一个尚未验证的推论

该档可能并非完全不可用 —— 简单原生 exe（如 cmd.exe /c echo hi）也许能跑，
只有 .NET 类程序会死。若需要，我们可以补一次实测。

[argszero]

The source supports your inference in one direction, and rules out one of its variables

I read the sandbox package at the current head (86a40220). Two facts there bear directly on your diagnosis.

What the code does confirm

The runner never loads a user profile. LoadUserProfile appears nowhere in packages/sandbox/sandbox-windows-acl — not in src, not in the bindings table, and neither does CreateProcessWithLogonW. The call in use is CreateProcessAsUserW (win32-abi.ts:5 names the token right it needs; runner.ts:37 documents its behaviour). So your suggestion 1 is a genuine implementation change rather than a setting someone forgot to flip: the platform call that would populate HKEY_USERS under the restricted token is simply not made, and the restricted SID set is exactly what CreateRestrictedToken produced.

Your quotation of the environment handling is accurate. runner.ts:34-37:

In both flows the runner rewrites TMP/TEMP in its OWN environment to the private directory before spawning; the child inherits that block (lpEnvironment NULL; an explicit block through koffi trips ERROR_INVALID_PARAMETER in CreateProcessAsUserW, verified empirically).

That single sentence explains two of your observations at once. The null environment block is why the child inherits the runner's environment rather than a fresh one; and because the runner is spawned by the host process, the PATH it hands down is the host's own — which is exactly the snapshot behaviour behind your Win32 2 case after the Store alias was uninstalled. Your third suggestion (refresh pwsh's path per call rather than per host) is the right remedy for that half, and it is independent of everything else here.

What it does not settle

The absence of LoadUserProfile shows the remedy is not already present; it does not show that registry availability is what fails. 0xC0000142 is STATUS_DLL_INIT_FAILED, and a loader failure has more than one cause that a restricted token can produce — a missing hive is one, and a privilege the runtime's initialisation needs is another. I would not settle it from the source. But it does mean your two candidate remedies name the same variable from opposite ends, and either one would discriminate: making the profile call and seeing the failure disappear is as informative as relaxing the token.

On your 附 — the axis is probably the wrong one

There is a same-day report from a different host that bears on this, and it argues against reading 0xC0000142 as a .NET signature. In that report (cmd.exe, where.exe, whoami.exe — none of them .NET) fail with the same 0xC0000142 when their stdio is captured, while the same commands run fine when output goes straight to the terminal. Two reports, one error code, two different conditions:

condition that fails	report
the program is .NET (pwsh), piped or not	this one
the program is native, but its stdio is captured	the other one

Your proposed experiment — "a simple native exe probably runs; only .NET programs die" — will very likely pass, but it will not isolate the cause, because the condition you would run it under (no piping) is the condition under which even the native failures go away. To make it discriminating, run the native executable both unpiped and piped under the same mode. If unpiped works and piped dies, then "which runtime the program uses" is not the variable and the answer lies in the token/pipes plane; if both work while pwsh still dies on both, then the .NET half of your inference is confirmed and stands on its own.

That distinction is worth having before the fix is scoped, because the two planes have different owners: the pipe half is the default-DACL grant, the loader half is the token's profile and privilege set.

I have not run this on Windows, so every measurement here is yours; what I verified in the tree is the absence of any profile-loading call in the package, the CreateProcessAsUserW call site, and the comment describing the rewritten TMP/TEMP and the null environment block.

[argszero]

Addendum — a measured candidate mechanism for this exact error code, and the arm the shipped code is on

I want to add one thing to my comment above rather than let it stand as if LoadUserProfile were the only lead. There is a measured cause for 0xC0000142 in this sandbox, on this same shipped version, and the arm it identifies as the failing one is the arm the code is currently on.

What was measured, and where

A community reporter supplied it in the issue tracker of a plugin repository of mine, with the scripts they used to obtain it: argszero/cordis-plugin-sandbox-grant-advisor, issue #1, comment carrying the arm table. Environment: Windows 10 22H2 build 19045, elevated Administrator token, DSH Desktop 0.2.0-rc.2, @deepseek-ai/dsh-sandbox-windows-acl 0.2.0-rc.2, and — the load-bearing detail — the mediating process is the packaged GUI-subsystem DeepSeek Harness.exe, measured GetConsoleWindow() = null.

They patched exactly one call in the shipped runner (setTokenDefaultDaclGrant) through a module-loading hook and held everything else fixed — restricting SID list, Low-integrity step, write grants, TEMP handling, command line, workspace:

default-DACL ACE names	mediator	result
the capability (temp) SID	GUI, no console	0xC0000142
Everyone	GUI, no console	0x00000000
capability SID + Everyone	GUI, no console	0x00000000
the capability (temp) SID	GUI, AllocConsole() first	0x00000000
the capability (temp) SID	console node.exe	0x00000000
the capability (temp) SID	GUI, no console — dropping the restricting SIDs or Low IL instead	0xC0000142 (unchanged)

Their reading: on that build the failure is the conjunction of (no console) and (a default DACL naming no universally-held trustee) — either arm alone recovers. Their Arm B dump (from inside the confinement) shows the merge extends the ambient default DACL rather than replacing it; the four entries are the merged Everyone ACE plus ambient Administrators, SYSTEM and the logon SID.

Why this lands on your report

packages/sandbox/sandbox-windows-acl/src/index.ts:304 is, verbatim:

      setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid)

and in workspace-write with a private temp root the temp SID is not optional — :208-209 throws if the caller did not derive one. So on the desktop form the merged ACE names the synthetic capability SID, with Everyone never reached. That is the first row of the table above. Your environment is the same shape as the one measured: the desktop form of 0.2.0-rc.2, a GUI process, workspace-write, and a child that dies in the loader.

I am not claiming that this is your cause — your build is not 19045, and the reporter explicitly warned against folding builds together, because a separate report has 26200 failing even with Everyone in place. What I am claiming is that it is a cheaper hypothesis to test than the profile one, because the discriminating observation is a read rather than a code change.

The experiment that separates them

Dump the restricted child's own default DACL — GetTokenInformation(TokenDefaultDacl) from inside the confinement, which needs no patch — and check which trustees are named. Then compare the two arms the table above separates:

1. Correlate. If your host reproduces with the capability SID named and recovers when the ACE names a universally-held trustee (or when the mediator has a console), the profile hypothesis is not needed and LoadUserProfile would have been a change that fixed nothing.
2. If both arms still fail, the profile/privilege plane is back in play, and that arm of your report stands.

The AllocConsole() row is worth keeping for a second reason: it is the cheapest of all the arms (no SID change, no patch to the grant) and it is a pure host-side difference — so a Desktop build that has a console, or a headless one, would behave differently from the GUI form without anything in the sandbox changing.

One caveat on my own earlier comment

I wrote that the absence of any LoadUserProfile call "shows the remedy is not already present". That still holds, and it is not evidence for that remedy being the cause. Reading the two together: the source tells you the profile call is absent, the measurement tells you a different and already-identified variable produces the identical exit code on a console-less host of the same version. Ordering the experiments by cost, the DACL dump comes first.

I did not run any of this; every measurement above is the reporter's, and what I verified in the tree is the call site that selects the SID, the requirement that a temp SID be derived in your mode, and the comment describing the merge as extending the ambient default DACL.

[Void-LifeStream]

Measured on our host: the runtime is the variable — not stdio capture

Thanks for reading the tree. Both of your points landed, and one of them corrected me.

What we measured (same host, same mode, minutes apart)

Mode: the «workspace-write» preset (workspace-write + ask).

executor	runtime	stdio	result
the agent's pwsh tool	.NET 7.6.7	captured	(no output), exit 3221225794 (0xC0000142)
cuda_run → python.exe	CPython 3.13.11	captured (stdout collected by the job)	exit 0, printed ALIVE 3.13.11 CPython

Both children were launched from the same session, on the same host, in the same mode — that part is
observed. That they also went through the same runner under the same restricted token is our
inference, not something we verified separately (⚠️ flagged rather than asserted).
Non-child tools (read / write / edit — they do not spawn a process) also keep working in that mode.

What this settles — and what it does not

1. The runtime is the variable here. The two rows differ only in runtime; one dies, the other runs.
2. "stdio captured" is not the answer on this host. Row 2's stdout was captured as well — and it lived.
   So the concern that we would pick the unpiped condition and therefore "pass without discriminating"
   does not bind here: native + pipe is alive on our box.
3. The cheaper hypothesis you added — the default DACL naming the synthetic capability SID, conjoined with
   a console-less mediator — is pushed down on our host, because CPython shares that very restricted token
   and it runs. ⚠️ That is not a claim the 19045 measurement is wrong; you warned against folding builds
   together, and this is a case of exactly that. That mechanism simply does not look like ours.
4. Still unresolved: "missing hive" vs "missing privilege". Both can produce a loader failure; our probe
   only separates the runtime layer. Going one level deeper needs GetTokenInformation inside the
   confinement — and the honest reason we stopped here is in the next section.

A methodological point that cost us a redesign

Your suggested experiment (run a native exe piped and unpiped, same mode) cannot be issued on our host
as written: the agent's only command channel is pwsh, and in that mode pwsh itself dies first —
so "run cmd.exe as the control" never leaves the gate. The control would have to be launched through the
very thing that is broken.

The observer sits on the same plane as the subject. We only got row 2 by using a channel that does not go
through pwsh at all (cuda_run). For anyone reproducing this on a Desktop build, that may be worth knowing:
"I cannot run the control" is itself a datum — and it points straight at the plane.

Reproduction recipe

1. Switch DSH's permission preset to «workspace-write» (workspace-write + ask).
2. Issue any pwsh command through the agent ⇒ expect (no output) + exit 3221225794.
3. Run cuda_run with print("ALIVE") ⇒ expect exit 0 and real output.
   ⚠️ Switching to that mode kills pwsh for every session on the host, not just one — switch back right after.

Why we are not going further ourselves

We can only measure from inside the confinement, and the instrument we would need is a .NET tool —
i.e. the thing that is dead. If someone can run a native probe that dumps GetTokenInformation(TokenDefaultDacl)
and the token's privilege set from inside this sandbox, that would separate the last two candidates.
We would rather say that plainly than guess.

Full evidence, including everything we did not manage to separate:
E:\DeepSeek Harness\Infrastructure\sandbox-plane-probe-结果.md (Chinese; the table above is the whole of it).

[Void-LifeStream]

Correction (2026-10-17): our ".NET" hypothesis is falsified — and @argszero called it in advance

Short version: the claim in our 附 ("native exe probably runs; only .NET dies") is wrong, and
suggestion 1's LoadUserProfile half is not the fix. A later report (#10010) measured the actual
pair of conditions. We are writing this down instead of quietly editing, because the mistake is instructive.

What we got wrong

We ran the experiment we had proposed: under workspace-write, pwsh died (0xC0000142) while a
native program (CPython, via our GPU tool) ran fine. We read that as confirmation.

It wasn't. Our two data points did not go through the same runner — the GPU tool does not use the
sandbox runner path at all. We had flagged that as an unverified inference in our own notes, and then
drew the conclusion anyway. That is exactly the failure mode @argszero predicted:

"a simple native exe probably runs; only .NET programs die — will very likely pass,
but it will not isolate the cause."

A control group that isn't on the same runway can't discriminate. The variable we thought we were
toggling (runtime) was confounded with the one we didn't control (which launch path the process took).

What actually happens (per #10010, measured; we have not independently reproduced it)

Two conditions must hold together:

1. the packaged desktop build uses process.execPath — the GUI-subsystem DeepSeek Harness.exe — as the
   runner host ⇒ that process has no console to inherit;
2. the restricted token's default DACL gets only the capability/temp SID merged in, not Everyone.

With both true the loader fails ⇒ 0xC0000142. This also explains the observation that started all of
this: read-only works on the same host, because that branch merges worldSid (Everyone) instead.

Their console experiment is the design we should have used: same runner, same token, only
AllocConsole() toggled — and then AllocConsole() + FreeConsole() again, to prove it is the state
at spawn time rather than a side effect.

Status of our original suggestions

our suggestion	status
1a. call LoadUserProfile	❌ not the fix — native exes die too, so a missing registry hive is not necessary
1b. relax the token	✅ directionally right — merging Everyone into the default DACL is the other half (with a security trade-off to be weighed)
2. document ".NET programs unavailable under workspace-write"	⚠️ scope too narrow — it is any child process, not only .NET; and it now has a user-side workaround
3. refresh pwsh's path per call	✅ still valid, and independent of everything above

⚠️ We have not reproduced #10010 ourselves. We are citing it as a better-dated measurement with a
concrete probe, not as a verified root cause. If it fails to reproduce, this correction is wrong too —
and we would rather say that here than repeat the mistake of over-claiming from a single host.

Thanks to @argszero for the axis correction (we should have taken it the first time), and to the
#10010 author for doing the measurement and publishing the probe.