[Bug] 「打开方式」列出所有已注册处理器，选中非适用程序后助手进程永久挂起（Windows）

[Tristanash]

[Bug] 「打开方式」会列出所有已注册处理器，选中非适用程序后助手进程永久挂起（Windows）

环境

• DSH Desktop: 0.2.1-rc.2（@deepseek-ai/dsh-desktop，Electron）
• OS: Windows 10 Pro 22H2，内部版本 19045.6466（x64）
• 触发文件: 工作区内的一个 .cmd 与一个 .ps1
• 现象时间: 2026-10-20 02:43（本地时间）

复现步骤

1. 在会话中让助手产出一个 .cmd（批处理）和一个 .ps1 文件，两者都会出现在文件卡片里。
2. 点击卡片上的 打开。
3. 在 DSH 弹出的应用列表里，为 .cmd 选择 Adobe Premiere Pro CC 2019（列表里确实会出现它），为 .ps1 选择 Sublime Text。
4. 观察界面与任务栏。

实际结果

• 界面持续显示 「正在打开…」，永不结束，没有超时也没有错误提示。
• 任务栏出现一个 无法激活、无法关闭 的窗口条目，标题为 Window Dialog。
• 进程树里留下两个僵尸进程：

powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass ^
  -File %TEMP%\dsh-native-command-596ikP\associations.ps1     (→ 打开 .cmd，选择 Premiere Pro)
powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass ^
  -File %TEMP%\dsh-native-command-fmMCzw\associations.ps1     (→ 打开 .ps1，选择 Sublime Text)

两者父进程均为 DeepSeek Harness.exe，存活十余分钟不退出。

期望结果

• 应用列表只列出真正能处理该扩展名的程序（至少把 ASSOC_FILTER_RECOMMENDED 的项排前面）。
• 选中不适用的程序时，应当报错或超时退出，而不是永久挂起。
• 不应在任务栏留下不可交互的顶层窗口。

根因分析

1. 应用列表未做相关性过滤

助手脚本中通过 SHAssocEnumHandlers(extension, 0, out handlers) 枚举处理器，第二个参数 0 表示不做推荐项过滤，因此凡是往系统注册过 shell 集成的程序（例如 Adobe 全家桶、编辑器、压缩软件）都会出现在任何扩展名的候选列表里。用户很容易误选。

2. 用 IHandler::Invoke 直接启动，且外层加了一个「等 Shell 引用计数归零」的排空循环

脚本里的核心逻辑是：

static void WithShellLifetime(Action action) {
  ...
  SHCreateThreadRef(count, out reference);
  SHSetThreadRef(reference);
  SHSetInstanceExplorer(reference);
  int owned = Marshal.ReadInt32(count);
  try { action(); }
  finally {
    if (Marshal.ReadInt32(count) > owned) {
      UIntPtr timer = SetTimer(IntPtr.Zero, UIntPtr.Zero, 10, IntPtr.Zero);
      while (Marshal.ReadInt32(count) > owned) {   // ← 没有超时
        Message message;
        if (GetMessage(out message, IntPtr.Zero, 0, 0) <= 0) throw ...;
        TranslateMessage(ref message);
        DispatchMessage(ref message);
      }
    }
  }
}

action 是 OpenRegistered(path, application)，内部调用 handler.Invoke(data)。

注释里写明了意图：「Shell handlers may return before their asynchronous launch work releases the host」，所以要用引用计数来等异步启动完成。但如果被选中的 handler 启动路径较慢、或者（更常见）它并不真正处理该扩展名，Shell 的线程引用计数就不会回落到基线，while 循环便永不退出——助手进程挂死，调用方（Electron 主进程）拿不到结果，UI 就停在「正在打开…」。

对比测试：同一批文件选择 记事本 打开时，handler 立即返回，助手进程正常退出，无僵尸。

3. 僵尸窗口的来源

SetTimer(IntPtr.Zero, ...) + 该进程 -STA 的消息循环，使这个挂起的 PowerShell 进程持有并显示了一个顶层窗口（窗口类 Static，标题 Window Dialog），在任务栏里表现为一个点不开的条目。

建议修复

1. 过滤候选列表：使用 SHAssocEnumHandlers 的 ASSOC_FILTER_RECOMMENDED（值 1）只展示推荐项，其余折叠到「选择其他应用…」里。
2. 给排空循环加超时（例如 5–10 秒），超时后终止助手并把错误回抛给 UI，而不是无限等待。
3. 改用更稳的启动方式：对「打开」这种场景直接用 ShellExecuteEx（SEE_MASK_NOASYNC）按 AUMID/ProgID 启动，避免走 IHandler::Invoke 后还要等待引用计数。
4. 进程生命周期兜底：DSH 退出或卡片被关闭时，强制结束这些 dsh-native-command-* 助手进程。
5. 助手进程建议加 -WindowStyle Hidden，避免再制造任务栏僵尸窗口。

用户侧的临时绕过（供其他遇到者参考）

• 需要查看文件内容：用记事本打开，或从资源管理器右键打开。
• 需要执行脚本：从资源管理器双击，或用快捷方式直接调用 powershell.exe -File ...。
• 避免在 DSH 的「打开方式」里选择视频/设计类软件。

---

English summary

On Windows, the file-card "Open" flow enumerates association handlers with
SHAssocEnumHandlers(ext, 0, ...) (no ASSOC_FILTER_RECOMMENDED filter), so irrelevant
apps such as Adobe Premiere Pro appear for .cmd. After the user picks one, the helper
(associations.ps1) calls IHandler::Invoke inside a WithShellLifetime drain loop that
spins until the shell thread-reference count returns to its baseline. When the chosen
handler does not release that reference, the loop never exits: the UI stays on
"Opening…" forever, a visible Window Dialog window is left in the taskbar, and the
powershell.exe helper stays alive indefinitely. Choosing Notepad for the same file
returns normally and leaves no zombie.

Suggested: filter handlers to recommended ones, bound the drain loop with a timeout,
prefer ShellExecuteEx for launching, and terminate dsh-native-command-* helpers when
the app exits.

[PerryLink]

列表里出现不相关的程序，是因为枚举时传的过滤器是 0。

packages/util/native-command/src/file-applications-windows.ts:181-185：

static void Visit(string path, Action<IHandler> visit) {
  var extension = Path.GetExtension(path);
  if (extension.Length == 0) return;
  SHAssocEnumHandlers(extension, 0, out handlers);

SHAssocEnumHandlers 的第二个参数是 ASSOC_FILTER：ASSOC_FILTER_NONE = 0，ASSOC_FILTER_RECOMMENDED = 1。传 0 的意思是"把这个扩展名上注册过的所有 handler 都给我"，包括那些只是注册了、并不推荐用于打开的程序；传 1 才是用户双击时系统会优先给出的那批。所以你在 .cmd 列表里看到 Adobe Premiere 不是 DSH 自己拼错了列表，是它主动要了全集。是否真有一个应用把 .cmd 注册成了自己的 handler，那是你机器注册表的状态，值得在报告里附一下 HKCR\.cmd 的实际内容。

这一条和旁边那条 500 是同一个函数的两个出口：:202-204 的遍历体对每个 handler 直接调 GetName / GetUIName，没有逐项 try，所以集合越大、踩到一个坏注册的概率越高。把过滤器换成 1 会顺带减少踩雷面，但真正的修法还是逐项容错。

至于选完之后永久挂起、留下两个 associations.ps1 僵尸进程，我认为是另一个问题，不建议并进这条报告。进程不退出说明那段 PowerShell 侧还在等什么；file-applications-windows.ts:93-97 里确实有一个 Win32 消息泵（GetMessage 循环，靠 timer 退出），选中的程序如果弹出模态窗口就会把它卡在那儿。这个要查得看 associations.ps1 的退出条件，和"列表太宽"是两件事。

如果只能提一条，我建议提"过滤器传了 0 + 遍历无逐项容错"，因为它们在同一段代码里、一次就能改完；挂起那条单独提，附上进程树和选中的具体程序对。

[Tristanash]

抱歉，回复是ai通过浏览我的电脑后用GL进行回复的，此条是手打。我目前遇到的BUG确实严格来说是两个：

1. 扩展名上注册过的handler没有过滤，DSH应该对这种‘选择打开方式’的动作进行过滤，筛选出适合打开的程序或方法。
2. 选择非记事本以外的软件打开，会弹出一个你认为的模态窗口（我说的僵尸窗口），卡住进程，使得DSH认为任务并未执行完成，而这个窗口又卡住了进程不让后续的文件打开。

我自以为第二个问题才是急需修正的问题，因为第一个问题无非就是打开方式不对，最多就是弹乱码或是打开失败、不兼容此文件类型什么的。第一个问题只能算是附带的。我也是第一次在GitHub上发帖，不知道一个post只能贴一个bug的规矩

[Tristanash]

谢谢，位置对得很准，SHAssocEnumHandlers(extension, 0, out handlers) 就是那里。我照你说的在本机补了两组实测数据。

1）HKCR\.cmd 是干净的，没有被任何应用劫持

HKEY_CLASSES_ROOT\.cmd
  (default) = cmdfile
  子键: PersistentHandler = {5e941d80-bf96-11cd-b579-08002b30bfeb}

HKCR\cmdfile\shell\open\command = "%1" %*，标准值。也就是说没有任何程序把 .cmd 写进自己的注册项——列表里那堆东西纯粹是 ASSOC_FILTER_NONE 枚举出来的"全部候选"。

2）filter=0 / filter=1 的实际数量（本机，Windows 10 22H2 19045.6466）

扩展名	ASSOC_FILTER_NONE (0)	ASSOC_FILTER_RECOMMENDED (1)
.cmd	15	0
.ps1	15	1
.txt	15	3

.cmd 那 15 个里包含 Adobe Premiere Pro、Photoshop、Dreamweaver、WPS、IE、画图、Sublime Text、Windows Media Player、WordPad、百度网盘等，确实与文件类型毫无关系。

⚠️ 但这里有个和预期不一样的点：.cmd 用 ASSOC_FILTER_RECOMMENDED 会返回 0 个 handler。所以如果只是把 0 改成 1，.cmd 这类扩展名的"打开方式"列表会整个空掉。修的时候大概需要保留 fallback，比如 recommended 为空时退回默认 handler（或退回 NONE），否则是从"太多"直接跳到"没有"。

3）关于拆报告：同意，挂起确实是另一个问题，混在一起会稀释。我另开一条，会带上：

• 两个 associations.ps1 助手进程的完整命令行与父进程
• 具体配对：Fix-Proxy.cmd → Adobe Premiere Pro CC 2019、Fix-Proxy.ps1 → Sublime Text
• 对照组：同样这两个文件改选 Notepad，助手进程正常退出、无僵尸
• 残留的顶层窗口：类名 Static、标题 Window Dialog，在任务栏里点不开

发出来我 @ 你。

[Tristanash]

挂起问题已按建议单独成条 → #10369 （含两个 helper 的完整命令行、.cmd→Premiere / .ps1→Sublime 的配对，以及选 Notepad 的对照组）。这条继续只讨论「过滤器 + 逐项容错」。

[PerryLink]

按你测的数据，0 → 1 不是修法，是把"全部"换成"空"：.cmd 在 ASSOC_FILTER_RECOMMENDED 下是 0 个 handler，这个对话框会一个候选都不剩。我上一条说"换成 1 会顺带减少踩雷面"，这句只在有推荐项时成立，.cmd 正好不成立。

fallback 的料这个文件里已经有了：List 在枚举之前就查了两条 Shell 关联，:198 的 Associated(extension, 2) 是 AssocQueryString(..., ASSOCSTR_EXECUTABLE, ...)，:199 的 21 是 ASSOCSTR_APPID；Associated 本体在 :119-125，走的是和双击相同的解析链。所以最小改动是给 :185 那次枚举加 fallback，而不是换常量：

• 先用 ASSOC_FILTER_RECOMMENDED 枚举，Next 一个都没拿到时再用 ASSOC_FILTER_NONE 重跑一次；
• 或者枚举为空时直接用 :198 取到的可执行文件合成一条记录，id 从 ASSOCSTR_PROGID 取（值是 20，不是 21）。

Visit 不能只改一半：OpenRegistered（:214-235）用的是同一个 Visit，靠它拿列表里的 id 回来找 handler 再 Invoke（:216-218）。List 按 recommended 枚举、Open 仍按 NONE 枚举的话，两个集合一旦不一致就会出现"列表里有、点下去报没注册"（:234）。要改就两个入口一起改。

你那条".cmd 用 recommended 是 0"还顺带说明另一件事：:207 判 @default 是拿 GetName 的返回值去比 :198 的 EXE 路径和 :199 的 AppID。Win32 handler 的 GetName 给的是 ProgId（.cmd 上是 cmdfile），跟 cmd.exe、跟 AppID 都不相等，OrdinalIgnoreCase 也救不回来——所以对这类 handler，@default 永远不会为真（打包应用那条走 AppID，可能还能对上）。你在本机顺手验一下就能定：查 .cmd 的 ASSOCSTR_PROGID 和 ASSOCSTR_EXECUTABLE，如果是 cmdfile 和 cmd.exe，这条成立，@default 得改成比 ProgId。

逐项容错还是我上一条指的位置，:202-208：GetName/GetUIName 在 try 之外，Visit 只有 :192 的 finally 释放 COM 对象，没有 catch，所以任何一个 handler 抛异常都会穿出 List。同一个文件里 IconData 对 GetIconLocation 是包了 try 的（:165），名字这两行没包，这个不对称大概就是漏的地方。挂起那条你已经分到 #10369，我不再往这条里塞。