[Bug][Windows desktop] workspace-write 子进程 0xC0000142：普通/管理员启动对照（0.2.0-rc.2，Win11 26200）

[yuease]

问题概述

Windows 桌面版 DSH 在 workspace-write 模式下无法启动受限 shell：命令无输出，退出码为 3221225794（有符号表示为 -1073741502，十六进制 0xC0000142 / STATUS_DLL_INIT_FAILED）。

同一台机器上，普通权限重新启动 DSH 后 shell 恢复，并验证了工作区内写入成功、越界写入被拒。之后再次以管理员身份启动，故障重现。管理员宿主与故障存在明显关联，但完整触发条件仍需进一步验证，见下方证据限制。

环境

• DeepSeek Harness Windows 桌面版，0.2.0-rc.2，nightly 通道。
• Windows 11，OS build 26200（PowerShell 的 OS 字段显示 Microsoft Windows 10.0.26200）。
• DSH 配置 profile：desktop；工作区：%USERPROFILE%\.dsh。
• 已使用官方 MSI 安装 PowerShell 7.6.6：C:\Program Files\PowerShell\7\pwsh.exe；正常、不受限启动已验证。
• 也测试过缓存中的 PowerShell 7.6.5，失败表现相同。
• 直接调用 DSH 包内 @deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js；Electron Node runtime 24.18.1。
• 初始排查时 Windows UAC 的 EnableLUA=0；直接双击桌面快捷方式也会以提升权限启动。快捷方式本身没有 RunAsAdmin 标志，程序没有 RUNASADMIN 兼容性项。这是当时的系统状态，不作为单独已确认的根因。

复现步骤

1. 完全退出 DSH 桌面版，确保旧进程退出。
2. 以管理员身份启动 DSH，选择 workspace-write 会话。
3. 调用 pwsh 工具执行：

$PSVersionTable.PSVersion.ToString()
Write-Output 'sandbox-ok'

4. 观察：无输出，退出码 3221225794 / 0xC0000142。
5. 完全退出后以普通权限启动，在同一工作区、同一 PowerShell 路径下重复；本机测试恢复成功。
6. 再次以管理员启动后，最后一轮测试重新失败。

实测结果

直接运行 DSH 原生 runner

• 缓存版 PowerShell 7.6.5，read-only：退出 0，输出 sandbox-ok。
• 缓存版 PowerShell 7.6.5，workspace-write：退出 0xC0000142。
• 官方 PowerShell 7.6.6，不受限：退出 0，输出版本 7.6.6。
• 官方 PowerShell 7.6.6，read-only：退出 0，输出 sandbox-ok。
• 官方 PowerShell 7.6.6，workspace-write：退出 0xC0000142。
• Windows cmd.exe，workspace-write：退出 0xC0000142。

因此故障不局限于 PowerShell 版本或安装路径。没有测试 cmd.exe 的只读模式，不将其列为成功结果。

DSH 导出会话中的原始工具结果（脱敏摘录）

用户报告普通权限启动后，pwsh 工具返回：

PSVersion=7.6.6
PSEdition=Core
LangMode=FullLanguage
WriteInWorkspace=ok
RemoveProbe=True
Exe=C:\Program Files\PowerShell\7\pwsh.exe

随后验证边界：

ChildExitCode=7
System32Visible=True
OutsideWrite=denied
OutsideFileExists=False
DSH_PROFILE=desktop

最后用管理员重启，同一工具再次返回：

(no output)
[exit code: 3221225794]

早期已批准的不受限诊断返回 Elevated=True，whoami /groups 显示 High Mandatory Level。

预期行为与临时恢复方法

希望 workspace-write 能稳定启动受限进程；如果某种提升权限宿主环境不受支持，应给出可操作的提示，而不是让每条命令静默返回 DLL 初始化错误。

本机普通权限启动后曾恢复，且工作区写入边界有效。read-only 也在直接 runner 测试中正常。完全权限模式能运行，但它绕过受限执行，不能视为沙箱修复。

排查没有修改 DSH 包内代码或降低沙箱保护。可以优先比较已核实的普通/提升宿主 token、工作区模式、默认 DACL、private temp、控制台创建标志和继承 stdio 的组合；这些是建议调查方向，不是已确认根因。

相关反馈

• [Bug] Windows: sandboxed pwsh always dies with 0xC0000142 under console-less host (desktop launch path) #810：[Bug] Windows: sandboxed pwsh always dies with 0xC0000142 under console-less host (desktop launch path) #810
• Workspace-write sandbox: external processes fail with 0xC0000142 on Windows 10 (build 19041) #1847：Workspace-write sandbox: external processes fail with 0xC0000142 on Windows 10 (build 19041) #1847

本反馈补充 Windows 11 build 26200、桌面版 0.2.0-rc.2，以及启动权限切换的对照结果。

[MalikAhed]

The elevation correlation is useful, but 0xC0000142 only establishes STATUS_DLL_INIT_FAILED; it does not by itself prove the ACL is the cause. I’d capture the child’s effective environment and token for the failing and successful runs, then compare the exact launch boundary: integrity level, default DACL, PATH, TEMP/TMP, inherited stdio/console flags, and the resolved pwsh.exe/cmd.exe path. Also check Windows Event Viewer → Application Error/SideBySide at the failure timestamp for the DLL or initialization module.

Because the same runner works in read-only mode and fails for both PowerShell and cmd under workspace-write, a useful regression is a minimal child that prints its token and exits 0 before the sandbox write step, followed by a child that writes only inside the workspace. That separates process initialization from the ACL policy. Keep the normal-user and elevated-host cases as separate fixtures, and do not treat full-permission mode as a sandbox fix. Related reports #810 and #1847 may help compare the console-less launch path. If this helps narrow the cause, please mark the reply as the accepted answer.

[yuease]

Thanks — your suggested comparison helped narrow this down substantially. I have now captured the host and sandbox token immediately before CreateProcessAsUserW, including the child's default DACL, rather than inferring host elevation from the child.

With the same PATH, working directory, explicit executable paths, command arguments, and inherited stdio setup:

• Medium-integrity host (TokenElevation=0): PowerShell initialization, workspace-only writes, and cmd initialization all exit 0.
• High-integrity host (TokenElevation=1): those workspace-write tests all exit 0xC0000142, including the initialization-only test that performs no workspace write. The read-only PowerShell test still exits 0.
• High-integrity host, with one experimental change to the fresh sandbox token's default DACL: all those tests exit 0.

The relevant DACL difference is that the normal host's default DACL contains a GENERIC_ALL allow ACE for the current user, while the elevated host's contains a GENERIC_ALL allow ACE for BUILTIN\Administrators instead. DSH retains this difference in the sandbox token. Both sandbox tokens have Low integrity, TokenElevation=0, and Administrators is deny-only.

For the experimental change, I retained every existing ACE and added a non-inheritable GENERIC_ALL allow ACE for the current token's user SID to the sandbox token's DEFAULT DACL. I did not change the token's groups, restricting SID list, integrity level, privileges, or any filesystem ACL as part of that intervention. This was applied only in a diagnostic wrapper to newly created tokens; the installed DSH code was not patched.

After the intervention I also verified:

inside-ok
OutsideWrite=denied
OutsideExists=False
grandchild-ok
exit=0

This checks the workspace boundary and a cmd grandchild; it is not a complete security review of a production fix.

Captured launch parameters: CreateProcessAsUserW creationFlags=4 (CREATE_SUSPENDED), inheritHandles=1, STARTUPINFO.dwFlags=257 (STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW), wShowWindow=0, lpDesktop=NULL, and lpEnvironment=NULL. These settings remained unchanged. TEMP/TMP used the runner's generated private directories under the same root; directory names and the derived temp capability SIDs naturally differed per run. Both tests used C:\Program Files\PowerShell\7\pwsh.exe (7.6.6), and the cmd fixture used C:\Windows\System32\cmd.exe.

Application log checks around the original failures found no matching Application Error, SideBySide, WER, or .NET Runtime entry identifying the failing module.

So this is now more than elevation correlation: a targeted default-DACL intervention removes the reproduced failure while the tested workspace confinement remains effective. I still cannot identify the precise DLL/initialization API without loader tracing, and I am not treating unrestricted execution as a sandbox fix. A production fix should be reviewed and add regression fixtures for both normal and elevated hosts, including boundary and grandchild-spawn checks.

[MalikAhed]

happy to help