Workspace-write sandbox: external processes fail with 0xC0000142 on Windows 10 (build 19041)

[TUO-AI]

DSH Windows ACL 沙箱在 Windows 10 上受限令牌进程启动失败(0xC0000142)
环境
操作系统:Windows 10(build 19041,PowerShell 5.1.19041.4170)
DSH:web 模式(127.0.0.1:3080),会话沙箱模式 workspace-write
安全软件:Windows Defender 实时保护已关闭(用户确认一直关闭);360 仅存 ELAM 驱动 360elam64.sys(无完整 360 安全卫士组件)
工作区:D:\DSH(ACL 干净:9 条 ACE,仅 1 条工作区写 SID S-1-4-…)
现象
workspace-write 模式下,从受限 pwsh 会话内启动外部程序间歇性失败:

where.exe、cmd.exe、python/py、node、tesseract、powershell.exe(子进程)启动即失败
部分进程弹出 "应用程序无法正常启动 (0xC0000142)" 对话框;部分静默无输出
Start-Process cmd.exe -Wait 观察到退出码 -1073741502(= 0xC0000142,STATUS_DLL_INIT_FAILED)
PowerShell 内置受限令牌不可用的命令也被拒:Get-NetTCPConnection(拒绝访问)、Get-CimInstance(静默失败)——与 README 记录的"Authenticated Users 不在 restricting 列表,故 CIM 不可用"一致
时序:会话早期大量 py 调用全部成功(数十次),随后持续失败;重启 dsh web 服务无效;切换 danger-full-access 后全部恢复正常;切回 workspace-write 再次失败
D:\DSH ACL 无累积(排除授权条目膨胀损坏 DACL)
怀疑根因
WRITE_RESTRICTED 受限令牌的 restricting-SID 列表(登录 SID + Everyone + 工作区写 SID)在 Windows 10 上与 Windows 11 26200 行为不一致:

README 明确"verified on Windows 11 build 26200",且将 0xC0000142 记录为受限令牌的已知边界("控制台隔离不可用……子进程在 DLL 初始化期间以 STATUS_DLL_INIT_FAILED 死亡")
受限令牌缺少控制台登录 SID(S-1-2-1)/INTERACTIVE/Authenticated Users;README 记录了 S-1-2-1 在 Win11 26200 上的无效实验,但 Win10 加载器对控制台/DLL 初始化检查可能不同
间歇性(早期可用、后期失败)表明存在令牌构造或加载器状态相关的竞态,在 Win10 上更敏感
复现
会话沙箱模式 = workspace-write(Windows 10,19041)
执行 py --version 或 where.exe cmd(从 DSH pwsh 工具)
观察:进程无输出/弹出 0xC0000142 对话框,Start-Process 变体返回 -1073741502
期望
workspace-write 模式下外部进程(where/cmd/python 等)可稳定启动,或
提供关闭受限令牌执行的配置项(fail-open 开关),或
提供 Win10 专用的 keep-alive restricting-SID 组合(如加入 S-1-2-1)验证是否消除 0xC0000142
备注
WER HKCU...\Windows Error Reporting\DontShowUI=1 已设置,无效(0xC0000142 为加载器对话框,非 WER 路径)
danger-full-access 模式无此问题(不走受限令牌)

[denial123789]

This report matches an explicit implementation boundary, with one important version distinction:

• win32-abi.ts says the restricting-SID experiments were verified on Windows 11 build 26200.
• The backend documents STATUS_DLL_INIT_FAILED for restricted children created with incompatible console flags.
• token.ts intentionally omits Authenticated Users, INTERACTIVE, LOCAL, and S-1-2-1; adding them broadly would change the security boundary, not merely improve compatibility.

Your Windows 10 build 19041 A/B result is therefore useful evidence of an OS/backend compatibility gap. I would not add a fail-open switch: silently running the same requested command unrestricted defeats the permission contract. The next diagnostic should preserve the exact child command, creation flags, inherited stdio mode, OS build, and unsigned exit code 3221225794. A small matrix using the same executable with inherited console versus CREATE_NO_WINDOW or CREATE_NEW_CONSOLE would help distinguish the documented console path from a wider loader issue.

For affected operators, danger-full-access is not a sandbox fix. Move only the blocked task to a disposable VM or another explicit isolation boundary and keep the mode change visible.

Tracked with the source boundary and safer next action here:
https://sandbaseai.github.io/deepseek-harness-handbook/field-status.html

[MengLs1620]

补充数据：同一根因，但表现为必现，且受限 shell 本身起不来

环境：Windows 10 Pro for Workstations 22H2（build 19045）；官方签名的 DeepSeek Harness 桌面版，FileVersion = 0.1.7-rc.2（nightly 通道当前最新）；内置 @deepseek-ai/dsh-sandbox-windows-acl 0.1.7-rc.2；会话模式 workspace-write。

现象：经 pwsh 工具执行任意命令（如 $PSVersionTable.PSVersion.ToString()）→ 无输出，退出码恒为 3221225794（0xC0000142）。

• 无 stderr，且没有 windows-acl-run: 签名 → runner 自身正常，死的是它生成的受限子进程
• 事件日志无 WER / Application Error 记录；切 danger-full-access 立即恢复
• 与 Workspace-write sandbox: external processes fail with 0xC0000142 on Windows 10 (build 19041) #1847 的差异：不是间歇性，是 100% 必现

四组对照实验（逐个排除嫌疑）：

假设 | 结果 -- | -- 低完整性（Low IL）本身 | ✅ 正常 —— Sysinternals PsExec 启动 S-1-16-4096 子进程成功跑起 pwsh 7.6.6（exit 0） shell 版本 | ❌ 无关 —— 本机原未装 PS7（解析到 5.1）；安装 7.6.6 并完整重启后，从 DSH 内部确认已解析到 pwsh 7.6.6 / PSEdition Core，仍 0xC0000142 第三方 DLL 注入 | ❌ 无关 —— AppInit_DLLs 空且 LoadAppInit_DLLs=0（64/32 位）、无 AppCertDlls、无 IFEO Debugger；pwsh 进程模块表中无任何第三方 DLL 启动器的控制台继承 | ❌ 无关 —— 改为从已打开的 PowerShell 窗口启动应用（父进程非 explorer），仍失败

另核对：工作区根 SDDL 含沙箱的常驻 capability ACE（形如 (A;OICI;0x110156;;;S-1-4-<n>-<n>)）与 (D;CI;DT;;;WD)，说明 ACL 供给确实执行过，不是权限没配上。

指向：该后端 token 模块自己写明「受限子进程必须共享宿主控制台；在受限令牌下自行创建 conhost 会以 STATUS_DLL_INIT_FAILED 死亡」，并标注 restricting 列表验证于 Win11 26200。而 Electron 桌面宿主没有控制台可传递。

关键：修复已经写好了，只是没进发行版。

桌面仓库存在提交 a1caef3（fix(win): keep confined shells alive when Electron has no console，2026-09-15，注明 Core fix adapted from community PR #629）：在 Node 模式 trampoline 中、仍未受限时调用 AllocConsole() 并以 SW_HIDE 隐藏，再导入上游 runner，使受限子进程继承一个已存在的控制台。

但对已安装的 app.asar 检索 AllocConsole / windows-console-host / ensureWindowsConsoleHost / desktop trampoline → 0 命中（同一文件里 trampoline 所依赖的 ELECTRON_RUN_AS_NODE 机制是存在的）；且内置沙箱包仍为 rc.2，而该提交的部署根固定到 rc.6。判断为修复未进入官方发行版。

请求：

1. 把该控制台分配修复（或 PR CJK 中文输入法在 Web 对话框无法正常使用（附定位与修法建议） #629 的思路）带进官方桌面发行版，并覆盖 read-only 与 workspace-write 两种模式。
2. 让失败可诊断：目前「runner 正常 + 子进程死亡」在工具层与普通命令失败无法区分，模型侧只看到一个裸的 0xC0000142。若能在受限 spawn 前做一次控制台可用性自检并给出结构化原因，排查成本会大幅下降。
3. 明确一点：这不是请求 fail-open，也不建议往 restricting 列表加入 Authenticated Users / INTERACTIVE / LOCAL / S-1-2-1 —— 那是扩大安全边界，不是修兼容性。

最小复现：

代码块

1. 会话权限 = 工作区内修改（workspace-write）
2. 经 pwsh 工具执行（不提权）：$PSVersionTable.PSVersion.ToString()
   → 无输出，退出码 3221225794
3. 对照：切「完全权限」(danger-full-access)，同一命令成功