Windows 沙箱下 pwsh 子进程启动即死

[17633828700]

Windows 沙箱下 pwsh 子进程启动即死（0xC0000142）：受限令牌 × 无控制台

问题报告 / Upstream bug report
报告日期：2026-10-01
涉及组件：@deepseek-ai/dsh-sandbox-windows-acl（经 dsh-sandbox-local runner 调用）
Harness 版本：0.2.0-rc.2（ProductVersion 0.2.0.0）

---

1. 摘要

在 workspace-write 沙箱模式下，面向模型的 pwsh 工具完全不可用：子进程在任何用户代码执行前即以 0xC0000142（STATUS_DLL_INIT_FAILED）终止，无 stdout/stderr。

根因（双向对照实验确立）：CreateRestrictedToken 生成的受限令牌 与 子进程无法获得控制台，两者同时成立时触发；缺任一条件即正常。沙箱路径的宿主是 Electron GUI 进程，本身没有控制台，因此沙箱 spawn 出的每个控制台程序（pwsh、node、cmd.exe）都在受限令牌下死于 DLL 初始化。

该机制不受 TEMP/TMP 环境变量、临时目录权限、CreateRestrictedToken 具体标志位组合的影响——这三者均已实验排除。

---

2. 环境

项	值
OS	Windows 11 25H2
用户	管理员账户（High 完整性）
Harness	0.2.0-rc.2，安装于 C:\Users\Like\AppData\Local\Programs\DeepSeek Harness
PowerShell	7.6.6（C:\Program Files\PowerShell\7\pwsh.exe）
沙箱模式	workspace-write

---

3. 复现

任意命令，包括最简形式：

Get-ChildItem env:DSH_*        # → 无输出，[exit code: 3221225794]
echo hello                     # → 无输出，[exit code: 3221225794]
$PSVersionTable.PSVersion      # → 无输出，[exit code: 3221225794]

3221225794 = 0xC0000142 = STATUS_DLL_INIT_FAILED。同会话切换到 danger-full-access 后，同一命令立即成功。

---

4. 核心实验

4.1 实验装置

以 CreateProcessAsUserW 复刻沙箱的 spawn 参数，令牌按源码构造：

CreateRestrictedToken(
  currentToken,
  flags = 13,                        // DISABLE_MAX_PRIVILEGE | LUA_TOKEN | WRITE_RESTRICTED
  restrictingSids = [ <登录 SID>, S-1-1-0 (Everyone) ]   // 即文档所述"保活组"
)
SetTokenInformation(TokenIntegrityLevel, S-1-16-4096)    // Low

spawn 参数与生产一致：匿名管道 stdio、STARTF_USESHOWWINDOW + SW_HIDE、bInheritHandles = TRUE。

4.2 结果矩阵 ★

父进程控制台	令牌	程序	exit code	stdout	判定
无	受限(13)+Low	pwsh 7.6.6	0xC0000142	空	死
无	受限(13)+Low	node	0xC0000142	空	死
无	受限(13)+Low	git-bash	0xC0000142	空	死
有	受限(13)+Low	pwsh 7.6.6	42	STDOUT_MARKER	正常
有	受限(13)+Low	node	42	NODE_MARKER	正常
有	受限(13)+Low	git-bash	0xC0000142	couldn't create signal pipe, Win32 error 5	死（不同原因，见 §7）

4.3 双向对照：两个条件缺一不可

令牌	控制台	pwsh 结果
原始	无	✅ 42
受限	有	✅ 42
受限	无	❌ 0xC0000142
原始	有	✅ 42

结论：受限令牌是必要非充分条件；无控制台是必要非充分条件；两者同时成立才失败。

4.4 排除标志位假设

固定"无控制台"，逐一测试令牌标志：

flags	含义	结果
0	restricting 列表 only	0xC0000142
1	DISABLE_MAX_PRIVILEGE	0xC0000142
4	LUA_TOKEN	0xC0000142
8	WRITE_RESTRICTED	0xC0000142
13	生产实际组合	0xC0000142
13 + Low	+ 降完整性	0xC0000142
0 + Low	+ 降完整性	0xC0000142

→ 与标志位组合、与完整性级别均无关。

4.5 修复验证

在 spawn 前于中间进程调用 AllocConsole()，同一受限令牌下：

程序	修复前	修复后
pwsh	0xC0000142	✅ 42，stdout 正确
node	0xC0000142	✅ 42，stdout 正确
cmd.exe	0xC0000142	✅ 42

有控制台时，各创建标志的表现：

创建方式	结果
无标志	✅ 42
STARTF_USESHOWWINDOW + SW_HIDE（DSH 现用）	✅ 42
CREATE_NO_WINDOW	❌ 0xC0000142
CREATE_NEW_CONSOLE	❌ 0xC0000142
DETACHED_PROCESS	⚠️ exit 0 但命令未执行（副作用验证：marker 未创建）

---

5. 排除项：与 TEMP/TMP 和临时目录权限无关

假设	实测
用户变量 TEMP/TMP 未指向用户临时目录	HKCU\Environment 原始值已是 %USERPROFILE%\AppData\Local\Temp，类型 REG_EXPAND_SZ，且解析正确
临时目录不存在	C:\Users\Like\AppData\Local\Temp 存在
降权后无法访问临时目录	该目录 ACL 含 OMEN-MAX\Like : FullControl，用户 SID 在 DACL 中；Harness 自身持续向该目录写入 dsh-* 工作目录

决定性反证：cmd.exe 在受限令牌 + 无控制台下同样以 0xC0000142 死亡（§4.2），而 cmd.exe 启动不依赖临时目录或任何环境变量。此外 0xC0000142 发生在映像加载（DLL 初始化）阶段，早于进程读取环境变量——把 TEMP 指向何处对该故障无因果影响。

注：改动 TEMP 不仅无效，若把 REG_EXPAND_SZ 误写成 REG_SZ，反而会丢失变量展开能力。

---

6. 与包内文档表述的差异

包内 README 与 asar 注释把原因归于两个创建标志：

Console isolation is unavailable — children created with CREATE_NO_WINDOW / CREATE_NEW_CONSOLE die during DLL initialization with STATUS_DLL_INIT_FAILED (0xC0000142); children share the host console, and pipe-based stdio redirection is unaffected.

而另一处注释（asar，offset 68038223）又说明实现已刻意回避这两个标志：

Process creation sets STARTF_USESHOWWINDOW with SW_HIDE … It preserves console inheritance and does not add CREATE_NO_WINDOW or CREATE_NEW_CONSOLE, which can fail DLL initialization under the restricted token.

实测表明该表述不完整：即使完全不使用这两个标志，只要宿主进程无控制台，受限令牌下子进程仍然 0xC0000142（§4.2、§4.3）。

"children share the host console" 这一前提在 Electron GUI 宿主上等价于 share a non-existent console——GUI 宿主自身没有控制台（本次 AttachConsole 探测：ERROR_INVALID_HANDLE，与 explorer.exe 一致）。这使 §4.5 中 SW_HIDE 方案的"保留控制台继承"设计意图落空：被继承的是一个不存在的控制台。

证据边界（如实标注）：本次直接验证的是"受限令牌 × 子进程无控制台 → 0xC0000142"这一因果对（§4.2–4.5，多轮可复现）。至于"宿主 Electron 进程究竟在何处失去控制台"以及"沙箱子进程确切的继承链"，未能以运行时手段逐步跟踪——受限模式下 pwsh 无法启动，无法在内层观测。另有一处未解释的矛盾：本次会话的 pwsh 工具自身 GetConsoleWindow() 为非空且 GetConsoleProcessList() = 1（独占控制台），而 AttachConsole 探测显示父进程链上各进程均无控制台。两者并存可能源于工具路径与沙箱路径的控制台处理不同（如 ConPTY 伪控制台对 AttachConsole 不可见），此点未经独立验证。

---

7. 附带发现：Git for Windows / MSYS 在受限令牌下有第二个独立障碍

git-bash 即使在有控制台的条件下仍然失败，且失败签名与 pwsh 不同：

0 [main] bash (10748) cygheap_user::init: NtSetInformationToken (TokenDefaultDacl), 0xC0000022
577 [main] bash (10748) ...\usr\bin\bash.exe: *** fatal error - couldn't create signal pipe, Win32 error 5

即 MSYS 运行时的 NtSetInformationToken(TokenDefaultDacl) 被拒（0xC0000022 = STATUS_ACCESS_DENIED），继而无法建立信号管道。这意味着修好控制台问题并不足以让 Git Bash 在受限令牌下可用，需要另开 issue 或单独处理。

---

8. 建议修复方向

8.1 上游（推荐）

在受限令牌下 spawn 控制台程序时，确保子进程获得一个控制台，而不是依赖继承（宿主为 GUI 进程时该继承源不存在）。本次实验证明下列方向可行：

• 在 spawn 中间进程调用 AllocConsole()，再让受限令牌子进程继承（§4.5 已验证 pwsh/node/cmd 全部恢复）；
• 或改用 ConPTY（伪控制台）承载沙箱会话。

8.2 明确不可用

• CREATE_NO_WINDOW / CREATE_NEW_CONSOLE：有控制台时仍致死在受限令牌下（§4.5）；
• DETACHED_PROCESS：静默失败——退出码 0 但命令从未执行（§4.5），比崩溃更危险，会伪装成成功。

8.3 失败应结构化上报

当前故障以裸退出码 3221225794 暴露。建议参照既有 SANDBOX_UNAVAILABLE 模式，让"受限令牌下子进程 DLL 初始化失败"成为可识别的结构化错误，避免调用方反复重试注定失败的调用，也避免被误诊为"PowerShell 安装损坏"。

8.4 文档更正

建议修正 README 中"Console isolation is unavailable"一段：把触发条件从"使用了 CREATE_NO_WINDOW/CREATE_NEW_CONSOLE"更正为"受限令牌下子进程未能获得控制台"，并说明 GUI 宿主场景下这是默认状态。

8.5 用户侧临时手段

会话内逐命令提权到 danger-full-access（本次已验证 pwsh、node、git 均可正常执行）。

---

9. 证据索引

用途	位置
沙箱受限令牌构造（flags=13）	…\@deepseek-ai\dsh-sandbox-windows-acl\lib\types-Cl_DXjhk.js:893
控制台失败相关注释	同上 :1170-1172
TMP/TEMP 重写逻辑	同包 lib\runner.js:154-155
STARTF_USESHOWWINDOW/SW_HIDE 说明	…\resources\app.asar offset 68038223
沙箱 spawn 入口	types-Cl_DXjhk.js:1327（spawn()）→ spawnPipedProcess

---

10. 声明

本报告的全部实验均在进程外进行（受限模式下 pwsh 自身无法启动，观测通道即故障对象）。实验仅创建受限令牌并 spawn 子进程，未修改任何注册表项、环境变量或系统设置。

[491196907]

是自己选了安装位置吗，如果是的话重新安装，用默认位置，和我昨天的情况一样

[yfhaotian]

装在什么地方呢？默认安装位置是在这里C:\Program Files\PowerShell\7 问题依旧，有没有解决帮办法？

[491196907]

先确定两件事情，第一件事情不用桌面端，用web端能不能正常使用，如果能正常用，告诉web端你的情况，他会带着你修，第二件事情使用其他的agent会不会出现这种情况，如果不会，就下载workbuddy这种来帮你修复
之前我碰到这个问题就是这样子解决的，我的ds也说是bug导致的，要官方维修，但我一想可能性不大啊，不至于这种功能都没有，这种恶性bug有的话社区应该全部是这个问题了

[17633828700]

位置没错，应该是win系统的问题

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年10月10日(周六) 晚上10:18 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [deepseek-ai/deepseek-harness] Windows 沙箱下 pwsh 子进程启动即死 (Discussion #8535) 装在什么地方呢？默认安装位置是在这里C:\Program Files\PowerShell\7 问题依旧，有没有解决帮办法？ — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[yfhaotian]

昨晚 AI 自己分析是 DeepSeek Harness 的 bug 等官方修复。

[argszero]

Your two-way control is the right shape, and its conclusion holds: a restricted token and a console-less host are each necessary but not sufficient, and only together do they kill the child during loader init with 0xC0000142 (STATUS_DLL_INIT_FAILED) before any user code runs. Your §4.4 also correctly rules out the token flag combination as the cause — that is the part most reports in this family get wrong.

Three facts from inside the harness explain why you only ever see a bare NTSTATUS, plus one caveat that matters before you name a cause.

1. Why the code is never classified as an error. packages/sandbox/sandbox-local/src/index.ts maps each runner to failure rules, and RUNNER_FAILURE_RULES['windows-acl'] accepts exactly one exit code — WINDOWS_ACL_RUNNER_FAILURE_EXIT = 127 — plus the stderr signature windows-acl-run: . 0xC0000142 matches neither, and packages/sandbox/sandbox/src/diagnostics.ts skips the stderr scan (continue) as soon as the exit code is not in allowedExitCodes, before any signature could match. So this never becomes a runner failure: no SandboxUnavailableError, no diagnostic, no error state. It passes through as an ordinary non-zero exit, and tool-pwsh/src/render.ts states that policy outright — "non-zero exits are reported, not errored". That is structural, not a missing line of copy, and it is why the row reads as a raw exit code only.

2. Why the console is the second half. A restricted token can inherit a console but cannot create one. The packaged desktop host is a GUI-subsystem process, so nothing in its tree owns a console object to hand down, and every console program started under the restricted token fails during DLL initialization. Your own matrix is that fact from three sides at once: the program dies with no console and lives with one, the same build started from a console (dsh web) is fine, and danger-full-access is fine.

3. read-only is the first step of the discriminator, not a workaround. Comparing the same command under read-only (alive) and workspace-write (dead) does isolate the restricting-list branch — sandbox-windows-acl/src/token.ts::createRestrictedToken passes [logonSid, world] in read-only and [logonSid, world, ...writeSids] in workspace-write. But read-only also costs you PowerShell's constrained-language posture, so it is a diagnosis rather than a fix.

The caveat: 0xC0000142 alone does not name one cause. The same source records the opposite direction of the same status — too few restricting entries (a missing logon SID plus the EVERYONE keep-alive group) dies with the same code. So the status only gets you to "native initialization failed"; the mode split is what narrows which condition produced it, and for the runner-side branch the discriminator is whether a windows-acl-run: line appears in stderr at all. Worth stating that in a report rather than concluding a single cause from the code.

These cases are collected in the diagnostic plugin @argszero/cordis-plugin-sandbox-grant-advisor@0.18.0 — npm i @argszero/cordis-plugin-sandbox-grant-advisor, source https://github.com/argszero/cordis-plugin-sandbox-grant-advisor (MIT). It recognises this family (native-init) from the symptom and hands back exactly the two-step discriminator above — the mode split first, the startup-chain/console axis second, with the read-only cost stated and the "the status code alone cannot name the cause" boundary kept. It changes nothing about the sandbox or the policy; it only answers "which of my two conditions is the one that applies".

[17633828700]

用codex修过，但是只是临时解决方案，确实是dsh的问题，桌面端和web端是不同的逻辑，其他工具的pwsh是正常的，codex，reasonix都是正常的。目前已经通过重装系统解决。可以肯定是系统版本问题。

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年10月12日(周一) 上午9:18 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [deepseek-ai/deepseek-harness] Windows 沙箱下 pwsh 子进程启动即死 (Discussion #8535) 先确定两件事情，第一件事情不用桌面端，用web端能不能正常使用，如果能正常用，告诉web端你的情况，他会带着你修，第二件事情使用其他的agent会不会出现这种情况，如果不会，就下载workbuddy这种来帮你修复 之前我碰到这个问题就是这样子解决的，我的ds也说是bug导致的，要官方维修，但我一想可能性不大啊，不至于这种功能都没有，这种恶性bug有的话社区应该全部是这个问题了 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[paperbluster]

dsh 不要使用完全权限之外的模式，目前遇到多次把项目的acl还是啥权限等级降低导致正常启动在这个windows电脑无效，因为windows对应用启动有权限设计的，如果是自己用node项目封装dsh web，这个问题很容易导致node项目本体都打不开

[17633828700]

完全权限正常，沙箱模式不行Windows权限导致pwsh启动既死。封装插件绕过可以，但是沙箱外写入删除扔有风险

…

---原始邮件--- 发件人: ***@***.***> 发送时间: 2026年10月12日(周一) 上午10:58 收件人: ***@***.***>; 抄送: ***@***.******@***.***>; 主题: Re: [deepseek-ai/deepseek-harness] Windows 沙箱下 pwsh 子进程启动即死 (Discussion #8535) dsh 不要使用完全权限之外的模式，目前遇到多次把项目的acl还是啥权限等级降低导致正常启动在这个windows电脑无效，因为windows对应用启动有权限设计的，如果是自己用node项目封装dsh web，这个问题很容易导致node项目本体都打不开 — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>