DEEPSEEK HARNESS出现问题解决和反馈

xigua663

314人浏览 · 2026-08-18 16:43:08

xigua663 · 2026-08-18 16:43:08 发布

DeepSeek Harness 在 Win11 上「无法打开文件夹」深度排查实录：从 0xC0000142 现场证据到 readUtf16 截断修复

踩坑记录 · 排查思路 · 代码级修复，已本地验证，待上游合并

摘要

DeepSeek Harness（dsh web，v0.1.0-rc.6）在 Windows 上点击「添加文件夹」时报错：

复制

directory picker failed: directory picker failed: win32 folder dialog worker exited before reporting a result

本文完整还原了这条报错的真实调用链（不是 Electron 的 dialog.showOpenDialog，而是 koffi 直调 Win32 COM 的 IFileOpenDialog），记录了排查中抓到的关键现场证据（0xC0000142 = STATUS_DLL_INIT_FAILED），并确认了两个代码层问题：worker 失败零诊断信息 与 readUtf16 在 U+XX00 字符处截断（确认为代码 bug）。附上 5 条已本地验证的修复方案。

一、环境与现象

项目	值
系统	Windows 11 Home China（build 26100）
Node	v24.17.0
koffi	3.1.5
DSH	`@deepseek-ai/dsh` 0.1.0-rc.6（npm 全局安装，`dsh web`）

现象：点击「添加文件夹」→ 弹窗报错 → 无法选择任何目录。

初始判断：报错文案极其模糊，只有一句 "worker exited before reporting a result"，完全无法判断是权限、兼容性还是 IPC 问题。于是决定从源码入手逐层还原。

二、调用链还原：报错到底从哪来

DSH 的 Web GUI 在 Windows 上不是用 Electron/Tauri 的系统对话框，而是用 koffi（Node FFI 库）直接调用 Win32 COM 接口 IFileOpenDialog，并且弹窗逻辑运行在 spawn 出来的子进程 worker.cjs 中（目的：模态对话框阻塞子进程，主进程事件循环保持活跃）。

复制

用户点「添加文件夹」
  └─> dsh-client-ui-directory-picker-native（前端，只发请求）
        └─> dsh-host-directory-picker-auto 启动时判定后端
              │   win32 + 127.0.0.1 + 非 SSH  → 选 native
              └─> dsh-host-directory-picker-native
                    pickWin32Directory()
                      └─> spawnDialogWorker()：spawn(node.exe, [worker.cjs])
                            │   stdio: ["ignore","inherit","inherit","ipc"]
                            └─> worker.cjs（子进程）
                                  koffi.load(ole32/user32/kernel32)
                                  CoCreateInstance(IFileOpenDialog)
                                  dialog.Show()            ← 模态阻塞
                                  process.send({kind:'done', path})   ← 回报结果

报错文案的精确来源在 dsh-host-directory-picker-native/lib/index.js 的 worker.on("exit") 兜底分支：

复制

worker.on("exit", () => {
    settle(() => {
        reject(new Error("win32 folder dialog worker exited before reporting a result"));
    });
});

也就是说：主进程 spawn 的子进程在发回任何消息（showing / done / error）之前就退出了。而 worker 内部所有 JS 异常都会被 try/catch 捕获并走 IPC 上报，唯独原生层崩溃 / DLL 加载失败 / 进程被 kill 是 JS 捕不到的——这正是「退出前零消息」的典型成因。

三、关键现场证据：0xC0000142 = STATUS_DLL_INIT_FAILED

排查当天（8/17）抓到了一个决定性信号：同一会话内所有新 spawn 的子进程（PowerShell / ripgrep / glob）统一以 0xC0000142 退出，而纯文件 I/O 完全正常。

复制

[exit code: 3221225794]  ==  0xC0000142  ==  STATUS_DLL_INIT_FAILED（DLL 初始化失败）

结论：这台机器当时系统级 DLL 加载链路存在故障，而 DSH 的目录选择器恰好依赖「spawn 子进程 + 子进程内加载 DLL」，于是成为最先爆雷的功能。不是 DSH 代码本身的锅。

更有意思的是次日（8/18）同机不再复现：koffi 加载正常，worker 独立 spawn 可正常弹出对话框。结合两个时间点的证据，判定为环境性/瞬时性故障（常见诱因：系统 DLL 损坏/更新残留、PATH 被 DLL 劫持目录污染、安全软件注入导致加载器失败）。

💡 排查心法：报错只给了一句通用文案时，别急着猜「权限 / 兼容性 / IPC」——先看错误码。0xC0000142 这类系统级 NTSTATUS 能直接告诉你问题在进程加载层而不是应用逻辑层。

但「环境性故障」只是表象，它暴露了下面两个实实在在的代码层问题。

四、问题 1：worker 失败时零诊断信息（代码缺陷）

worker.on("exit") 把 (code, signal) 全部丢弃，且 spawn 时 stderr 配置为 inherit（不捕获）。后果：原生 SEH 崩溃 / DLL 初始化失败 / 顶层 throw / 被杀这四种退出原因完全无法区分，用户只能看到一句通用文案，维护者拿不到任何堆栈。

修复：exit 错误携带 code/signal/stderr

复制

// spawnDialogWorker 内：stderr 改为管道捕获
const stdio = ["ignore", "ignore", "pipe", "ipc"];

// pickWin32Directory 内：
let workerStderr = "";
worker.stderr?.on("data", (chunk) => { workerStderr += chunk; });

worker.on("exit", (code, signal) => {
    settle(() => {
        reject(new Error(
            `win32 folder dialog worker exited before reporting a result ` +
            `(code=${code}, signal=${signal}, stderr=${workerStderr.slice(0, 500)})`
        ));
    });
});

修复：worker 顶层异常统一走 IPC 上报

worker.cjs 顶层有两处 throw（DSH_DIALOG_TITLE 为空 / process.send === undefined），会绕过 IPC 直接退出，加上兜底：

复制

process.on("uncaughtException", (err) => {
    try { send({ kind: "error", message: err?.stack ?? String(err) }, () => process.exit(1)); }
    catch { console.error(err); process.exit(1); }
});
process.on("unhandledRejection", (reason) => {
    try { send({ kind: "error", message: String(reason) }, () => process.exit(1)); }
    catch { console.error(reason); process.exit(1); }
});

这样即使原生崩溃仍捕不到（JS 层局限），至少 JS 层异常和 IPC 缺失从「静默退出」变成「可上报的 error 消息」，用户下一次再报错就能看到 (code=...) 了。

五、问题 2：readUtf16 在 U+XX00 字符处截断（确认为代码 bug）

这是本次排查的意外收获，与官方 #563 / #580 同类，且本机已复现确认。

worker.cjs 中 readUtf16 用 bytes[end] !== 0 判定 UTF-16LE 字符串结束，只检查了低字节：

复制

// 修复前（有 bug）：开 = U+5F00，LE 编码为 00 5F
// 低字节 00 被误判为字符串结束 → 路径提前截断
function readUtf16(koffi, address) {
    const bytes = Buffer.from(koffi.view(address, 32768));
    let end = 0;
    while (end + 1 < bytes.length && bytes[end] !== 0) end += 2;
    return bytes.toString("utf16le", 0, end);
}

问题本质：开（U+5F00）这类 U+XX00 字符，其 UTF-16LE 编码是 00 5F（低字节为 0x00）。扫描循环遇到低字节 0x00 就以为字符串结束了，导致包含此类字符的路径被截断。本机实测：旧逻辑把 C:\workspace\... 截断为 C:workspace，双字节判定后完整返回。

修复：双字节 NUL 判定

复制

// 修复后：bytes[end]===0 且 bytes[end+1]===0 才视为 NUL
function readUtf16(koffi, address) {
    const bytes = Buffer.from(koffi.view(address, 32768));
    let end = 0;
    while (end + 1 < bytes.length && !(bytes[end] === 0 && bytes[end + 1] === 0)) end += 2;
    return bytes.toString("utf16le", 0, end);
}

六、修复方案汇总（5 条，已本地验证）

#	方案	说明
1	exit 错误携带 code/signal/stderr	诊断基础，四种退出原因可区分
2	worker 顶层异常统一走 IPC 上报	无 IPC 时落 stderr，不再静默退出
3	启动超时 watchdog（10s）+ 自动重试一次	spawn 后 1s 内未发消息即退出时重启 worker，消化瞬时故障
4	win32 启动时 koffi 预检，失败自动降级 browse 后端	browse 为纯 `node:fs` 目录浏览，任何环境可用，降级成本极低
5	`readUtf16` 双字节 NUL 判定	修复 U+XX00 字符截断，详见第五节

七、当前状态与后续

本地补丁：已应用到 npm 全局安装（含 .bak 备份），用户重启 dsh web 后验证中。
结论：根因是环境性/瞬时性的系统 DLL 加载故障（已自愈），但排查过程确认了 worker 诊断信息缺失与 readUtf16 截断两个代码 bug，修复后同类问题将「可见、可诊断、可自愈」。
关联 issue：#563（中文路径截断）、#580（UTF-16 截断，附 cherry-pick 修复）、#768（Node 24 + koffi 3.1.x 在 Win11 26200 兼容问题）。