dsh自动更新会失败

[ziye-shamus]

我这里dsh自动更新总是失败 每次都是根目录被虚空锁定 一直占用然后更新就报32 查不出任何问题 每次只有重启电脑 然后在没有启动过dsh的时候开始安装更新包才行 有解决办法嘛？每次都这样挺麻烦的

[Muguett-DBY]

如果这里的 32 是 Windows 错误码，它对应 ERROR_SHARING_VIOLATION，说明仍有文件被进程占用。你说的「启动过 DSH 后就失败，重启后能安装」和句柄没有释放的情况相符，具体是谁占用还需要现场看。微软错误码说明

下次失败时，可以先保留报错窗口，用系统自带的资源监视器查一下。

1. Win + R 输入 resmon，打开 CPU 页，展开「关联的句柄」。
2. 搜索报错中的安装目录名或失败文件名，记下进程名、PID 和命中的路径。
3. 保存工作并正常退出对应程序，再重试更新。若是终端或编辑器占用安装目录，也要先退出那个工作目录。

我核对了目前主线安装器，目录操作已经对 5、32、33 做了重试，失败时会保存 directory-failure-*.log，里面有源路径、目标路径和错误码。方便的话补一下 DSH 版本、报错里的这几项，以及查到的进程名/PID，用户名可以打码。这样才能继续判断卡在目录切换的哪一步。目录重试 · 失败日志

[ziye-shamus]

正好又有更新了 我试试看 如果有问题再回复你

[ziye-shamus]

还是同样问题 这个上次更新的时候就让ai帮我找了 找来找去都没有找到有一个明确的进程 只知道结果是被占用 无法修改整个文件夹

我按你的办法查了下 真有进程。。是qq拼音的 一个是qq拼音用户中心一个是剪贴板 好怪啊 怎么会扯到这两个的。。因为我在dsh里面用的它的缘故嘛？

[ziye-shamus]

感谢大佬支招 结束对应进程之后就能成功安装了

[Muguett-DBY]

太好了，能更新就好！至于为什么会是输入法或剪贴板进程，单凭进程名还不能确认是否因为在 DSH 里使用了输入法。

一种可能的机制是某个进程仍把安装目录作为当前工作目录；Windows 在该进程运行时会阻止移动或重命名这个目录（微软文档）。这只是例子，不代表你这里一定是这种情况。下次如果再出现，可以留意资源监视器里命中的是目录本身还是某个具体文件，分享路径时把用户名遮住就好。

[ziye-shamus]

就刚才的 我是只搜索了我安装dsh的根目录名称x:\deepseek 这样 然后跳出了两个进程关联 我直接结束两个 重新搜索就没有关联了 不过我后续是直接跑的安装包 不确定如果我用dsh的自动更新会不会重新触发这个问题 可以等以后更新了再试试看

[wlsoft2006]

我也是每次都只能下载重新安装，但是版本不是最新的，只能重启电脑再点击升级，撞大运才能安装最新版本！
问题是：点击安装更新重启就什么都没有了
win11

[ziye-shamus]

我之前是两个版本全都这样ai完全查不到是什么在占用 只能重启后趁着还没跑过dsh时候安装 才能成功

[ziye-shamus]

我按照大佬说的流程查了一下 发现是被qq拼音输入法的进程占用了 结束掉后就能正常安装了

[anylink]

这个问题的根因已经在 #13214 定位到源码层，完整分析见：
#13214 (comment)

简要说明：

1. apps/desktop/src/update-coordinator.ts:218 调用 this.updater.quitAndInstall(true, true)。
2. electron-updater 的 BaseUpdater.quitAndInstall() 内部是 先 install()（同步 spawn NSIS 安装器）、再 setImmediate(() => app.quit())。
3. 而 apps/desktop/src/main.ts:733-749 在 spawn 之前只做了 await Promise.all([backend.stop(), stopOperationReports()])——停的是 Host。main / gpu-process / utility(NetworkService) / renderer 这四个进程没有任何等待逻辑，它们只会在 app.quit() 之后才退出。
4. 所以安装器执行 MoveFileExW(InstallDir → InstallDir.old-{GUID}) 的那一刻，这四个进程仍映射着 DeepSeek Harness.exe 与 resources\app.asar。

你遇到的 32（ERROR_SHARING_VIOLATION） 和 #13214 的 5（ERROR_ACCESS_DENIED） 是同一件事的两种表现：取决于占用者持有的是文件句柄还是目录/工作目录句柄。重试 10 次间隔很短，撑不过应用退出。

「重启电脑后、没启动过 DSH 时能装成功」正好印证这一点：那一刻安装目录没有任何持有者。

补充一个现场可用的判定方法（无需第三方工具）：

Win + R → resmon → 切到「CPU」页 → 展开「关联的句柄」→ 在搜索框输入 DeepSeek Harness，可以直接列出占用该目录的进程名、PID 和句柄路径。也可以在失败后立刻查询安装目录的持有者，确认是 DSH 自己的进程还是编辑器/终端的句柄。

本机对照数据：应用运行时查询安装目录，返回的 5 个持有者全是 DSH 自身进程；全部退出后首次 MoveFileExW 即返回 0。installer-logs\\directory-failure-*.log 累计 13 份，全部 error 5、Attempts ×10、Restoration error: 0。