pwsh 工具在 workspace-write 下以 0xC0000142 死亡：受限令牌 + 控制台隔离标志

[lks169]

pwsh 工具在 workspace-write 下以 0xC0000142 死亡：受限令牌 + 控制台隔离标志

**English title:** pwsh tool dies with STATUS\_DLL\_INIT\_FAILED (0xC0000142) under workspace-write — ACL restricted token combined with a console-isolating process-creation flag

**⚠️ 提交渠道（已核实，勿用 issues）：** 该仓库 **GitHub Issues 已关闭**（API 返回 has\_issues: false、open\_issues\_count: 0），故 /issues/new 不可用。
请提交到 **GitHub Discussions**：https://github.com/deepseek-ai/deepseek-harness/discussions
并建议**同时**使用应用内 /feedback（会释放完整会话日志前缀）。
**建议标题：** \[Windows] pwsh tool fails with 0xC0000142 (STATUS\_DLL\_INIT\_FAILED) under workspace-write — ACL restricted token + console-isolating creation flag
**建议标签：** windows / sandbox / shell / bug
**版本：** 0.2.0-rc.2 (win-x64)
**状态：** **根因已由受控实验定位**（见下方"最小触发条件"）

---

结论（TL;DR）
在 Windows 上，ACL 受限令牌（WRITE\_RESTRICTED + Low 完整性）与 CREATE\_NO\_WINDOW 或 CREATE\_NEW\_CONSOLE 这两个进程创建标志同时出现时，目标 shell 必以 STATUS\_DLL\_INIT\_FAILED（0xC0000142）在 DLL 初始化阶段死亡、零输出。
单独任一条件都不致命：

受限令牌  {logon SID, Everyone} + Low  +  标志=0                 ->  OK
受限令牌  {logon SID, Everyone} + Low  +  CREATE\_NO\_WINDOW       ->  FAIL 0xC0000142
无限制令牌                              +  CREATE\_NO\_WINDOW       ->  OK

dsh-sandbox-windows-acl 的 README 已经写明这条限制：

*"**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."*
而 dsh-win32-process 的 README 也声称该原语已经规避了它：
*"It preserves console inheritance and **does not add CREATE\_NO\_WINDOW or CREATE\_NEW\_CONSOLE**, which can fail DLL initialization under the restricted token."*
但实测的失败特征与该限制完全吻合，说明受限路径上仍有一处把控制台隔离标志传了下去。可疑点：dsh-jobs 用 windowsHide 启动 Windows 子进程（Node 把 windowsHide: true 映射为 CREATE\_NO\_WINDOW），与 dsh-win32-process 的承诺不一致。

---

最小触发条件（受控实验）
目标固定为 C:\\Program Files\\PowerShell\\7\\pwsh.exe（7.6.6），宿主为 High 完整性进程，令牌由 CreateRestrictedToken + SetTokenInformation(TokenIntegrityLevel) 构造，进程由 CreateProcessAsUser 创建。
矩阵 A — 令牌 × 创建标志（决定性）
令牌 创建标志 结果
无限制 0（继承控制台） ✅ OK
无限制 CREATE\_NO\_WINDOW ✅ OK ← 该标志单独无害
受限 {logon, Everyone} + Low 0 ✅ OK
受限 {logon, Everyone} + Low CREATE\_NO\_WINDOW ❌ FAIL 0xC0000142
受限 {logon, Everyone} + Low CREATE\_NEW\_CONSOLE ❌ FAIL 0xC0000142
受限 {logon, Everyone} + Low DETACHED\_PROCESS ✅ OK
受限 {logon, Everyone} + Low CREATE\_NEW\_PROCESS\_GROUP ✅ OK
受限 {logon, Everyone} + Low 0 + STARTF\_USESHOWWINDOW+SW\_HIDE ✅ OK ← DSH 实际的窗口隐藏写法无罪
矩阵 B — restricting 列表宽度 × Low 完整性
restricting SIDs Low 结果
无（普通令牌） ✗ ✅ OK
无（普通令牌） ✓ ✅ OK ← Low 完整性单独无害
{S-1-1-0}（仅 Everyone） ✓ ❌ FAIL 0xC0000142
{logon SID, S-1-1-0}（DSH 文档所述） ✓ ✅ OK
{Everyone + Authenticated Users + Users + Administrators + SYSTEM + Interactive + Local + ConsoleLogon + LocalService + NetworkService}（不含 logon SID） ✓ ✅ OK ← logon SID 并非唯一必需
矩阵 C — 其它被排除的变量
变量 结果
宿主进程无控制台（以 CREATE\_NO\_WINDOW 启动自身副本，GetConsoleWindow() = 0）后，受限 + 标志=0 ✅ OK ← 父进程控制台状态无关
DISABLE\_MAX\_PRIVILEGE ✅ OK
把 logon SID 放进 SidsToDisable ✅ OK
powershell.exe 5.1（.NET Framework）替代 pwsh 7 ❌ 同样 FAIL（与 shell 版本无关）
cmd.exe（非 .NET） ✅ OK

由此确立的因果链
会话沙箱模式为 workspace-write → dsh-sandbox-windows-acl 为子进程构造 WRITE\_RESTRICTED + Low 完整性令牌。令牌本身是正确的：受控复刻该令牌后，pwsh 7 与 5.1 均能正常启动。
受限路径在创建该子进程时额外传入了控制台隔离标志（CREATE\_NO\_WINDOW 或 CREATE\_NEW\_CONSOLE）。
在 WRITE\_RESTRICTED 令牌下，这两个标志所要求的控制台初始化会执行写类访问检查；restricting SID 列表无法副署该写权限 → 控制台初始化失败 → 早期 DLL 初始化以 0xC0000142 死亡，进程零输出。
失败既非 runner 失败（无 windows-acl-run: stderr 签名、非退出 127），也非策略拒绝，因此工具层无法分类，用户只看到一个裸退出码。
为什么不是每台机器都复现： 第 3 步的写检查取决于目标控制台对象的 DACL 与 restricting 列表的交集。本机（Windows 11 25H2 / Build 26200，企业安全基线）上 {Everyone} 不足以通过而 {logon SID, Everyone} 可以——DACL 一旦再收紧或列表再变窄，就会落到失败侧。

建议修复
a.（核心）受限路径绝不传控制台隔离标志，并补一道断言
确保受限子进程的创建标志中永不含 CREATE\_NO\_WINDOW / CREATE\_NEW\_CONSOLE，只允许 0、DETACHED\_PROCESS 或 CREATE\_NEW\_PROCESS\_GROUP。dsh-win32-process 的 README 已给出该承诺，但实测说明承诺未在整个受限链路上兑现——重点核查 dsh-jobs 的 windowsHide（Node 将其映射为 CREATE\_NO\_WINDOW）是否泄漏到了受限目标的创建调用上。
建议在受限 spawn 前加断言：若标志集合包含这两个位，直接以明确的内部错误失败，而不是让子进程静默死掉。
b.（必做）识别该退出码
把 3221225794 / 0xC0000142（STATUS\_DLL\_INIT\_FAILED）纳入工具层失败分类，与 runner 失败签名和策略拒绝区分开，映射到专门文案。目前它落在所有分类之外，是"完全无提示"的直接原因。
c.（必做）启动时可服务性探测
在受限模式下做一次一次性探测；若受限 shell 无法启动，则以类似 SANDBOX\_UNAVAILABLE 的可操作错误失败（提示改用 danger-full-access 或上报）。既然当前没有任何用户侧安装动作能修复本问题，这一探测是避免用户陷入死胡同的唯一机制。
d.（文档）纠正两处表述
pwsh-local：resolvePwshPath 会静默兜底到 Windows PowerShell 5.1，应至少告警。（注意：本 issue 与 5.1 无关，但该兜底会让排查者误入歧途——本报告的初版就是这么跑偏的。）
sandbox-windows-acl / jobs：明确"受限路径不得使用 windowsHide"。

临时规避
方案 操作 说明
单次升权 调用时带 sandbox\_permissions: danger-full-access + justification 已验证有效；每次需审批
会话级 /permission danger-full-access 已验证有效
安装 PowerShell 7 — ❌ 已证伪：安装 7.6.6 并重启后问题依旧
调整 restricting 列表 — ❌ 用户侧不可配置；且列表本身正确

**当前无用户侧根治手段**，只能以 danger-full-access 换取可用性。

---

附 A：复现脚本
随本报告提供自包含实验脚本（PowerShell + C# P/Invoke，仅创建测试进程并读取退出码，不修改任何文件）：
G:\\工作\\dsh-token-bisect.ps1 — 令牌/标志/控制台状态矩阵，含"无控制台宿主"两阶段实验
运行方式（需管理员；脚本以 Add-Type 编译内联 C#）：

pwsh -NoProfile -File .\\dsh-token-bisect.ps1

附 B：环境
项目 值
操作系统 Microsoft Windows 11 专业版
OS 版本 10.0.26200，Build 26200，DisplayVersion 25H2，UBR 9457
架构 x64
DSH 0.2.0-rc.2（桌面版 win-x64）
运行时 Node 24.21.0 / Python 3.12.14（随附）
活动 profile desktop
工作区 G:\\工作（非系统盘）
宿主完整性 High（已提升），S-1-16-12288
令牌 logon SID S-1-5-5-1-2318168691
PowerShell 7 7.6.6（MSI，%ProgramFiles%\\PowerShell\\7\\pwsh.exe）
Windows PowerShell 5.1 %SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe
安全软件 仅 Windows Defender；AppInit\_DLLs 空，LoadAppInit\_DLLs = 0
版本矩阵（沙箱相关包）
组件 版本
@deepseek-ai/dsh-pwsh-local 0.2.0-rc.2
@deepseek-ai/dsh-pwsh-sandbox 0.2.0-rc.2
@deepseek-ai/dsh-sandbox-windows-acl 0.2.0-rc.2
@deepseek-ai/dsh-sandbox-local 0.2.0-rc.2
相关源码 / 文档位置（仓库内）
内容 路径
受限令牌 / 控制台隔离限制 / 0xC0000142 说明 packages/sandbox/sandbox-windows-acl/README.md
"不添加 CREATE_NO_WINDOW" 的承诺 packages/subprocess/win32-process/README.md
Windows 子进程以 windowsHide 启动 Job runner packages/jobs/\*/README.md
pwsh 侧沙箱包装 packages/shell/pwsh-sandbox/README.md
shell 路径解析与 5.1 兜底 packages/shell/pwsh-local/src/resolve.ts
附 C：已排除的假设（完整清单）
假设 结论 证据
shell 版本 / 5.1 兜底 ❌ 排除 安装 pwsh 7.6.6 并重启后仍失败
Low 完整性标签 ❌ 排除 仅 Low（无 restricting）可正常启动
restricting 列表缺 logon SID ❌ 排除 不含 logon 但含其它广域 trustee 亦可正常启动
宿主进程无控制台（windowsHide 的副作用） ❌ 排除 无控制台宿主下"受限 + 标志=0"仍 OK
DSH 的 STARTF\_USESHOWWINDOW+SW\_HIDE ❌ 排除 该组合下启动正常
权限剥离 / DISABLE\_MAX\_PRIVILEGE / SidsToDisable ❌ 排除 均可正常启动
杀软 / 第三方 DLL 注入 ❌ 排除 AppInit\_DLLs 空，仅 Defender
沙箱整体不可用（SANDBOX\_UNAVAILABLE） ❌ 排除 runner 正常启动并 spawn 了子进程；无退出 127
累积状态 / 资源耗尽（重启可缓解类） ❌ 排除 同一进程、同一令牌、同一时刻仅创建标志不同即结果不同（矩阵 A 的 3 与 4）；资源耗尽型故障不会只挑一个标志失败。且故障早于本次会话存在，重启 DSH 亦无变化
控制台隔离标志 + 受限令牌 ✅ 确认 见矩阵 A：唯一能精确复现的组合
附 D：附带发现（与主缺陷无关）
该主机是企业网且无法访问证书吊销服务器：
curl 报 schannel: ... CRYPT\_E\_NO\_REVOCATION\_CHECK (0x80092012)
Invoke-WebRequest 因反复重试吊销检查而慢到约 11 KB/s
绕开方式：curl.exe --ssl-no-revoke（仍验证证书链），随后以 Authenticode 签名核验补偿。
另：winget install --id Microsoft.PowerShell 只提供 MSIX（msixbundle），不会创建 %ProgramFiles%\\PowerShell\\7\\pwsh.exe；如需 MSI 应从官方 Release 获取。

补充：上游状态与提交渠道（均已核实）
上游状态
检查项 结果
官方 nightly 更新源最新版 0.2.0-rc.2（releaseDate: 2026-09-29T10:35:27Z）—— 本机已是最新，无可升级的修复
GitHub Releases 最新 tag dsh-v0.2.0-rc.2
是否已有相同报告 无。0xC0000142 / 3221225794 / CREATE\_NO\_WINDOW / DLL\_INIT\_FAILED / pwsh / workspace-write / sandbox windows 全部零命中；仓库 issue 总数为 0
结论 本报告为首次报告，且不存在已发布的修复
提交渠道
首选：GitHub Discussions —— 该仓库 has\_issues: false、has\_discussions: true，Issues 功能已关闭，/issues/new 不可用：
👉 https://github.com/deepseek-ai/deepseek-harness/discussions
强烈建议同时使用应用内 /feedback —— DSH 内置该命令与助手消息的 Like/Dislike。按本仓库的 telemetry 策略，显式反馈会释放截至该事件的完整规范会话日志前缀（含上下文）。本 issue 的排查过程较长（5 轮受控实验、7 条假设被逐条排除），会话日志对维护者的价值极高。
/feedback <描述> 直接键入发送，走 Host 命令路径；
或点击相关助手消息的 👎 打开弹窗，选分类后提交。
（/feedback 不带参数只打开弹窗，不发送文本。）
附上复现脚本 dsh-token-bisect.ps1，维护者可直接跑出与"矩阵 A"完全一致的结果。

[mmungdong]

现在自己可以在插件代码里解吗？我也遇到这个问题了

[argszero]

The mechanism is right; the component it names is not — and your matrix is the reason a shipped advisory had to withdraw a sentence.

Thanks for the controlled matrix, the DETACHED_PROCESS / CREATE_NEW_PROCESS_GROUP / STARTF_USESHOWWINDOW+SW_HIDE arms in particular: they turn the console story from an anecdote into a rule rather than a list of forbidden flags.

Two source-level corrections, both read from origin/master:

1. windowsHide is not set anywhere in dsh-jobs. On win32 it appears once, on the ordinary subprocess path — packages/subprocess/subprocess-local/src/spawn.ts:472 (windowsHide: platform === 'win32') — which starts the runner rather than the confined child. A search of packages/jobs/ finds nothing.
2. The restricted path cannot pass a console-isolating flag at all. packages/subprocess/win32-process/src/abi.ts defines only CREATE_SUSPENDED and CREATE_UNICODE_ENVIRONMENT, and the three createRestrictedProcess call sites pass 0 (piped, process.ts:243), CREATE_SUSPENDED (inherited-job, process.ts:542) and CREATE_SUSPENDED | CREATE_UNICODE_ENVIRONMENT (ordinary, process.ts:567, i.e. 0x404). No CREATE_NO_WINDOW constant exists anywhere in that source.

So the flag half of your chain is measured correctly at the OS level, but "something on the restricted path passes it anyway" does not follow from the code published at that version — and your own matrix B is where the remaining variance lives: the restricting list's width against the console object's DACL ({S-1-1-0} alone fails, {logon SID, S-1-1-0} works, i.e. machine-dependent), which is the axis your causal-chain step 3 already describes.

One more thing your report surfaces and it is worth separating: 0xC0000142 is never an error in this pipeline. RUNNER_FAILURE_RULES['windows-acl'] admits exactly one code — exit 127 with the windows-acl-run: signature — so the code arrives as the canonical value of a result the pipeline calls a success and no layer can classify it. Your "the user sees a bare exit code" observation is the direct consequence.

The plugin: @argszero/cordis-plugin-sandbox-grant-advisor — mount it in a dsh profile and it attaches one user-role advisory per agent to the tool result for this family. 0.12.0, published today, replaces its older and too-strong sentence ("it is the console and not the flag list that decides") with the rule your matrix establishes — in a restricted token a console can be INHERITED but not CREATED, so a flag that forces creation is fatal on its own while DETACHED_PROCESS, which declines a console, is not — ships the matrix including the unrestricted-token pair, and answers the windowsHide suspicion with the two source facts above. It is diagnosis only: it never edits an ACL, never elevates, never sets another process's environment, and never changes a preset or a mode.