Windows：残留的文件关联处理器返回 E_FAIL，导致 DSH 整个“打开方式”列表失败（IAssocHandler::GetName）

[EmotionTowel]

问题概述

在 Windows 11 24H2/25H2 中，Windows 移除 WordPad 后遗留了一个失效的文件关联处理器。这个处理器会导致 DSH 对所有文件类型的“打开方式”查询失败。

实际调用过程如下：

1. SHAssocEnumHandlers 成功返回处理器枚举器；
2. IEnumAssocHandlers::Next 成功返回多个有效处理器，包括 Typora；
3. 枚举到残留的 WordPad 处理器时，IAssocHandler::GetName / GetUIName 返回 E_FAIL；
4. 当前 @deepseek-ai/dsh-native-command 没有隔离单个处理器的 COM 异常，导致整个应用列表查询被中断。

在 Web UI 中表现为：

• 显示“无法获取应用列表”；
• 只显示“显示文件位置”；
• 不显示默认应用或应用列表。

“使用默认应用打开”本身仍然正常，因为该路径直接交给 Explorer，不需要枚举全部文件关联处理器。

测试环境

• DSH：0.1.7-rc.2
• 包：@deepseek-ai/dsh-native-command
• Windows：Windows 11 25H2，Build 26200.9457，x64
• 交互式桌面会话
• 分别测试 Windows PowerShell 5.1 和 PowerShell 7
• 在 .md、.txt、.png、.exe 上均可复现

残留注册表状态

Windows 11 24H2 移除了 WordPad，但系统中仍保留以下应用注册：

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Applications\WORDPAD.EXE
  FriendlyAppName = @shell32.dll,-22069
  shell\open\command = "C:\Program Files\Windows NT\Accessories\WORDPAD.EXE" "%1"

但目标程序已经不存在：

C:\Program Files\Windows NT\Accessories\WORDPAD.EXE

本机还发现以下 WordPad 残留项：

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Applets\Wordpad
HKLM\SOFTWARE\RegisteredApplications\Wordpad

HRESULT 逐步定位

使用保留每个 HRESULT 的小型 COM 探针，得到：

SHAssocEnumHandlers()      -> S_OK
IEnumAssocHandlers::Next()  -> S_OK
正常处理器                  -> S_OK
残留 WordPad GetName()     -> E_FAIL (0x80004005)
残留 WordPad GetUIName()   -> E_FAIL (0x80004005)

以 .md 为例，在失败之前已经成功枚举到：

• WPS Office
• Typora
• 记事本
• 百度网盘
• DevEco Studio
• IntelliJ IDEA
• Sublime Text
• Word

因此，SHAssocEnumHandlers 本身没有失败。真正的问题是：枚举到后面的某一个失效处理器时失败了。

DSH 当前行为

packages/util/native-command/src/file-applications-windows.ts 中的 Visit() 调用每个处理器的回调时，没有隔离单个处理器的 COM 异常：

try {
  visit(handler);
}
finally {
  Marshal.FinalReleaseComObject(handler);
}

List() 随后调用 IAssocHandler::GetName 和 GetUIName。由于这些 COM 方法使用 HRESULT 异常封送，残留 WordPad 处理器的失败会终止整个 PowerShell 查询。

最终错误等价于：

System.Runtime.InteropServices.COMException
HRESULT: E_FAIL (0x80004005)

复现步骤

1. 使用 Windows 11 24H2 或更高版本；
2. WordPad 已被移除，但 Applications\WORDPAD.EXE 注册项仍然存在；
3. 通过 DSH 文件卡片、文档预览或改动文件审查打开任意文件；
4. DSH 调用 nativeFileApplications(path, signal)；
5. 查询被中断，而不是返回前面已经枚举到的有效处理器；
6. 只删除残留的 HKLM\SOFTWARE\Classes\Applications\WORDPAD.EXE 注册项后重新测试；
7. 同一次查询立即返回完整应用列表，并正确标记默认应用。

影响范围

该问题不只影响 Markdown 或 Typora。

只要某个扩展名的处理器列表中包含这个残留 WordPad 处理器，查询就可能失败。在测试机上，以下扩展名都在失败位置中断：

.md
.txt
.png
.exe

同时已确认，问题与 PowerShell 版本无关：

• Windows PowerShell 5.1：失败；
• PowerShell 7：失败；
• 显式初始化 COM STA：失败；
• 旧版 -EncodedCommand 传输方式：失败。

建议修复

将每个 Shell 处理器视为独立项；单个处理器失败时只跳过该处理器：

try {
  visit(handler);
}
catch (COMException) {
  // 残留或未完全卸载的处理器不应让其它应用全部失效
}
finally {
  Marshal.FinalReleaseComObject(handler);
}

也可以只在 List() 中捕获 GetName / GetUIName 周围的 COM 异常。

建议增加回归测试：模拟一个 GetName 返回 E_FAIL 的处理器，并验证后续有效处理器仍然会出现在结果中。

修复行为验证

跳过残留 WordPad 处理器后：

nativeFileApplications("...\\test.md")
  -> 返回 11 个应用
  -> Typora 出现在列表中
  -> Typora 被正确标记为默认应用

在报告者的机器上，删除残留的 WordPad 应用注册后无需修改 DSH 代码即可恢复。因此，这更像是 Windows 升级/卸载后的注册表残留与 DSH 容错不足之间的兼容问题，而不是 Typora 关联注册问题。