[Bug] Windows 上单个损坏的 shell 关联 handler 会让原生打开能力全部消失（应用列表 500）

[ftdx112]

[Bug] Windows 上单个损坏的 shell 关联 handler 会让原生打开能力全部消失（应用列表 500）

• 组件：@deepseek-ai/dsh-native-command（主因）、@deepseek-ai/dsh-client-ui-deliverables（放大与不可观测性）、@deepseek-ai/dsh-host-open-in-app
• 版本：@deepseek-ai/dsh@0.2.0-rc.2（npm 发行版，非源码 checkout）
• 平台：Windows 10（10.0.19041），PowerShell 5.1，profile web，dsh web 绑定 127.0.0.1:3080
• 严重程度：高——交付卡片、变更对比页、会话头部「Open In…」以及文档预览的全部原生控件同时失效，且无任何日志，只能靠反向工程定位

摘要

dsh-native-command 的 Windows 应用枚举（DshFileAssociations.List）对每个已注册 shell handler 直接调用 IHandler.GetName()，没有异常保护。只要机器上存在一个登记残留但已损坏的 handler（例如某个已卸载程序留下的 HKCU\Software\Classes\Applications\<app>.exe 记录），GetName() 就抛 E_FAIL (0x80004005)，导致：

1. 整个枚举失败、powershell.exe 退出码 1、无 stdout；
2. nativeFileApplications() 抛出 → session.workspacePathApplications() 抛 gateway/internal；
3. /api/present.open（GET 应用列表分支）返回 500；
4. 前端据此不渲染任何原生控件 —— 而实际上同一台机器的默认应用打开本身完全正常。

用户可见结果：「无法获取本机应用，无法用默认应用打开交付物」，但侧边栏预览始终可用。

复现

任选一个磁盘上存在的文件：

node -e "import('file:///C:/Users/<you>/AppData/Local/npm-cache/_npx/<hash>/node_modules/@deepseek-ai/dsh-native-command/lib/index.js').then(async m => { try { const a = await m.nativeFileApplications('D:\\path\\to\\file.json', new AbortController().signal); console.log('OK', a.length); } catch (e) { console.log('FAIL', e.message); } })"

失败时的真实报错（被 output() 或 PowerShell 的 $ErrorActionPreference='Stop' 转成一个失败进程）：

Command failed: powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass -File C:\Users\<you>\AppData\Local\Temp\dsh-native-command-XXXX\associations.ps1
使用"1"个参数调用"List"时发生异常:"对 COM 组件的调用返回了错误 HRESULT E_FAIL。"
    + FullyQualifiedErrorId : COMException

逐 handler 插桩后可精确定位到具体是哪一个损坏：

enum = S_OK
--- handler #1  name=C:\WINDOWS\system32\NOTEPAD.EXE
--- handler #2  name=d:\Microsoft VS Code\Code.exe
--- handler #3  name=C:\Program Files\7-Zip\7z.exe          ← 正常，保留
--- handler #4  name=C:\Program Files\7-Zip\7zFM.exe        ← 正常，保留
--- handler #5  name=<GetName THREW>  iconHint=D:\Axure RP 8\AxureRP8.exe
                               ^^^ 0x80004005 E_FAIL
--- handler #6 … 全部正常

根因链

1. dsh-native-command / WINDOWS_ASSOCIATIONS 的 List()

   Visit(path, delegate(IHandler handler) {
     string id, name;
     handler.GetName(out id); handler.GetUIName(out name);   // ← 无 try/catch
     …
   });

   对比同一个源文件里的其它调用点都是有保护的：IconData() 用 try { handler.GetIconLocation(…) } catch (Exception) { … }（约 585–609 行），而这个循环里没有。一个坏 handler 就能终止整张列表。

2. windowsFileApplications() 把该 C# 放进 $ErrorActionPreference = 'Stop' 的脚本执行；异常变成 terminating error，powershell.exe 退出码 1、stdout 为空，runNativeCommand（execFile）reject。

3. dsh-host-open-in-app / dsh-api-session-controller：探测路径上的 output() 把失败静默吞成 null（开菜单按钮因此永远不出现），而文件级查询 nativeFileApplications 直接抛。

4. dsh-client-ui-deliverables 路由（registerPresentOpen）把一切异常压成一句纯文本：

   catch (error) {
     request.signal.throwIfAborted();
     return new Response("Presented file unavailable.", { status: failureStatus(error) });
   }

   failureStatus() 只把 ENOENT/ENOTDIR/not-found 映射为 404，其它一律 500，且不写任何日志、不回传 cause。这直接导致排查成本极高：浏览器只看到 500，服务端控制台一行都没有。

期望行为

1. 单个 handler 的失败被隔离：GetName/GetUIName/GetIconLocation/IsRecommended 逐调用 try/catch，坏条目跳过而不是让整个列表失败；
2. 应用列表查询失败不应导致原生控件完全消失——建议退化为「不显示应用菜单，但保留默认应用打开/在文件管理器中显示」，因为 openNativeAssociatedPath / revealNativePath 根本不走这条枚举；
3. 路由把 cause 记入 host 日志（或至少回传一个可区分的错误码），而不是吞成 500 "…unavailable."。

证据

• 机器上两个坏 handler 的来源（均为已卸载/失效程序残留）：
  • HKCU\Software\Classes\Applications\AxureRP8.exe\shell\open\command = "D:\Axure RP 8\AxureRP8.exe" "%1"，而 D:\Axure RP 8 已删除；
  • HKCU\Software\Classes\md_auto_file\shell\edit\command = "C:\Program Files\Microsoft Office\root\Office16\Winword.exe" /n "%1"，该 64 位路径不存在（真实 Word 在 Program Files (x86)）。
• 影响面：.json、.md、.ini 等所有扩展名都会命中（SHAssocEnumHandlers 会把这类登记注入每个扩展名的枚举）。
• 对照实验（同一进程、同一文件）：
  • 逐调用 try/catch 的版本 → handlers=15 broken=0，正常返回 14 条应用；
  • 原版 List() → 抛 0x80004005。
• 清理这两个残留后：.json 与 .md 的 nativeFileApplications() 均恢复 OK (14 apps)，而 openNativeAssociatedPath() / revealNativePath() 前后都是 OK —— 说明坏的只有枚举，不是打开。

建议优先级

1. List() 内 GetName/GetUIName 加重试或 try/catch（核心修复，两行级别）；
2. OpenRegistered() 里的 handler.GetName（同上）；
3. dsh-api-session-controller.SessionController.workspacePathApplications() 捕获异常返回部分/空列表，或把枚举失败与「无桌面」区分开；
4. /api/present.open 与 /api/changes.open 记录 cause。

附：用于定位的插桩脚本（可作回归测试素材）

param([string]$TargetPath)
Add-Type -ReferencedAssemblies System,System.Core,System.Drawing -TypeDefinition @'
using System;
using System.Runtime.InteropServices;
using System.Text;
public static class Trace {
  [ComImport, Guid("973810ae-9599-4b88-9e4d-6ee98c9552da"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  public interface IEnumHandlers { [PreserveSig] int Next(uint count, out IHandler handler, out uint fetched); }
  [ComImport, Guid("f04061ac-1659-4a3f-a954-775aa57fc083"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
  public interface IHandler {
    void GetName([MarshalAs(UnmanagedType.LPWStr)] out string name);
    void GetUIName([MarshalAs(UnmanagedType.LPWStr)] out string name);
    void GetIconLocation([MarshalAs(UnmanagedType.LPWStr)] out string path, out int index);
    [PreserveSig] int IsRecommended();
    void MakeDefault([MarshalAs(UnmanagedType.LPWStr)] string description);
    void Invoke(System.Runtime.InteropServices.ComTypes.IDataObject data);
    void CreateInvoker(System.Runtime.InteropServices.ComTypes.IDataObject data, [MarshalAs(UnmanagedType.Interface)] out object invoker);
  }
  [DllImport("shell32.dll", EntryPoint = "SHAssocEnumHandlers", CharSet = CharSet.Unicode, PreserveSig = false)]
  static extern void EnumHandlers(string extension, uint filter, out IEnumHandlers handlers);
  public static string Run(string path) {
    var log = new StringBuilder();
    IEnumHandlers handlers;
    EnumHandlers(System.IO.Path.GetExtension(path), 0, out handlers);
    IHandler handler; uint fetched; int i = 0;
    while (handlers.Next(1, out handler, out fetched) == 0 && fetched == 1) {
      i++;
      string name = null, icon = null;
      try { handler.GetName(out name); } catch (Exception e) { name = "<THREW 0x" + Marshal.GetHRForException(e).ToString("X8") + ">"; }
      try { int idx; handler.GetIconLocation(out icon, out idx); } catch { }
      log.AppendLine("#" + i + " name=" + name + " iconHint=" + icon);
    }
    return log.ToString();
  }
}
'@
Write-Output ([Trace]::Run($TargetPath))

环境补充

• dsh --version / 包：@deepseek-ai/dsh@0.2.0-rc.2，profile web（bundles：dsh-base、dsh-web-app、dsh-experimental-auto-review）
• 浏览器：同一台机器，loopback 访问 http://127.0.0.1:3080（无 SSH、无 WSL、无容器，SESSIONNAME=Console）
• canOpenNativePath() = true，nativeFileManager() = explorer

[lazybone404]

补充一个不同触发位置的实例，以及一条会影响修法的实测。

环境：Windows 11 build 26200；Desktop 版 DeepSeek Harness 44.0.0，@deepseek-ai/dsh@0.2.0-rc.2。

触发位置与主贴不同：不是 HKCU\...\Applications\<app>.exe，而是扩展名的 OpenWithProgids。HKCU\SOFTWARE\Classes\.html\OpenWithProgids 下的 VisualStudio.html.52587c27（ProgID 本体在 HKLM\SOFTWARE\Classes），指向已卸载的 VS 2022 BuildTools：...\2022\BuildTools\Common7\IDE\devenv.exe，command 为 "...\devenv.exe" /dde，带 ddeexec（Application=VisualStudio.17.0）。

症状：.html 与 .htm 的「打开方式」列表为空、回退成只有「显示文件位置」；其余扩展名全部正常（.txt 15、.json 16、.pdf/.docx/.xlsx/.pptx/.zip/.csv 各 17、.png 19）。

定位（同主贴的逐 handler 插桩）：.html 共枚举出 18 个 handler，第 4 个（index 3）的 GetName 与 GetUIName 均抛 E_FAIL，其余 17 个正常，枚举本身正常结束（Next 返回 S_FALSE）。

受控验证：只从 HKCU 的 OpenWithProgids 删除这一个值，.html 与 .htm 立刻恢复（17 个应用，默认 Chrome），其余 17 个 handler 不变；删除前后可用条目数 17 → 17，即被移除的正是那条读不出名字的条目。

一条会影响修法的实测：「目标 exe 不存在」本身不足以复现。
构造了 5 种合成注册——OpenWithProgids 指向不存在的 exe、悬空 ProgID 引用、空的 shell\open\command、镜像 DDE 结构 + 不存在的 exe、HKCU\...\Applications\DshNoSuchApp.exe + 不存在的 exe——shell 要么直接跳过该条目，要么让 GetName 正常返回那个不存在的路径，五种都不触发 E_FAIL。所以触发条件比「注册残留」更窄，具体成因未能确定。这也意味着不能靠「先检查 exe 是否存在」来规避，逐 handler 隔离异常才是对的。

版本差异：我这边的表现不是控件完全消失，而是应用列表为空、回退到「显示文件位置」，可能与入口（交付卡片 / desktop 版）有关。