Repository navigation
Replies: 1 comment 1 reply
|
我也是出现了这种问题，我现在还在查具体原因，搞的都不想睡觉了。。。 |
DSH 桌面版 Windows 沙箱
|
| 项 | 值 |
|---|---|
| 操作系统 | Windows 11 专业版 22H2，10.0.22621（Build 22621） |
| 账户 | 内置 Administrator（S-1-5-21-1234237517-3240889624-3366260708-500，显示名 ljw） |
| 令牌类型 | 纯高完整性（High Mandatory Level，S-1-16-12288），无 UAC 过滤 |
| UAC 相关 | FilterAdministratorToken=0；Administrators 组为 "Mandatory / Enabled"（非 deny-only） |
| DSH | 0.2.1-rc.2，desktop profile |
| 工作区 | D:\dsh\各种问题排查工作空间（所有者已改为当前用户） |
| PowerShell | 系统仅有powershell.exe 5.1；无 pwsh 7 |
| Job Object | 当前进程在 Job 中，UIRestrictionsClass=0，LimitFlags=0x2000（仅 KILL_ON_JOB_CLOSE） |
三、现象与复现
复现步骤
- 启动 DSH 桌面版（双击图标，GUI 启动）
- 文件策略切换为 「工作区内修改」
- 让 Agent 执行任意命令（
echo hi/whoami/ 任意 shell） - 立即返回
0xC0000142，无输出
补充现象
- 禁用 dsh-ops 插件后仍然失败（排除插件因素）
- 从终端启动桌面版仍然失败（GUI 子系统不附加父控制台）
workspace-write下工作区外写入被正确拒绝（ACL 层工作正常）
四、排查过程
阶段 1：确认问题范围
| 检查 | 结果 | 结论 |
|---|---|---|
danger-full-access 下命令 |
✅ 正常 | 命令执行链路本身没问题 |
workspace-write 下 pwsh |
❌0xC0000142 |
沙箱路径问题 |
workspace-write 下 ops_bash |
❌0xC0000142 |
同样失败 |
| 禁用 dsh-ops 后 | ❌ 仍失败 | 与插件无关 |
阶段 2：排除工作区 / ACL 因素
| 怀疑点 | 实测 | 结论 |
|---|---|---|
| 工作区所有者不是当前用户 | 改为当前用户后仍失败 | ❌ 无关 |
| 工作区 ACL 缺 WRITE_OWNER | prepare-workspace.ps1 手动执行返回 ready |
❌ 无关 |
| Low 完整性标签 | Low 标签目录上跑 read-only 正常；Medium 目录上跑 workspace-write 仍失败 | ❌ 无关 |
| cwd 影响 | runner 的 cwd 换成C:\Windows / %TEMP% 仍失败 |
❌ 无关 |
restricting SIDs 数量 |
手工加入 temp SID 仍成功 | ❌ 无关 |
default DACL 修改 |
手工合并 S-1-4 的 FULL_CONTROL ACE 仍成功 | ❌ 无关 |
AclSandbox 逻辑 |
从源码import { AclSandbox }，node 宿主下 agentless 与 seam-managed 模式全部成功 |
❌ 无关 |
阶段 3：定位到进程创建阶段
0xC0000142 = STATUS_DLL_INIT_FAILED，是 Windows 加载器返回的进程退出码，不是 JS 异常、不是权限拒绝（0xC0000022）、不是文件缺失（0xC0000135）。
ETW（Microsoft-Windows-Kernel-Process）抓到的真实进程链（打补丁后）：
START DeepSeek Harness.exe pid=107452 parent=85400 (第一层 runner)
START DeepSeek Harness.exe pid=39076 parent=107452 (第二层沙箱 runner)
START powershell.exe pid=91924 parent=39076 (目标)
STOP powershell.exe exit=0
STOP DeepSeek Harness.exe exit=0
STOP DeepSeek Harness.exe exit=0
说明：进程链完整（DSH 主进程 → 两层 runner → 目标）。补丁前目标进程直接以 0xC0000142 结束。
阶段 4：隔离「宿主形态」变量
用 koffi 直接调用 CreateRestrictedToken + CreateProcessAsUserW，复刻 DSH 的令牌构造（flags=13、restricting SIDs [logonSid, EVERYONE, workspaceSid]、降为 Low 完整性），只改变宿主进程：
| # | 宿主进程 | creationFlags | 目标 | 结果 |
|---|---|---|---|---|
| A | node.exe（控制台程序，GetConsoleWindow ≠ NULL） |
0（继承控制台） |
cmd.exe |
✅成功 |
| B | node.exe | CREATE_NEW_CONSOLE (0x10) |
cmd.exe |
❌**0xC0000142** |
| C | node.exe | DETACHED_PROCESS (0x8) |
cmd.exe |
✅ 成功 |
| D | DeepSeek Harness.exe（GUI，GetConsoleWindow = NULL） |
0（需新建控制台） |
cmd.exe |
❌**0xC0000142** |
| E | DeepSeek Harness.exe | DETACHED_PROCESS (0x8) |
cmd.exe |
✅成功 |
| F | DeepSeek Harness.exe | 0 |
powershell.exe 5.1 |
❌0xC0000142 |
结论：CREATE_NEW_CONSOLE 是失败点。受限令牌下，子进程若需要新建控制台就会 0xC0000142；能继承父控制台（A）或完全不建控制台（C/E）则正常。
阶段 5：令牌与 Job 逐项对比（排除）
令牌属性（node 进程 vs Electron 进程）——完全一致：
| 属性 | node | Electron |
|---|---|---|
TokenUser |
S-1-5-21-…-500 |
同 |
TokenIntegrityLevel |
S-1-16-12288 (High) |
同 |
TokenType |
1 (Primary) | 同 |
TokenGroups |
14 个，完全一致 | 同 |
TokenDefaultDacl |
3 ACE（Administrators / SYSTEM / logon SID） | 完全相同 |
IsAppContainer |
0 | 0 |
Job Object——完全一致：
| 项 | node | Electron |
|---|---|---|
UIRestrictionsClass |
0x0（无 UI 限制） |
0x0 |
LimitFlags |
0x2000（KILL_ON_JOB_CLOSE） |
同 |
ActiveProcessLimit |
0 | 0 |
环境变量：两者基本相同，仅 ELECTRON_RUN_AS_NODE 等差异。
五、关键实验：PowerShell 是否真的依赖控制台？**
用真正的匿名管道（CreatePipe + STARTF_USESTDHANDLES）为 DETACHED_PROCESS 子进程提供有效 stdio，排除"继承句柄无效"的干扰：
| 测试 | 命令 | 期望 | 实际 | 结论 |
|---|---|---|---|---|
| PowerShell 5.1 + DETACHED + 真管道 | -Command "exit 42" |
42 | 0 | ❌ 不执行 |
| pwsh 7 + DETACHED + 真管道 | -Command "exit 42" |
42 | 0 | ❌不执行 |
| pwsh 7 + DETACHED + 真管道 | Write-Output "X"; exit 0 |
0 + 输出 | 0 +无输出 | ❌ 未执行 |
| cmd + DETACHED + 真管道 | /c "echo X" |
0 + 输出 | 1（命令解析失败） | 需修正命令行 |
结论：Windows PowerShell（5.1 与 7 均如此）在完全没有控制台时，-Command 不会执行。 这不是 stdio 问题，而是 PowerShell 的 ConsoleHost 需要真实控制台才能初始化。
这解释了为什么：
DETACHED_PROCESS方案（无控制台）对cmd可行，对 PowerShell 不可行- DSH 的
pwsh工具在DETACHED_PROCESS下会"静默空转"
六、源码定位
关键代码 1：进程创建
packages/subprocess/win32-process/src/process.ts — spawnJobProcess()：
// Preserve console inheritance: CREATE_NO_WINDOW can fail restricted-token DLL initialization.
dwFlags: abi.STARTF_USESTDHANDLES | abi.STARTF_USESHOWWINDOW
...
abi.CREATE_SUSPENDED // 没有 DETACHED_PROCESS，也没有 CREATE_NEW_CONSOLE注释表明团队已知 CREATE_NO_WINDOW 会导致受限令牌 DLL 初始化失败，因此选择"继承控制台"。但在 GUI 宿主（无控制台） 下，子进程会被迫新建控制台，同样触发失败。
关键代码 2：stdio 限制
packages/shell/tool-pwsh/src/index.ts（约 135–148 行）：
In both confined modes, programs cannot open named pipes, so a command that captures another program's output through piped stdio ... fails with EPERM, while
stdio: 'inherit'andstdio: 'ignore'spawns work
说明团队已知沙箱下不能用 pipe，只能用 inherit。
关键代码 3：令牌注释
packages/sandbox/sandbox-windows-acl/src/token.ts（约 188 行）：
early DLL init dies with 0xC0000142 ... without them
关键代码 4：验证范围
源码注释明确写 "verified on Win11 26200"，本机 22621 未覆盖。
七、根因分析
三个条件叠加
1. Windows PowerShell（5.1/7）的 ConsoleHost 需要真实控制台才能执行 -Command
↓
2. DSH 桌面版是 Electron GUI 子系统进程，天生没有控制台
↓
3. 受限令牌（Low 完整性 + restricting SIDs）下，无法创建或继承可用的控制台
（conhost 创建/窗口站访问在受限令牌下失败）
↓
0xC0000142 (STATUS_DLL_INIT_FAILED)
为什么 web 版正常
web 版的 process.execPath 是 node.exe（控制台程序），从 Git Bash 启动时继承了真实控制台。整条 runner 链都有控制台，PowerShell 正常工作。
为什么开发阶段没发现
源码注释显示仅在 Win11 26200 验证；且开发时通常从终端启动（有控制台），子进程继承控制台，永远走不到"没有控制台"的路径。
八、三次修复尝试与结果
为验证根因，实际修改了 app.asar 内代码（均为等长字节替换，未改 asar 结构）。
尝试 1：DETACHED_PROCESS
修改 dsh-win32-process/lib/index.js，spawnInheritedJobProcess 的 flags 4 → 12。
| 结果 | 说明 |
|---|---|
✅ 不再0xC0000142 |
进程能启动，退出码 0 |
❌PowerShell 不执行 -Command |
5.1 和 7 都一样（已用真管道复测） |
✅cmd.exe 可正常执行 |
问题特定于 PowerShell |
结论：DETACHED_PROCESS 对 PowerShell 不可行——与"是否用管道"无关，是 PowerShell 的控制台依赖。
尝试 2：AllocConsole() + ShowWindow(SW_HIDE)
在 runner 初始化时分配隐藏控制台。
实测结果（真实桌面版）：
| 命令类型 | 结果 |
|---|---|
PowerShell 内置命令（Write-Output、Get-Date、Get-ChildItem） |
✅正常 |
外部程序（cmd /c、node、git） |
❌仍然 0xC0000142（弹错误对话框） |
| 工作区边界 | ✅ 正常 |
追加 SetStdHandle 恢复标准句柄后，外部命令仍然失败。
结论与意义：
- 这是最关键的反向证据：给 runner 加隐藏控制台后，PowerShell 从"完全起不来"变成"能跑"，直接证实了根因就是控制台缺失。
- 但
AllocConsole()的控制台只能让 PowerShell 自身工作，无法让其创建的外部子进程正常工作。 - 待解问题：PowerShell 把控制台句柄传给子进程时，受限令牌下子进程访问失败。这需要进一步研究（可能需要在控制台 ACL、或
STARTUPINFOEX的句柄列表上做工作）。
尝试 3：CREATE_NEW_CONSOLE（由 subprocess runner 分配）
修改 spawnCurrentTokenJobProcess 的 flags 1028 → 1044，让 subprocess runner（High，非受限）启动 target 时分配隐藏的真实控制台。
结果：pwsh 工具完全失败（连内置命令都 0xC0000142）。已立即回滚。
推测原因：target 是 Electron（GUI 子系统），CREATE_NEW_CONSOLE 对 GUI 程序无效/异常。
九、对照：node 宿主完全正常
实验 1：web 版（含 dsh-ops）
| 检查项 | 结果 |
|---|---|
process.execPath |
@dsh-ops\pwsh-win32-x64\bin\pwsh.exe（pwsh 7.6.6） |
| 令牌完整性 | Low（S-1-16-4096） ✅ |
| 工作区外写入 | ✅拒绝 |
| 私有 temp 写入 | ✅ 允许 |
node / git / 子进程 |
✅ 全部可用 |
实验 2：纯净环境（禁用 dsh-ops）
| 检查项 | 结果 |
|---|---|
| PowerShell 版本 | 5.1.22621.4249 Desktop（系统版） |
pwsh 工具 |
✅ 可用 |
| 令牌完整性 | Low（S-1-16-4096） ✅ |
| 工作区外写入 | ✅ 拒绝 |
子进程（cmd /c） |
✅ 正常 |
node v25.2.1 |
✅ 正常 |
| WMI/CIM | ❌ 拒绝访问（预期，受限令牌下 CIM 不可用） |
两组实验证明：沙箱的令牌构造、ACL 授权、边界判定、temp 授权逻辑本身没有问题；唯一变量是宿主进程形态。
十、修复建议
1. 让 runner 使用 node.exe
web 版能工作的直接原因是 process.execPath 是 node.exe（控制台程序），从终端继承真实控制台。
但注意：asar 内的 runner.js 不能被外部 node.exe 直接加载（node 无 asar 支持）。需要：
- 把 runner 及其依赖解包到 asar 外的独立目录，用
node.exe运行；或 - 使用 Node SEA（single executable application）打包 runner。
优点：无需控制台窗口，路径与 web 版一致（已验证可用）。
代价：需要调整打包结构。
2. 隐藏控制台 + 解决子进程继承（需继续研究）
AllocConsole() + SW_HIDE 已证明能让 PowerShell 自身工作。剩余问题是PowerShell 创建的外部子进程无法使用该控制台。
可能的切入点：
- 控制台的 ACL：
AllocConsole创建的控制台，其安全描述符是否允许受限令牌子进程访问； STARTUPINFOEX+PROC_THREAD_ATTRIBUTE_HANDLE_LIST：显式传递控制台句柄；--encodedcommand或-File替代-Command：排除命令行解析因素；CreateProcessAsUserW的lpDesktop：显式指定WinSta0\Default；- job object 的 UI 限制：确认没有额外限制（已确认
UIRestrictionsClass=0）。
3. stdio 改用文件重定向
受限令牌下 pipe 会 EPERM、inherit 在 GUI 宿主下无效。可将 stdout/stderr 重定向到临时文件，命令结束后由 runner 读回，彻底摆脱管道与控制台的 stdio 依赖。
但注意：这解决的是"输出捕获"，不解决 PowerShell 对控制台本身的依赖。
4. 失败时给出可诊断的错误
0xC0000142 对用户完全不可读。建议在 runner 捕获该退出码时输出：
sandbox runner: child exited with STATUS_DLL_INIT_FAILED (0xC0000142);
likely cause: the host has no console for a console-subsystem target under a restricted token.
十一、未验证 / 存疑
- 内置 Administrator 是否为必要条件：本机命中该特征，但未在标准用户账户下对照测试。真正的充分条件可能只是"GUI 宿主 + 受限令牌"。
- 具体失败的 DLL：未用 Procmon / loader snaps 抓取。
CREATE_NEW_CONSOLE复现失败是强关联，但不是直接观测。 AllocConsole的控制台为何不能被子进程继承：现象已确认（尝试 2），机制未深究。这是最关键的待解问题。- 尝试 3 失败的确切原因：推测是
CREATE_NEW_CONSOLE对 GUI 子系统（Electron）无效，未验证。 - PowerShell 的"控制台依赖"是否可通过
-NonInteractive之外的参数绕过：未穷举。
附录：实验方法与脚本
- 令牌构造复刻：
CreateRestrictedToken(flags=13, restrictingSids=[logonSid, EVERYONE, workspaceWriteSid])+SetTokenInformation(TokenIntegrityLevel=Low) - 进程创建：
CreateProcessAsUserW(token, null, cmdline, null, null, 1, flags, null, cwd, &si, &pi)，si.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW - 真管道：
CreatePipe+SECURITY_ATTRIBUTES{bInheritHandle=TRUE}，父进程保留读端 - Job：
CreateJobObjectW+JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE - ETW：
logman start <name> -p Microsoft-Windows-Kernel-Process 0x10 -o trace.etl -ets - asar 修改：按 header 的 offset/size 直接读写字节；补丁采用等长替换（删除注释 + 空格补齐），避免重建 header
备份与回滚
| 文件 | 说明 |
|---|---|
app.asar.bak-before-detached-patch |
最初原始版 |
app.asar.bak-before-console-fix |
尝试 2 前 |
app.asar.bak-before-newconsole |
尝试 3 前 |
当前 app.asar SHA256 与最初原始版一致：47874618BF5B3011FCAAC10CD4C85F69DA333E70D4F99B921207C78D0999512A。
桌面版
workspace-write失败的根因是 Windows PowerShell 硬依赖控制台 + Electron GUI 宿主没有控制台 + 受限令牌无法创建控制台。给 runner 加隐藏控制台能让 PowerShell 自身工作（已证实根因），但外部子进程的继承问题尚未解决。最干净的修复是让 runner 使用node.exe（与 web 版一致，已验证可用）。
Uh oh!
There was an error while loading. Please reload this page.
环境
EnableLUA = 0），进程为高完整性（Elevated: True）C:\Program Files\PowerShell\7\pwsh.exe（非 Microsoft Store 别名，WindowsApps下无 pwsh）现象
在「工作区内修改」（workspace-write）权限下，任何 shell 调用都会立即失败，返回错误码
0xC0000142（STATUS_DLL_INIT_FAILED），没有任何命令输出。切到「完全权限」（danger-full-access）后，同一条命令、同一个 pwsh 7.6.7 正常工作。
复现步骤
echo hi0xC0000142，无输出已排除的原因
0xC0000142AppData\Local\Microsoft\WindowsApps下不存在 pwshC:\Program Files\PowerShell\7\pwsh.exe结果相同怀疑方向
DSH 的 Windows 沙箱在执行子进程时使用受限令牌和低完整性级别。相关代码注释显示只在 Windows 11 26200 上验证过，而本机是 Windows 10 19045。在该组合下，子进程可能在窗口站/桌面访问或 user32 初始化阶段失败，表现为
STATUS_DLL_INIT_FAILED，因此换任何 shell 都无效。另外，本机是内置 Administrator 且 UAC 关闭，进程持有纯高完整性令牌；受限令牌从高完整性令牌派生，可能是触发条件之一。
期望行为
补充
如果官方需要，我可以提供进程监听（Procmon）抓到的具体失败 DLL，以及在受限会话中对照 5.1 与 7.6.7 的结果。
All reactions