Windows 上「打开方式」永远显示「无法获取应用列表」：单个 shell handler 的 GetName/GetUIName 返回 E_FAIL 就会让整个应用列表作废

[snmtg1008]

摘要

Windows 桌面版上，Presented 文件卡片的「打开方式」下拉永远显示「无法获取应用列表」，
而同一台机器上目录级的 /open-in-app/apps 路由是正常的（返回已安装应用列表）。

根因：文件级枚举走的是另一条链 —— session.workspacePathApplications → nativeFileApplications →
Windows 分支用 PowerShell + Add-Type 现场编译 C#，通过 SHAssocEnumHandlers 枚举注册的 shell handler。
其中对 IHandler.GetName / GetUIName 的调用没有任何容错：

Visit(path, delegate(IHandler handler) {
  string id, name;
  handler.GetName(out id); handler.GetUIName(out name);   // 无 try/catch；E_FAIL 直接冒泡
  if (!seen.Add(id)) return;
  …
});

只要注册表里存在一个这两个方法返回 E_FAIL 的 handler（本机是一个写字板 WORDPAD 遗留关联项），
异常就会冒泡，整个 List() 失败 → nativeFileApplications 抛错 → 前端把 null 当作 failed →
显示 path.appsError（「无法获取应用列表」）。ASCII 与中文路径同样受影响，与路径编码无关。

环境

项	值
操作系统	Windows（NTFS，build 26200）
桌面版	DeepSeek Harness Desktop 0.17.2
内核	@deepseek-ai/dsh@0.1.7-rc.1（打包版 deepseek-harness-pkg@0.1.7-alpha.2）
包	@deepseek-ai/dsh-native-command@0.1.7-rc.1
Node	v24.20.0

复现

import { nativeFileApplications } from '@deepseek-ai/dsh-native-command'
await nativeFileApplications('C:\\path\\to\\any.txt', new AbortController().signal)

抛：

Exception calling "List" with "1" argument(s): "Error HRESULT E_FAIL has been returned from a call to a COM component."
FullyQualifiedErrorId : COMException

定位过程

1. SHAssocEnumHandlers 本身是好的 —— 单独调用（同样的 IID 与签名）对所有扩展名都返回 OK(enum)；
2. 把 IHandler 的方法临时改成 [PreserveSig] int 逐个读 HRESULT，坏 handler 立刻现形：

.txt [3] GetName hr=0x80004005 val=null ; GetUIName hr=0x80004005 val=null ;
         GetIconLocation hr=0x00000000 val=C:\Program Files\Windows NT\Accessories\WORDPAD.EXE

0x80004005 即 E_FAIL。注意同一项的 GetIconLocation 是成功的 —— 坏的是 GetName / GetUIName 这两个。

影响链（为什么用户看到的是「无法获取应用列表」而不是空列表）

1. nativeFileApplications 抛错 →
2. dsh-api-session-controller 的 workspacePathApplications 包成 RemoteError('gateway/internal') 抛出 →
3. dsh-client-ui-open-in-app 的 applications() catch 后 return null →
4. 该 hook 置 failed: apps === null，菜单渲染出 path.appsError。

注意对比：该方法开头 if (!this.canOpenPath()) return [] —— 空数组不会显示这条错误。
所以「无法获取应用列表」必然是抛错路径，这一点可以作为排查判据。

建议修复

给每次 handler 读取加容错，坏 handler 跳过而不是终止整个枚举：

 Visit(path, delegate(IHandler handler) {
   string id, name;
-  handler.GetName(out id); handler.GetUIName(out name);
+  try { handler.GetName(out id); } catch (Exception) { return; }   // 无名者无法被启动，跳过
+  if (id == null || id.Length == 0) return;
+  try { handler.GetUIName(out name); } catch (Exception) { name = id; }
+  if (name == null || name.Length == 0) name = id;
   if (!seen.Add(id)) return;

等价做法是把 IHandler.GetName / GetUIName 声明改成 [PreserveSig] int 并显式检查 HRESULT ——
同文件的 IconData(handler) 已经用 try/catch 做了这种容错（注释写着 "Missing icon resources do not make
the application unusable."），说明这套策略是本项目接受的风格，只是没覆盖到 GetName / GetUIName。

另外建议给 OpenRegistered（同一 C# 里另一处 Visit 回调）加同样的跳过逻辑，
否则一个坏关联会让「用 X 打开」也一起失败。

附：定位用的最小探针（PowerShell 5.1，需 -STA）

Add-Type -ReferencedAssemblies System,System.Core -TypeDefinition @'
using System; using System.Runtime.InteropServices; using System.Text;
public static class Walk {
  [ComImport, Guid("973810ae-9599-4b88-9e4d-6ee98c9552da"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  public interface IEnumHandlers { [PreserveSig] int Next(uint c, out IHandler h, out uint f); }
  [ComImport, Guid("f04061ac-1659-4a3f-a954-775aa57fc083"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  public interface IHandler {
    [PreserveSig] int GetName([MarshalAs(UnmanagedType.LPWStr)] out string n);
    [PreserveSig] int GetUIName([MarshalAs(UnmanagedType.LPWStr)] out string n);
    [PreserveSig] int GetIconLocation([MarshalAs(UnmanagedType.LPWStr)] out string p, out int i);
    [PreserveSig] int IsRecommended();
  }
  [DllImport("shell32.dll", CharSet = CharSet.Unicode, PreserveSig = false)]
  static extern void SHAssocEnumHandlers(string ext, uint filter, out IEnumHandlers handlers);
  public static string WalkIt(string ext) {
    var log = new StringBuilder(); IEnumHandlers hs;
    SHAssocEnumHandlers(ext, 0, out hs);
    int i = 0;
    while (true) {
      IHandler h; uint f; int hr = hs.Next(1, out h, out f);
      log.Append("[" + i + "] next hr=0x" + hr.ToString("X8") + " fetched=" + f + " -> ");
      if (hr != 0 || f == 0) break;
      string n; int a = h.GetName(out n); log.Append("GetName hr=0x" + a.ToString("X8") + " val=" + (n ?? "null") + " ; ");
      string u; int b = h.GetUIName(out u); log.Append("GetUIName hr=0x" + b.ToString("X8") + " val=" + (u ?? "null") + " ; ");
      Marshal.ReleaseComObject(h); i++; if (i >= 6) break;
    }
    return log.ToString();
  }
}
'@
[Walk]::WalkIt('.txt')

附：本机验证（结果脱敏）

按上面的建议打本机补丁后，同一调用不再抛错，返回该扩展名下的全部已注册 handler
（本机为 21 项；清单与具体应用名此处略去），且默认项被正确标记：

{ "installedHandlers": 21, "defaultResolved": true, "failed": false }

（另注：@deepseek-ai/dsh-native-command@0.1.7-rc.2 —— npm next —— 该处仍未修，
补丁后 L632 仍是 handler.GetName(out id); handler.GetUIName(out name);。）

[PerryLink]

这条与 #7842 / #7860 是同一个子系统——建议合并，而不是各修一半

1. 你指的那一层在哪里

"打开方式"的应用列表由 packages/host/open-in-app/ 提供（该包负责解析与启动外部应用；resolver.ts 里既有 launchDetachedApp（分离启动应用本体），也有交给系统外壳的 shell-open 路径）。⇒ 你说的"枚举应用列表"与"启动选中项"是这条路径上的两步，而枚举失败会让整个下拉变成"无法获取应用列表"。

2. 你这条的诊断价值：枚举与启动是两件事

同一天已有两份报告落在同一条路径上，但症状各不相同：

帖	症状	落在哪一步
#7842	"显示文件位置"静默失败（已 A/B 证实：windowsHide 抑制 Explorer 窗口）	启动（runExplorer）
#7860	"打开文件夹"起了进程但目录不开（同 runner）	启动（同一条）
你这条	下拉永远显示"无法获取应用列表"	枚举（不涉及启动）

⇒ 你这条把范围扩大到了"枚举"这一步，这是前两条没有覆盖的——所以它值得保留为独立报告，但建议明确写一句"这是同一条路径上的第三步"，让维护者一次把这三处一起看。

3. 请补三样（能让"单个 handler 拖垮整个枚举"变成可判定）

1. 那个返回异常的 shell handler 是哪一个（你说是"单个"——把它的名字/CLI 或注册项写出来）；
2. 完整异常原文（GetName/GetUIName 返回了什么、错误码是多少）；
3. 对照实验：把那个应用卸载或改名后，下拉是否恢复列表。若恢复 ⇒ 一个坏条目拖垮整份列表这一点被证实，修法就很明确（逐项容错，跳过失败项而不是整体失败）。

第 3 条是关键：它把"我的机器上不行"变成"枚举必须逐项隔离"这条可验收的要求。

4. 一个建议

无论最终是"逐项容错"还是"修那个 handler"，"读一个条目的元数据失败 ⇒ 整份列表不可用"都是一个应当被修的形状。建议把诉求写成：

枚举应用列表时，单个条目读取元数据失败应被跳过（并可提示），不应使整个列表不可用。

5. 版本提醒

⚠️ 当前最新是 0.1.7-rc.2（tag dsh-v0.1.7-rc.2）；别装 latest（npm 上它仍停在 0.1.5-rc.3，更旧）：

npm i -g @deepseek-ai/dsh@next      # 当前 = 0.1.7-rc.2

一条边界

我确认的是该子系统由 open-in-app 承担、且"枚举"与"启动"是两步（这支撑了"你这条是第三步"的定位）。具体哪个 handler 返回了什么以你补的证据为准——我没有复现枚举失败。

[snmtg1008]

补 PerryLink 要的三样（本机 0.2.0-rc.1 产物，Windows 11 / NTFS / PowerShell 7.6.6）。复现方式：把官方 DshFileAssociations.List() 的写法原样搬进一个探针（同一套 SHAssocEnumHandlers + IHandler.GetName/GetUIName，无 try/catch），另加一个逐项隔离版做对照。

1. 坏 handler 是哪一个 —— 不止一个，而且不止写字板

扩展名	坏项在枚举序列中的序号	GetIconLocation 给出的路径	IsRecommended
.txt, .docx	#2	C:\Program Files\Windows NT\Accessories\WORDPAD.EXE	0
.txt, .md, .json, .pdf, .png, .docx	#17–#22（随扩展名浮动）	<steam-library>\steamapps\common\apex legends\r5apex.exe	1
.md, .json, .pdf, .png, .docx	#22–#27	同上 WORDPAD	1

⇒ 本机至少是两族坏 handler：一个写字板遗留项，一个 Apex Legends 的关联项（后者我原报告里没提到，是这次探针才发现的）。共同点很关键：GetName / GetUIName 返回 E_FAIL，但 GetIconLocation 正常 —— 所以图标出得来、名字出不来，这也解释了为什么只有列表整体失败而没有更具体的报错。

2. 完整异常原文

COMException: Unexpected HRESULT has been returned from a call to a COM component.
HRESULT: 0x80004005 (E_FAIL)
抛出点: handler.GetName(out id) / handler.GetUIName(out name)

按官方 List() 的写法（无 try/catch）跑：.txt .md .png .json .pdf .docx 六个扩展名全部抛异常 —— Visit() 里 Marshal.ThrowExceptionForHR 之前的调用栈立刻中断 → List() 失败 → 前端拿不到列表。与扩展名无关，只与"关联列表里存在坏项"有关。

3. 对照实验：逐项隔离

我没有卸载或改名任何注册项（避免改用户系统），改为把同一批 handler 逐项 try/catch：

扩展名	逐项隔离结果
.txt	ok=21 / bad=3
.md	ok=21 / bad=2
.png	ok=26 / bad=2
.json	ok=21 / bad=2
.pdf	ok=23 / bad=2
.docx	ok=21 / bad=3

⇒ 坏项被跳过后，列表完整可用（21–26 个应用）。「单个条目读取元数据失败 ⇒ 整份列表不可用」由此成立，修法就是逐项隔离。你提的诉求措辞我完全同意。

4. 一条时间线：同一路径上「启动」那一步刚修了，「枚举」这一步没修

0.2.0-rc.1 的 release note 里有：

修复 Windows 中「在文件资源管理器中打开」或定位文件可能打开隐藏窗口、操作无响应的问题。 @yudshj

对应的是 #7842 / #7860 的启动步骤（runNativeCommand 的窗口可见性改由调用方显式传 hidden / visible，不再一律 windowsHide: true）。

但枚举这一步没有被覆盖：0.2.0-rc.1 里这段实现已挪到 @deepseek-ai/dsh-native-command，lib/index.js 的 List() 仍是

handler.GetName(out id); handler.GetUIName(out name);   // 无 try/catch

同一路径、两步，这次只修了后一步。建议维护者这次把两处一起看 —— 否则"打开方式"下拉仍会在这类机器上永远显示「无法获取应用列表」。

（探针脚本逐行对应官方 List() 的写法，可复现；未修改任何注册表项。）

[snmtg1008]

等一下，ai跑完就直接回复了，我看下为啥会有apex英雄在这里面

[snmtg1008]

补一条对上一帖的更正 —— 我把那个坏项的来源查清了，它并不是"关联了这些扩展名"。

它不是被关联到 .txt/.png/…，而是注册成了"万能打开方式"

HKEY_CLASSES_ROOT\Applications\r5apex.exe\shell\open\command
  (Default) REG_SZ "g:\steamlibrary\steamapps\common\apex legends\r5apex.exe" "%1"

该项下只有 shell 子树，没有 SupportedTypes。Windows 的规则是：Applications\<exe> 缺 SupportedTypes 时，该应用被视为能打开任意文件类型，于是它出现在每一个扩展名的 handler 枚举里（官方代码用 afFilter = 0，不过滤，全量返回）—— 这解释了为什么六个扩展名全部命中同一个游戏 exe。

同机两处旁证：这类项是安装器留下的

HKEY_CLASSES_ROOT\Valve.Source\shell\open\command              → ...\apex legends\r5apex_dx12.exe
HKEY_CLASSES_ROOT\discord-475006012840083466\shell\open\command → ...\apex legends\r5apex_dx12.exe

前者是 Steam 的 Source 关联被游戏安装覆盖，后者是 Discord 的游戏集成建的 ProgID。

而 WORDPAD 那一族来自通配列表：

HKEY_CLASSES_ROOT\*\OpenWithList\WordPad.exe

为什么这两个 handler 的 GetName / GetUIName 会 E_FAIL

HKCR\Applications\r5apex.exe 下只有 shell\open\command，没有任何 FriendlyAppName 之类的元数据（reg query /s 的全部输出就是那一个值）。GetUIName 拿不到本地化名 → E_FAIL；而 GetIconLocation 仍能从 command 里的 exe 取到图标 → 表现为"图标有、名字没有"。

对结论的影响：加强了

这两族坏项的共同点不是"某个软件有问题"，而是残缺 / 被覆盖的 handler 注册项（shell\open\command 在、元数据不在）。也就是说：任何安装器留下的残缺 Applications\<exe> 项，都能把整份「打开方式」列表打成「无法获取应用列表」 —— 这更加说明修法只能是逐项隔离，不可能靠逐个去修注册表。（本机枚举到的其它 handler 里，GetIconLocation 对坏项都仍可用，所以"跳过失败项"完全够用。）