[Bug] pwsh tool crashes with 0xC0000142 when falling back to Windows PowerShell 5.1 under the Windows ACL sandbox

[Se14m]

摘要 / Summary

Windows 上未安装 PowerShell 7 时，DSH 的 pwsh 工具会按 resolvePwshPath 的兜底逻辑回退到 Windows PowerShell 5.1（C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe）。在 Windows ACL 沙箱（workspace-write / read-only）下，5.1 每次启动都以 0xC0000142（STATUS_DLL_INIT_FAILED）崩溃：零输出、命令从未执行、前台与后台 100% 复现。沙箱外 5.1 运行完全正常。

环境 / Environment

• DSH 核心版本：0.1.0-rc.6（@deepseek-ai/dsh、@deepseek-ai/dsh-sandbox-windows-acl、@deepseek-ai/dsh-pwsh-local）
• DSH Desktop 版本：0.1.4（DeepSeek Harness Desktop.exe）
• 操作系统：Windows 11 专业版 Build 26200（10.0.26200.0；与沙箱 README 的验证版本一致）
• PowerShell 7：未安装（C:\Program Files\PowerShell\7 不存在）；调查过程中安装过商店版（MSIX），见「补充证据」
• Windows PowerShell 5.1：正常（沙箱外 powershell.exe -NoLogo -NoProfile -NonInteractive -Command "Write-Output ok" 正常输出 ok，排除 5.1 本身损坏）

复现步骤 / Repro

1. Windows 机器上不安装 PowerShell 7；
2. 在 DSH 任意会话中调用 pwsh 工具，任意命令（例如 Write-Output "hi"）；
3. 结果：退出码 3221225794（0xC0000142），无任何 stdout/stderr；
4. run_in_background: true 的后台调用同样崩溃。

根因分析 / Root cause

1. 解析链静默回退到 5.1：packages/shell/pwsh-local 的 resolvePwshPath 依次探测「PowerShell 7 安装位置 → PATH 条目 → Windows PowerShell 5.1 兜底」。本机无 PS7，因此实际执行的是 powershell.exe（5.1），且无任何提示。
2. 崩溃码确属 5.1 自身：沙箱 runner（packages/sandbox/sandbox-windows-acl/runner.js）以受限令牌 CreateProcessAsUserW（dwCreationFlags=0）spawn 子进程并镜像子进程退出码（runner 自身失败会以 127 + windows-acl-run: 签名退出并被识别为 SandboxUnavailableError，本场景未出现）。所以 0xC0000142 是 powershell.exe 的崩溃码，崩溃发生在早期 DLL 初始化阶段（命令执行之前）。
3. 0xC0000142 是沙箱文档化的已知边界：sandbox-windows-acl/README.md「已验证边界 → 控制台隔离不可用」一节记载——「在受限令牌下，以 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程在 DLL 初始化期间以 STATUS_DLL_INIT_FAILED（0xC0000142）死亡」；spawn.js 注释同样写明 "hidden-console children die with STATUS_DLL_INIT_FAILED (0xC0000142) — verified empirically"。
4. 沙箱从未对 5.1 兜底做过验证：该沙箱的 restricting-SID 列表、keep-alive 组（logon SID + Everyone）等都是针对 pwsh 7（.NET 5+/CoreCLR） 调优的（代码注释中的崩溃模式均为 pwsh 的 0xC0000142 / 0xE0434352）；README 与测试均未提及 powershell.exe / Windows PowerShell 5.1。.NET Framework 的 5.1 在早期初始化上触发了这条受限令牌边界。
5. 结果：未安装 PS7 的用户每次调用 pwsh 工具都拿到一个无含义的崩溃码，完全无法定位。

期望行为 / Expected

• 未安装 PowerShell 7 时给出明确、可操作的错误（例如「pwsh 工具需要 PowerShell 7，请运行 winget install --id Microsoft.PowerShell；Windows PowerShell 5.1 兜底在沙箱下不可用」），而不是静默崩溃 0xC0000142；
• 或：将 5.1 兜底纳入沙箱兼容验证；
• 或：在文档/工具描述中明确声明「Windows 沙箱下仅支持 PowerShell 7」。

建议修复 / Suggested fixes

1. resolvePwshPath 回退到 5.1 且沙箱启用时，检测并抛出清晰的错误（可复用 SandboxUnavailableError 的呈现路径）；
2. 将「5.1 兜底 + 沙箱」组合加入回归测试，或显式标记 unsupported；
3. 工具描述 / README 注明沙箱仅支持 PowerShell 7。

附加信息 / Additional

• 崩溃在前台/后台路径一致，非偶发，与具体命令无关（Write-Output 即崩）；
• 安装 PowerShell 7（MSI）后问题消失（解析到 C:\Program Files\PowerShell\7\pwsh.exe，沙箱验证过的路径）；
• 相关社区反馈：https://linux.do/t/topic/2754213 （「deepseek harness 在 windows 下 pwsh 好多问题」）。

补充证据：微软商店版（MSIX）pwsh 同样不可用（两条路径都失败）

调查中先安装了商店版 PowerShell 7（MSIX，经 C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe 执行别名运行）。实测该版本无法作为 DSH 的 pwsh 使用，无论沙箱开关：

1. 无沙箱（danger-full-access）：Error: spawn ...\WindowsApps\pwsh.exe ENOENT —— DSH 宿主（Node/libuv）无法 spawn Windows 商店执行别名（reparse point）；用户自己的终端可正常执行（cmd/Explorer 走系统 CreateProcess 解析）。
2. 沙箱内（workspace-write）：runner 报 windows-acl-run: CreateProcessAsUserW failed (Win32 2)，同样无法解析/启动该别名。

（附带观察：解析器命中商店版后，工具错误从「静默 0xC0000142」变为「runner 失败 + 提示切换 danger-full-access」，信息量改善，但结论不变。）

阶段性结论：Windows 上 DSH 的 pwsh 工具最可靠的路径是 MSI 版 PowerShell 7（C:\Program Files\PowerShell\7\pwsh.exe 真实 exe）；5.1 兜底在沙箱下 0xC0000142 崩溃成立；商店版在包注册损坏时不可用（ENOENT / Win32 2），winget --force 重装修复注册后可正常使用（见「验证结果」）。建议：

• 解析器在「5.1 兜底 + 沙箱」或「商店版别名」场景下给出明确、可操作的错误（如「请安装 MSI 版 PowerShell 7：winget install --id Microsoft.PowerShell --source winget --force」）；
• 或将这两条路径纳入沙箱回归测试 / 文档明确声明。

验证结果 / Resolution（2026-08-15 实测）

winget install --id Microsoft.PowerShell --source winget --force 成功（重装/修复了商店包注册）后，pwsh 工具完全恢复可用：

• PSVersion=7.6.4，PSHOME=C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.4.0_x64__8wekyb3d8bbwe
• 前台命令、中文 UTF-8 输出、管道、run_in_background 后台任务全部正常（exit 0）
• 此前商店别名 ENOENT 的根因：包注册不完整（早期 msixbundle 下载失败留下的坏状态），winget --force 重装后别名可正常 spawn

注意：本次验证在 danger-full-access（无沙箱）策略下进行。「PowerShell 7 + workspace-write 沙箱」组合在桌面应用环境下未验证——若用户恢复沙箱后 pwsh 7 仍报 0xC0000142，说明该控制台/DLL 初始化边界对桌面壳（无控制台宿主）是普适的，本报告需按此升级（标题与根因将改为「任何 PowerShell 在桌面壳 + 受限令牌下 DLL 初始化失败」）。

[Se14m]

Follow-up: broader than the 5.1 fallback - PowerShell 7 also crashes under the sandbox in Desktop mode

Additional evidence on the same machine (Windows 11 Pro 26200, DSH Desktop 0.1.4):

• After installing PowerShell 7.6.4 (Microsoft Store/MSIX, repaired via winget install --id Microsoft.PowerShell --source winget --force), the pwsh tool resolves and runs fine under danger-full-access (verified PSVersion=7.6.4; foreground and background both exit 0).
• Switching the session back to the workspace-write sandbox: every pwsh call fails again with exit code 3221225794 (0xC0000142 STATUS_DLL_INIT_FAILED), zero output - identical to the 5.1-fallback crash.

Conclusion: the documented sandbox boundary ("console isolation unavailable" - children created with a hidden/new console die with STATUS_DLL_INIT_FAILED under the restricted token) affects ANY PowerShell launched from the Desktop shell (Electron host without a console), not just the 5.1 fallback. In a console-host environment the child inherits the console and the sandbox works (which is presumably why the pwsh-7 path was verified); in the Desktop app the child gets a new hidden console and DLL init fails.

Note: this also means installing the MSI build at the standard location will likely NOT avoid the crash under the Desktop app (the failure is at process/DLL-init level, not Store-specific) - untested here.

Suggested handling (any of):

1. Detect "no-console host + sandbox + PowerShell" and surface a clear error instead of a bare exit code.
2. Document Desktop + workspace-write sandbox + PowerShell as unsupported; recommend danger-full-access for pwsh in the Desktop app until the runner can provide a console-compatible environment.
3. Consider making the runner attach/create a console before spawning (the POC explicitly dropped console isolation - Desktop hosts are exactly where it matters).