[Bug] "open in app" breaks due to one broken handler — windowsFileApplications fails on a stale COM handler (Windows)

[aavainer]

EN

Symptom. On file cards, the "Open in…" menu shows "Could not load applications" and the program list is empty; the file cannot be opened in the desired app from the menu.

Root cause (DSH 0.2.0, Windows). @deepseek-ai/dsh-native-command → nativeFileApplications → windowsFileApplications runs a C# adapter under powershell.exe -STA, which enumerates handlers via SHAssocEnumHandlers. In the Visit loop, handler.GetName() and handler.GetUIName() are called without try/catch. If one handler returns HRESULT E_FAIL on these COM calls, the whole List() fails → gateway/internal: file application query failed → the client renders "Could not load applications".

Trigger. After uninstalling WordPad on Windows 11 24H2, a stale HKEY_CLASSES_ROOT\Applications\WORDPAD.EXE entry remains (the WORDPAD.EXE file is gone). Its GetName/GetUIName throw E_FAIL, while GetIconLocation still returns a path to the missing exe. This one broken handler takes down the enumeration of 14 live ones (Word, LibreOffice, Notepad, …).

Reproduction. Leave a stale Applications\<RemovedApp>.exe key → call session/workspacePathApplications → "file application query failed".

Proposed fix (DSH side):

1. Wrap each handler's GetName/GetUIName (and preferably GetIconLocation) in try/catch — skip the broken handler instead of failing the whole list.
2. The "open with default app" path (openPath/openNativeAssociatedPath) should not depend on handler enumeration.

Regression. Before 0.2.0 the file opened directly in the default app; 0.2.0 added handler enumeration to the open flow, making it fragile to a single stale entry.

---

RU

Симптом. У карточек файлов меню «Открыть в…» показывает «Could not load applications», список программ пуст; файл нельзя открыть в нужном приложении из меню.

Корень (DSH 0.2.0, Windows). @deepseek-ai/dsh-native-command → nativeFileApplications → windowsFileApplications запускает C#-адаптер через powershell.exe -STA, который перечисляет обработчики через SHAssocEnumHandlers. В цикле Visit вызываются handler.GetName() и handler.GetUIName() без try/catch. Если один обработчик возвращает HRESULT E_FAIL, падает весь List() → gateway/internal: file application query failed → клиент рисует «Could not load applications».

Триггер. После удаления WordPad в Windows 11 24H2 остаётся битая запись HKEY_CLASSES_ROOT\Applications\WORDPAD.EXE (файл WORDPAD.EXE отсутствует). Её GetName/GetUIName кидают E_FAIL, а GetIconLocation ещё отдаёт путь к отсутствующему exe. Один такой обработчик роняет перечисление 14 живых (Word, LibreOffice, Notepad, …).

Воспроизведение. Оставить stale-ключ Applications\<RemovedApp>.exe → session/workspacePathApplications → «file application query failed».

Предложение фикса (на стороне DSH):

1. Обернуть GetName/GetUIName (и желательно GetIconLocation) каждого обработчика в try/catch — пропускать битый обработчик, а не валить весь список.
2. Путь «открыть в приложении по умолчанию» (openPath/openNativeAssociatedPath) не должен зависеть от перечисления обработчиков.

Регресс. До 0.2.0 файл открывался сразу в приложении по умолчанию; 0.2.0 добавил перечисление обработчиков в сценарий открытия, что сделало его хрупким к одной битой записи.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[PerryLink]

这是同一缺陷的第二份独立报告——请与 #7874 合并

1. 你指的代码路径确实存在

packages/util/native-command/src/file-applications-windows.ts
packages/util/native-command/src/file-applications.ts

⇒ 你说的 nativeFileApplications → windowsFileApplications（powershell.exe -STA 跑 C# 适配器、用 SHAssocEnumHandlers 枚举）这条链在本仓里是真实的，不是我需要猜的。

2. 与 #7874 是同一件事（请合并或互相引用）

同一形态在同期另有一条独立报告（#7874：Windows 上「打开方式」永远显示「无法获取应用列表」）。那条的报告者做了逐项隔离对照，并查清了元凶：

坏项不是"关联了 .txt/.png"，而是注册成了"万能打开方式"——HKEY_CLASSES_ROOT\Applications\r5apex.exe\shell\open\command，该键下只有 shell 子树、没有 SupportedTypes。

⇒ 两条指向同一个机制：枚举时遇到一个坏 handler ⇒ 整份列表不可用。你这条的价值在于把代码路径指名了（windowsFileApplications 的 Visit 循环）；那条的价值在于证明坏项确实存在于真实机器上。合起来才是完整证据，分开提容易被各修一半。

3. 建议的诉求（可验收、且不依赖"哪个 handler 坏"）

枚举应用列表必须逐项容错：单个 handler 读取 GetName/GetUIName 失败时应跳过该项并继续（可在日志中记一条），而不是让整份列表不可用。

理由：坏 handler 的来源不可控（第三方安装器会写出各种畸形注册）。逐项容错是一次性解法；只修"跳过 r5apex"只能治个案。这一点我在 #7874 里已给出同样的建议，你这条正好提供了代码侧的落点。

4. 请补两样

1. Visit 循环里抛出的具体异常与 HRESULT（你写到"fails on a stale COM handler"，把那一行错误贴出来即可）；
2. 版本：你写 DSH 0.2.0（Windows）；⚠️ 当前最新是 0.2.1-alpha.1 ⇒ 请确认 file-applications-windows.ts 在新版未变（我核到该文件仍在，但未逐行比对）。

5. 一条同族但已修的旁证（供你判断节奏）

native-command 这条路径刚被上游改过：windowsHide 从"无条件 true"改为按调用点决定，并有一条 a895066443 fix(windows): keep Explorer path-opening windows visible。⇒ 说明这条路径正在被关注，你的报告时机是好的；也建议你在正文里提一句"同包的 windowsHide 问题已修，本条是相邻的枚举侧"——这会让维护者立刻定位到同一文件。

一条边界

我确认的是该文件路径存在与你描述的调用链与本仓结构相符。具体是哪个 handler、抛了什么 HRESULT以你与 #7874 的实测为准——我没有 Windows 环境复现。

[aavainer]

Agreed — this is the same defect as #7874; we'll cross-reference and not keep two parallel threads. The two reports point at the same mechanism: one bad handler makes the whole list unavailable.

Answers:

1. HRESULT: the broken handler's GetName/GetUIName return E_FAIL (0x80004005); GetIconLocation still returns a path to the now-missing exe.
2. Version: observed on DSH 0.2.0 (Windows). We have not re-verified on 0.2.1-alpha.1; per your check the file is still present.

We agree the fix should be per-item fault tolerance (skip + log the broken handler) rather than a special-case for any specific stale key. Also noted: the same package's windowsHide path was recently fixed (a895066) — this is the adjacent enumeration side of native-command.

Happy to consolidate onto #7874 or keep #8839 as the code-path reference — your call.

---

RU:

Согласны — это тот же дефект, что #7874; даём перекрёстную ссылку, два параллельных треда не держим. Оба отчёта указывают на один механизм: один битый обработчик валит весь список.

Ответы:

1. HRESULT: у битого обработчика GetName/GetUIName возвращают E_FAIL (0x80004005); GetIconLocation ещё отдаёт путь к отсутствующему exe.
2. Версия: наблюдалось на DSH 0.2.0 (Windows). На 0.2.1-alpha.1 не перепроверяли; по вашей проверке файл на месте.

Согласны, что фикс должен быть по-элементно отказоустойчивым (skip + лог битого обработчика), а не частным случаем для конкретного stale-ключа. Отметили также: windowsHide в том же пакете уже починен (a895066) — это соседняя enumeration-сторона native-command.

Готовы консолидироваться на #7874 или оставить #8839 как ссылку на код-путь — на ваше усмотрение.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.

[PerryLink]

你的 E_FAIL 细节正好指出唯一的异常点——修法可以精确到"抓在哪里"

1. 这份 HRESULT 让修法变得很具体

你给的是：坏 handler 的 GetName / GetUIName 返回 E_FAIL（0x80004005），而 GetIconLocation 仍返回一个指向已不存在 exe 的路径。

⇒ 两条信息合起来说明：枚举本身没坏（SHAssocEnumHandlers 一路给到了这一项），坏的是"读这一项的名字"这一步。⇒ 因此容错的落点必须精确：

抓的位置	效果
把整个枚举循环包在 try/catch 里	❌ 一旦某项抛错就整份列表没了——这正是现在的 bug
在"逐项读取名字/UI 名"处包 try/catch	✅ 跳过该项、继续枚举 ⇒ 其余应用照常出现

建议把这句话写进合并后的报告："容错必须落在单项的读取上，而不是整个枚举循环上"——否则维护者很可能顺手把 try 加在外层，症状看起来好了、换个坏 handler 又复发。

2. GetIconLocation 那条是第二个独立的异常点，建议一起纳入

你说它仍返回指向已删除 exe 的路径 ⇒ 那么"逐项容错"的覆盖范围应当同时包含：

• 名字读取（GetName/GetUIName，已知会 E_FAIL）；
• 图标路径读取（可能返回陈旧/不可用路径 ⇒ 读取该文件时会失败）。

⇒ 验收条件可以写成一句可判定的：

当某个 handler 在读取名字/UI 名时返回 E_FAIL、或其图标路径指向不存在的文件时，其余 handler 仍应出现在列表中（该坏项可跳过并在日志中记一条）。

3. 关于合并：我确认你的做法

你写"同一缺陷、会互相引用、不并行开两条"，且同意修法应当是逐项容错。⇒ 这与我在 #7874 里给出的建议一致，合并后由你这条提供 E_FAIL 这一层证据、由那条提供"坏项是注册成万能打开方式"这一层证据，两半齐了。

4. 请补一样

被跳过的坏项是否应当在界面上留痕（而不是完全静默）⇒ 这一条决定"用户遇到同类坏 handler 时能不能自己发现"。建议作为可选项提出（不阻塞主修复）：至少写一条日志。

5. 版本

你写"未在 0.2.1-alpha.1 复核，按我的核实该文件仍在"。⇒ 我确认的是 packages/util/native-command/src/file-applications-windows.ts 与 file-applications.ts 在最新 HEAD 上仍存在（但未逐行比对内容）。⇒ 请在合并后的报告里写"文件仍在，行为待复核"，不要写成"新版仍复现"（那需要你实测）。

一条边界

我确认的是该文件路径在当前版本存在（因此落点有效）。E_FAIL 的具体产生位置与逐项容错的实现细节以你的核对为准——我没有 Windows COM 环境可测。

[aavainer]

Agreed on the acceptance criterion — per-item fault tolerance covering both the name/UI-name read (E_FAIL) and the icon-path read (nonexistent file), with the other handlers still listed. We'll also make sure the wording "fault tolerance on the per-item read, not the whole loop" goes into the merged report, exactly as you noted.

On your option (trace for a skipped handler): yes, at minimum a log line (warning) per skipped item — that's the cheap, non-blocking baseline that lets a user self-discover "why is app X missing" from logs. A UI badge we'd keep optional (it can get noisy with many third-party installers).

Happy to consolidate onto #7874 and keep #8839 as the code-path reference (windowsFileApplications Visit loop + the E_FAIL evidence). Thanks for pinning this down precisely.

---

RU:

Согласны с приёмкой — по-элементная отказоустойчивость, покрывающая и чтение имени/UI-имени (E_FAIL), и чтение пути иконки (несуществующий файл), при этом остальные handler'ы остаются в списке. Формулировку «отказоустойчивость на по-элементном чтении, а не на всём цикле» внесём в объединённый отчёт, как вы и отметили.

По вашей опции (след пропущенного handler'а): да, минимум — строка лога (warning) на каждый пропущенный пункт — это дёшевый неблокирующий базис, позволяющий пользователю самому понять из логов «почему приложение X не в списке». UI-бейдж оставим опциональным (с множеством сторонних инсталляторов может шуметь).

Готовы консолидироваться на #7874 и оставить #8839 как ссылку на код-путь (windowsFileApplications, цикл Visit + улика E_FAIL). Спасибо, что довели до такой точности.

Anonymized for public reporting: workspace names, paths, session names/ids and dates have been genericized.