[Bug] Windows「打开方式」选中某些应用后，associations.ps1 助手进程永久挂起，界面卡在「正在打开…」

[Tristanash]

[Bug] Windows「打开方式」选中某些应用后，associations.ps1 助手进程永久挂起，界面卡在「正在打开…」

续 Discussion #10349（过滤器传 0 + 遍历无逐项容错）。
按 @PerryLink 的建议，挂起问题单独成条。这条与「候选列表太宽」是两件事：列表问题影响选择阶段，这条影响执行阶段。

环境

• DSH Desktop: 0.2.1-rc.2（@deepseek-ai/dsh-desktop）
• OS: Windows 10 Pro 22H2，19045.6466（x64）
• 源码: master 分支，packages/util/native-command/src/file-applications-windows.ts

复现步骤

1. 让助手在工作区产出一个 .cmd 和一个 .ps1。
2. 在文件卡片点「打开」，从列表中选择：
   • Fix-Proxy.cmd → Adobe Premiere Pro CC 2019
   • Fix-Proxy.ps1 → Sublime Text
3. 观察界面与任务栏。

实际结果

• 界面永久停在 「正在打开…」，无超时、无错误提示，只能强杀。
• 任务栏出现一个无法激活、无法关闭的窗口条目。
• 每次点击留下一个不会退出的助手进程（存活 10 分钟以上）：

powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass \
  -File %TEMP%\dsh-native-command-596ikP\associations.ps1
  → Open('...\Fix-Proxy.cmd', 'C:\Program Files\Adobe\Adobe Premiere Pro CC 2019\Adobe Premiere Pro.exe')

powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass \
  -File %TEMP%\dsh-native-command-fmMCzw\associations.ps1
  → Open('...\Fix-Proxy.ps1', 'C:\Program Files\Sublime Text\sublime_text.exe')

两进程的父进程均为 DeepSeek Harness.exe，CPU 累计仅约 0.3 s（在等，不是在忙循环）。

• 残留窗口的实测属性：

属性	值
窗口类	Static
标题	Window Dialog
归属进程	上述 powershell.exe 助手
可见性	IsWindowVisible = true，出现在任务栏，点击无反应

注意：windowsFileApplications() 是用 'hidden' 窗口样式启动这个 helper 的，所以这个可见窗口不是控制台窗口，而是 COM/消息泵路径上产生的。

对照实验

文件类型	选中的应用	结果
.cmd	Premiere Pro CC 2019	挂起，助手不退出，留僵尸窗口
.ps1	Sublime Text	挂起，同上
.ps1 / .cmd	记事本	正常，助手进程正常退出，无残留窗口

即：同样的文件、同样的调用链，只换 handler 结果就不同。所以不是文件本身的问题，也不是 ShellExecute 层面的关联损坏（HKCR\.cmd 为标准的 cmdfile，ftype cmdfile = "%1" %*）。

根因分析

Open() 的路径是：

public static void Open(string path, string application) {
  WithShellLifetime(delegate { OpenRegistered(path, application); });
}

OpenRegistered 内部命中目标 handler 后调用 handler.Invoke(data)，随后进入 WithShellLifetime 的排空循环（file-applications-windows.ts:93-97 附近）：

UIntPtr timer = SetTimer(IntPtr.Zero, UIntPtr.Zero, 10, IntPtr.Zero);
try {
  while (Marshal.ReadInt32(count) > owned) {     // ← 没有 deadline
    Message message;
    if (GetMessage(out message, IntPtr.Zero, 0, 0) <= 0) throw new InvalidOperationException("Shell handoff message loop ended");
    TranslateMessage(ref message);
    DispatchMessage(ref message);
  }
} finally { KillTimer(IntPtr.Zero, timer); }

这个循环的设计意图是「等 Shell 的异步启动真正释放宿主」，判断依据是 SHCreateThreadRef 的计数回落到基线。问题在于退出条件完全依赖对端：

1. 循环没有超时。只要计数不回落（handler 没有释放、或 Invoke 本身阻塞在等待应用握手/模态窗口上），这个 while 就永久成立，GetMessage 靠 10ms 的 WM_TIMER 反复唤醒，进程既不退出也不报错。
2. 调用方同样没有超时。run(...) 只接受 signal（取消），UI 既然一直显示「正在打开…」，说明这层也没有基于时长的兜底；于是 helper 永远不返回，卡片状态永久挂起。
3. 失败对用户不可见。没有任何错误进入 UI，用户只能看到转圈；而 helper 是以 'hidden' 启动的，用户连它在干什么都看不到，只会看到任务栏多出一个点不开的 Window Dialog。
4. 退出时无人清理：DSH 关闭后这些 helper 仍会残留（本例中直到手动 Stop-Process 才清掉）。

至于「为什么偏偏是这两个应用」，我这里只能给出观察，不敢断言机制：两者都是长期驻留的 GUI 进程，且都通过 shell 注册的 handler 启动；记事本则是经典 Win32「open」动词。要区分「Invoke 未返回」与「Invoke 返回了但引用计数未回落」，需要 helper 侧打点（见下）。

建议修复

1. 给排空循环加 deadline（如 10 s），超时后放弃排空、直接返回并抛错；宁可「打开成功但不等握手」，也不要无限期挂住。
2. 调用方加整体超时（run(...) 外层，如 15 s），超时 kill helper 并把错误回抛 UI，让卡片显示「打开失败」而不是永久「正在打开…」。
3. 失败要可见：把 helper 的 stderr / 退出码透出到 UI（至少写进日志）。
4. 生命周期兜底：DSH 退出、卡片关闭、或同一个文件重新发起打开时，先清理同目录下的残留 helper。
5. 可选的更稳路径：对「非打包应用、非 DDE」的常见情况，直接用 ShellExecuteEx（SEE_MASK_NOASYNC）按 ProgID/exe 启动，避免走 IHandler::Invoke 后再等引用计数。保留 Invoke 作为「打包应用 / DDE」的回退路径。
6. 如果 1、2 都要保留现状，至少加诊断开关：超时后 dump count 当前值与 handler 名，方便定位是哪个 handler 不放引用。

需要的话我可以提供

• 完整进程树导出（含 Win32_Process 的 CommandLine/ParentProcessId）
• 这两个 associations.ps1 的原始内容（含解码后的 path / application）
• 在 helper 里加一行计时打点后的复现日志（Invoke 前后 + 每次 count 变化），可以按你说的方向精确定位是「Invoke 不返回」还是「计数不回落」

---

English summary

On Windows, after picking a handler in the file-card "Open" menu, associations.ps1
can hang forever for some applications. Open() calls IHandler::Invoke inside
WithShellLifetime, whose drain loop (while (ReadInt32(count) > owned) { GetMessage(...) })
has no deadline, and the caller (run(...)) has no timeout either. When the chosen
handler never releases the shell thread reference, the helper process never exits: the UI
stays on "Opening…" indefinitely, a visible Window Dialog top-level window (class
Static) is left in the taskbar, and the process survives even after the app is closed.
Choosing Notepad for the same file returns immediately and leaves nothing behind.

Fixes: bound the drain loop with a deadline, add a caller-side timeout that kills the
helper and surfaces the error, prefer ShellExecuteEx for non-packaged handlers, and clean
up orphaned helpers on app exit.