[补充 #10192/#13004] error 32 的「cwd 继承型」占用：豆包输入法实例 + 误导文案 + Restart Manager 建议

[yufeng-liang]

这是对 #10192 和 #13004 的补充，不是又一份「我也遇到 error 32」的重复报告。这两帖已经把 FILE_SHARE_DELETE 机制、最小复现、quitAndInstall() 时序竞态、去掉整目录改名等修法讲得很完整，本文不重复展开，只补充本机实测到的新的占用者类型、失败提示的行为差异，以及一条更具体的可落地建议。

• #10192 Windows 桌面端：安装目录被第三方进程占用时更新必然失败（搜狗输入法，含 share mode 扫描与完整修法）
• #13004 应用内更新失败：error 32 ×10，quitAndInstall() 时序竞态

1. 环境与结论速览

项	值
版本	0.2.2-rc.1 → 0.2.2-rc.2（安装包 299,659,528 B）
系统	Windows 10.0.26340，H 盘 NTFS，非默认安装路径 H:\DeepSeekHarnessDesktopOfficial
失败	11:55:38 / 11:58:23 / 12:08:06 共三次，MoveFileExW 重试 10 次全部 Windows error: 32，Restoration error: 0
结果	结束占用进程后重装成功，主程序 FileVersion 0.2.2-rc.2，目录 7895 个文件完整

2. 增量一：第二个输入法厂商，而且是「cwd 继承型」占用

用 Sysinternals 句柄工具扫描目录：

> handle64.exe -nobanner -accepteula DeepSeekHarnessDesktopOfficial
ImeWatchdog.exe  pid: 12444  type: File  58: H:\DeepSeekHarnessDesktopOfficial

占用者是豆包输入法的常驻看门狗 C:\Program Files\DoubaoIME\bootstrap\ImeWatchdog.exe，从 2026-11-11 21:22:34 一直持有到 11-12 12:16（约 15 小时），期间三次安装全部撞上。与 #10192 的搜狗 SOGOUSmartAssistant.exe 是不同厂商、不同组件 —— 说明「输入法 / IME 类常驻进程」是这类故障的高频来源，不是个例。

更值得注意的是它为什么会持有这个目录：既不是主动打开，也不是目录监视，而是 CreateProcessW 的 lpCurrentDirectory 传 NULL 时继承了父进程的 cwd（内核里表现为 PEB → RTL_USER_PROCESS_PARAMETERS → CurrentDirectory.Handle 这个常开句柄）。两条实测佐证：

1. 豆包输入法在 21:22:28~21:23:10 刚被升级重写（unins000.*、bootstrap、versions），watchdog 启动于 21:22:34，正好落在升级窗口内；
2. 结束该进程后它自动重启（新 PID 32956），同一个句柄号 0x58 指向的却是 C:\Program Files\DoubaoIME\versions\v1.1.1.2，不再碰 H 盘目录 —— 说明 cwd 完全由启动它的父进程决定，程序本身并不关心自己在哪个目录；否则重启后仍会去打开它。

也就是说这类占用没有固定目标、不可预测：任何从「当前目录恰好是安装目录」的会话里被拉起的常驻进程，都会留下一个长期的目录句柄。用户侧靠「关掉 dsh、关终端、以管理员重试」基本自查不出来。

顺带一提：本机按文件逐个做 FileShare.None 独占打开 400 个文件全部成功，ACL 正常（Administrators FullControl / Authenticated Users Modify）、磁盘 Healthy。被锁的只是目录对象本身，这与 #10192 第 3 节 share mode 扫描的结论一致，只是换了个触发源；也解释了为什么「检查 exe 有没有被锁」会误判。

3. 增量二：失败提示不是「静默」，而是误导

#10192 记录的是「失败静默、无对话框」。本机这条路径上是有弹窗的 —— 下面是 11:58:23 那次失败的原始截图，弹窗后面还能看到安装进度停在 96%，与日志时间戳一致：

弹窗原文：

无法替换安装目录。

32: 另一个程序正在使用此文件，进程无法访问。

请检查安装目录的访问权限，关闭占用其中内容的程序后重新运行安装器。如仍失败，请复制错误详情。

下方还有「显示详情 / 复制错误信息 / 确定」按钮，以及「完整错误报告已保存到 C:\Users\15778\AppData\Local\@deepseek-aidsh-desktop-...\directory-failure-20261112-115823.log」。

其中「请检查安装目录的访问权限」是误导：实际原因是共享冲突（占用者未给 FILE_SHARE_DELETE），与权限毫无关系，按提示去查 ACL / 提权运行都是白费功夫。后半句「关闭占用其中内容的程序」方向是对的，但没告诉用户是哪个进程，普通用户也无从自查。两帖合起来看，失败反馈在不同版本 / 路径下行为并不一致：有的静默、有的弹窗但说错原因。建议统一收敛成「安装目录被其它进程占用」并直接列出占用者。

4. 增量三：一条更具体的可落地建议（Restart Manager）

已有两帖都建议「给出哪个进程占用了目录」。补充一个 Windows 原生、无需额外依赖的实现路径 —— Restart Manager API：

RmStartSession(...)                                       // 开启会话
RmRegisterResources(h, n, files, 0, NULL, 0, NULL)        // 注册安装目录下的文件 / 目录
RmGetList(h, &needed, &count, rgAffectedApps, &reasons)   // 直接拿到占用进程 PID 与名称
RmEndSession(h)

安装器在 MoveFileExW 返回 32 后调用它，就能在弹窗里写明「ImeWatchdog.exe (PID 12444) 正在占用安装目录」，并提供「结束后继续 / 重启后重试」。这比单纯把 10 次重试改成「等待目标 PID 消失」更通用：后者只覆盖 dsh 自己没退完的时序竞态（#13004），覆盖不了第三方常驻进程。

另外 #10192 评论区给出的「以 DELETE 访问 + FILE_SHARE_READ|WRITE|DELETE(7) 试开目录，判断能否重命名」非常实用，建议直接作为安装前的前置检查：失败时立刻给出可读原因，而不是等 10 次重试全部失败后才落一份日志。

5. 肯定一下现有行为

三次失败 Restoration error: 0 都干净回滚，旧版本文件时间戳未被改动、无 .old-{GUID} 残留，用户数据（在 %LOCALAPPDATA%\deepseek-harness）未受影响；成功那次安装器正常完成替换并清理了自建备份。原子替换 + 回滚这套设计本身没问题，缺的只是失败时的诊断信息。

6. 可提供的补充材料

• 三份 directory-failure-*.log 原文
• handle64 -p 12444 与重启后新实例的完整句柄列表
• 升级前后版本信息、目录清单

需要的话我可以贴到评论里。感谢 #10192 / #13004 作者的详细报告，本机定位过程基本是照着这两帖的思路走的 🙏