[Bug] shell 工具 100% 失败 (0xC0000142)；重装后应用无法启动 (0.2.1-rc.3 / Win11)

[qingnian123-cod]

DeepSeek Harness 预览版 Bug 报告

报告人：普通用户（非开发者）
日期：2026-10-24
版本：DeepSeek Harness 0.2.1-rc.3（更新通道 nightly）
系统：Windows 11，64 位，中文计算机名
安装方式：官方下载 https://download.deepseek.com/desktop/dsh-latest-windows-x64.exe

---

摘要

两个独立问题：

1. 所有 shell 命令执行失败，错误码 3221225794（0xC0000142 STATUS_DLL_INIT_FAILED）
2. 卸载重装后程序无法启动，进程启动即退出，退出码 0x80000003，无任何日志输出

第 2 个问题可能是第 1 个问题排查过程中触发的，也可能是独立缺陷。

---

Bug 1：shell 工具 100% 失败

现象

任何通过 shell 执行的命令都返回相同错误：

运行命令 · Retry shell with explicit workdir
✗ 退出码 3221225794

即使用最简单的命令也一样：

echo ok

模型侧收到的反馈是：shell 起不来，所有 pwsh 调用返回 exit code 3221225794（0xC0000142，DLL 初始化失败），连 echo ok 都不行。

复现步骤

1. 安装 0.2.1-rc.3
2. 新建会话（创造模式 / 标准模式均如此）
3. 让 Agent 执行任意命令，例如「运行 echo ok」
4. 必现

已排除的原因（均为实测，非推测）

怀疑项	测试方法	结果
工作目录含中文	把工作区切到纯 ASCII 路径 C:\Users\wx200\AppData\Local\Temp\dsh-test 后重试	仍失败
缺少 VC++ 运行库	检查 System32 下 vcruntime140.dll、vcruntime140_1.dll、msvcp140.dll、concrt140.dll	全部存在，且已安装 VC++ 运行库
系统 ConPTY 损坏	独立安装 node-pty（npm），用同一 ConPTY 机制 spawn cmd.exe /c echo ok 与 powershell.exe	均正常输出 ok，退出码 0
系统 PATH 损坏	用 Node 的 child_process.spawnSync 直接 spawn powershell.exe -Command echo ok	正常，退出码 0
权限模式	沙箱模式 workspace-write 下复现	未能在 UI 中切换 Full access 后复测
环境变量被裁剪	用 Node 以空 env {} spawn powershell	仍正常启动

附加线索

• 程序内部模块：resources/app.asar.unpacked/dsh/node_modules/node-pty/prebuilds/win32-x64/conpty.node
• 该文件大小 304,616 字节，SHA256 前 16 位 B1FD2914229C11B0
• 卸载后重新安装，该文件哈希完全一致
• 终端控制器模块名：@deepseek-ai/dsh-api-terminal-controller，其中 shell 候选顺序为 zsh → bash → fish → pwsh → powershell → cmd
• 本机未安装 PowerShell 7（pwsh.exe 不存在），系统只有 Windows PowerShell 5.1

建议排查方向

1. 检查 conpty.node 是否与目标系统的 CPU 特性 / Windows 版本兼容（是否使用了特定指令集编译）
2. 检查 dsh-api-terminal-controller 验证 shell 候选时的 spawn 参数（是否传入了非默认的 env / cwd / detached 组合）
3. 在 spawn 失败时把底层系统错误码完整打印到日志，目前用户侧完全看不到原因

---

Bug 2：卸载重装后程序无法启动

现象

卸载（Uninstall DeepSeek Harness.exe /S /KEEP_APP_DATA）后重新安装，程序启动即退出：

退出码: -2147483645  (0x80000003 STATUS_BREAKPOINT)

关键细节

• stdout、stderr 全部为空
• Windows 事件查看器 → 应用程序日志中没有任何 DeepSeek 相关记录
• %APPDATA%\DeepSeek Harness 与 %LOCALAPPDATA%\DeepSeek Harness 根本没有被创建
• 说明进程在初始化早期就退出了，连用户数据目录都没走到

已排除

怀疑项	结果
安装路径含中文	分别装在 …\大肥鱼的工作台\dsh；\ 与纯 ASCII 的 C:\DSH\
残留进程占用	确认无任何相关进程
残留锁文件	~/.dsh 下无 lock / pid 文件

时间线

• 15:45 首次安装（/S 静默装到 %LOCALAPPDATA%\Programs\DeepSeek Harness）→ 可以正常启动和使用
• 因 Bug 1 排查，执行卸载
• 之后无论装到哪里，都无法启动

建议排查方向

1. 卸载程序是否删除了重装后不会重建的必要组件（注册表项、清单文件、运行库）
2. 首次启动与二次启动的初始化流程差异
3. 该退出码在 Electron 中通常对应原生模块加载失败或单实例检测，建议在失败时输出至少一行日志

---

其他观察

• 安装程序不支持静默安装：带 /S 参数执行返回退出码 2（即使已经指定 /D= 目标目录），只能走 GUI
• GUI 安装时对某些路径误报「无法写入此位置。请选择当前用户可写入的文件夹」，但该路径实测普通账户完全可写（C:\ 根目录对 Authenticated Users 完全控制），疑似路径可写性检查逻辑缺陷

---

期望

1. shell 工具能正常执行命令
2. 启动失败时至少输出一行可读的错误信息，而不是静默退出
3. 卸载重装应当是可靠路径，不能把「能用的」变成「不能用的」

---

报告基于 2026-10-24 的完整排查过程整理。排除了 5 类常见原因，均附带测试方法，便于复现核对。

[PerryLink]

shell 那半是同一个有文档的失败，重装救不了另一半。

0xC0000142 在 sandbox-windows-acl 的 README 里有两个写明了的成因：保活组（登录 SID + Everyone）缺失（:102），以及用 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程（:127）——所以进程层特意避开这两个标志（packages/subprocess/win32-process/src/process.ts:454）。还有第三种和你这种"每条命令都崩"最像的：路径的 DACL 里带着别的 AppContainer 工具的包 SID，低完整性令牌读不了它（:189），于是 DLL 初始化在命令执行之前就失败。

针对第三种，包里带了诊断加修复（README.md:78-80），必须非受限运行（受限令牌写不了 ACL）：

& '<skill-dir>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<failing-path>' -AllowRoot '<authorized-dir>' -Out '<recovery-dir>'

它会逐条备份、回读校验、把外来的包 SID ACE 从源头删掉，并打印回滚命令；遇到 reparse point 或受管的应用目录会直接拒绝，不会硬改。

重装为什么没用：文件还是落回原来那个目录，而 ACL 属于目录不属于文件；Chromium 的安装目录检查（就是你"重装后应用无法启动"那半）看的是目录 DACL，所以清 app data、重装都不会补上缺的那个 ACE。真正要做的是把那个目录的 ACL 修一次。

我只读了 README 和脚本源码（22ddee3），没在 Windows 上跑过。