[Bug] Windows：文件「打开方式」菜单始终显示「无法获取应用列表」（SHAssocEnumHandlers → E_FAIL 0x80004005）

[linqi414]

[BUG][Windows] 文件「打开方式」菜单始终显示「无法获取应用列表」（SHAssocEnumHandlers → E_FAIL）

项目	内容
产品版本	DeepSeek Harness 桌面版 0.2.2-rc.1
系统	Windows 10 Pro 21H2，build 22000.2538
Shell	Windows PowerShell 5.1.22000.2538（Desktop）
涉及包	@deepseek-ai/dsh-client-ui-open-in-app、@deepseek-ai/dsh-native-command、@deepseek-ai/dsh-api-session-controller
严重度	中（不影响会话，但「打开方式」功能在 Windows 上完全不可用；只能「显示文件位置」）

概要

任意文件卡片（聊天里的交付文件、文件树、文档标题栏）点开右侧下拉箭头后，菜单里没有可用的应用列表，只有一条置灰的「无法获取应用列表」，底部是「显示文件位置（默认）」。

这不是文件本身或系统关联的问题：同一个 .html 双击能正常用 Edge 打开，HKCU\...\FileExts\.html\UserChoice = MSEdgeHTM 且哈希有效。失败发生在 Host 枚举「能打开该扩展名的应用」这一步：Windows Shell 的 SHAssocEnumHandlers 返回 E_FAIL (0x80004005)，客户端因此把整个列表判为失败。

复现步骤

1. 在任意会话中生成或引用一个文件（示例：残疾人证管理系统.html）。
2. 在消息里的文件卡片上，点右侧文件夹图标旁的下拉箭头。
3. 观察菜单内容。

期望 / 实际

• 期望：列出已注册的处理器（Edge、Chrome、VS Code…），当前默认项标注「（默认）」，主按钮显示默认应用图标。
• 实际：只有「无法获取应用列表」（disabled）+「显示文件位置（默认）」；主按钮退化为「显示文件位置」。

根因分析

客户端链路

1. packages/client/ui-open-in-app/src/client/open-path.ts — OpenInAppPathController.applications() 调 session.workspacePathApplications({ path })；RPC 抛错或 ok === false 时返回 null。
2. @deepseek-ai/dsh-client-ui-open-in-app（client/file-applications.ts）— subscribe() 里 failed: apps === null。
3. packages/client/ui-open-in-app/src/client/OpenTargetButton.tsx — failed 为真时渲染 t("path.appsError")（即「无法获取应用列表」），且 revealDefault 生效，主按钮变成「显示文件位置」。

也就是说：任何 RPC 失败（路径校验失败、取消、原生查询失败）都会折叠成同一句文案，用户无法区分。

Host 链路

1. packages/api/session-controller/src/index.ts — workspacePathApplications() 内 this.fileApplications(path, signal) 抛错时统一包装为
   RemoteError("gateway/internal", "file application query failed", { cause })。
2. @deepseek-ai/dsh-native-command（file-applications.ts）— queryFileApplications() 在 win32 上调用 windowsFileApplications(target.path, null, signal, run)。
3. @deepseek-ai/dsh-native-command（file-applications-windows.ts）— 起一个 powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass -File associations.ps1，脚本 Add-Type 一段 C#，再由 SHAssocEnumHandlers(extension, 0, out handlers) 枚举处理器并提取图标。

关键证据

用与上面第 3 步相同的 P/Invoke 逻辑（只保留枚举，去掉图标提取）在 DSH 会话进程上下文里运行，.html 失败：

path       : F:\...\残疾人证管理系统.html
extension  : .html
user       : LYNCH\linqi
integrity  : Mandatory Label\Low Mandatory Level  S-1-16-4096
powershell : 5.1.22000.2538 (Desktop)
result     : FAILED (0x80004005) Error HRESULT E_FAIL has been returned from a call to a COM component.

替换扩展名后结果相同 —— .html / .txt / .pdf / .png / .md / .docx 全部 0x80004005，说明不是某个扩展名的关联损坏，而是枚举调用在本进程上下文里整体不可用。

同一台机器上：Add-Type 编译成功（该 C# 源码本身没问题），失败点只在 SHAssocEnumHandlers。系统关联侧正常（默认程序存在、双击可打开）。

推断的触发条件

执行该查询的子进程处于 Low 完整性级别（受限令牌，S-1-16-4096）。Windows 对跨完整性级别的 COM 激活有限制，Shell 的关联枚举在受限上下文里会直接 E_FAIL。DSH 的 Windows 沙箱（dsh-sandbox-local）正是把受限子进程降到 Low IL 的，因此这里怀疑：

• 该原生查询被放进了受限/沙箱子进程执行；或
• Host 自身在此环境下以受限令牌运行。

两种情况的表现一致：windowsFileApplications 必然失败 → 菜单只剩「显示文件位置」。

待维护者确认：windowsFileApplications 的 powershell.exe 是否经过 ctx.sandbox.confine() / dsh-sandbox-local。若确认，则在普通（Medium IL）终端里跑同一脚本应当成功 —— 这可以直接把「沙箱上下文」与「系统损坏」区分开。

最小复现

完整脚本见文末（另存为 repro-win-file-associations.ps1 后运行；无第三方依赖，ASCII，PS 5.1 可跑）：

powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass `
  -File .\repro-win-file-associations.ps1 -Path C:\some\file.html

输出里会打印当前用户、完整性标签、PowerShell 版本和枚举结果；失败时以退出码 1 结束并打印 HRESULT。

建议修复（任选其一，1 为推荐）

1. 不依赖 Shell COM 枚举：改用
   AssocQueryString(ASSOCF_NONE, ASSOCSTR_EXECUTABLE / ASSOCSTR_FRIENDLYAPPNAME / ASSOCSTR_DEFAULTICON, ".html", ...)
   加上注册表枚举 HKCU\Software\Classes\.ext\OpenWithProgids、HKCR\.ext\OpenWithList、HKCR\SystemFileAssociations\.ext。
   这些在低完整性下可读，且不需要激活 Shell 的关联 COM 服务器。图标可对 ASSOCSTR_DEFAULTICON 指向的 exe/dll 用 SHDefExtractIcon 取（纯 Win32，不涉及跨完整性激活）。
2. 换上下文执行：把 windowsFileApplications 的 PowerShell 调用放到未受限的 Host 子进程（不经 sandbox confine），保留现有 C# 实现。
3. 把失败原因透出来：workspacePathApplications 失败时携带 code/hresult，客户端菜单显示「打开方式查询失败（0x80004005）· 重试」，而不是笼统的「无法获取应用列表」。
4. 兜底行为：枚举失败或为空时，主按钮应退化为「用默认程序打开」（ShellExecuteEx / start），而不是只剩「显示文件位置」——后者需要用户再去资源管理器里双击，多一步且违背按钮的直觉。

影响面

所有在 Windows 上以受限令牌运行 Host（或系统策略阻止跨完整性 COM 激活）的用户：文件「打开方式」菜单不可用，只能走「显示文件位置」。会话本身、文件预览、文件树都不受影响。

临时规避（用户侧）

• 菜单里选 「显示文件位置（默认）」 → 在资源管理器里双击；
• 或把文件直接拖进浏览器。

---

repro-win-file-associations.ps1（完整脚本）

# Minimal repro: Windows file-handler enumeration used by DSH's "Open with" menu.
# Mirrors oneDLL call in @deepseek-ai/dsh-native-command (file-applications-windows):
#   SHAssocEnumHandlers(extension, 0, &handlers)
#
# Usage (Windows PowerShell 5.1):
#   powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass -File .\repro-win-file-associations.ps1
#   powershell.exe -NoProfile -NonInteractive -STA -ExecutionPolicy Bypass -File .\repro-win-file-associations.ps1 -Path C:\some\file.html
#
# Exit code 0 = handlers enumerated, 1 = enumeration failed (prints the HRESULT).

param(
    [string]$Path = (Join-Path $env:USERPROFILE 'probe.html')
)

$ErrorActionPreference = 'Stop'
[Console]::OutputEncoding = New-Object System.Text.UTF8Encoding($false)

Add-Type -ReferencedAssemblies System -TypeDefinition @'
using System;
using System.Collections.Generic;
using System.Runtime.InteropServices;

public static class DshAssocProbe
{
    [ComImport, Guid("973810ae-9599-4b88-9e4d-6ee98c9552da"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
    public interface IEnumAssocHandlers
    {
        [PreserveSig] int Next(uint celt, out IAssocHandler handler, out uint fetched);
    }

    [ComImport, Guid("f04061ac-1659-4a3f-a954-775aa57fc083"), InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
    public interface IAssocHandler
    {
        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(object data);
        void CreateInvoker(object data, out object invoker);
    }

    [DllImport("shell32.dll", CharSet = CharSet.Unicode, PreserveSig = false)]
    static extern void SHAssocEnumHandlers(string extension, uint filter, out IEnumAssocHandlers handlers);

    // ASSOC_FILTER_NONE = 0 (DSH uses 0)
    public static string[] List(string extension)
    {
        IEnumAssocHandlers handlers;
        SHAssocEnumHandlers(extension, 0, out handlers);

        var found = new List<string>();
        try
        {
            while (true)
            {
                IAssocHandler handler;
                uint fetched;
                int hr = handlers.Next(1, out handler, out fetched);
                Marshal.ThrowExceptionForHR(hr);
                if (fetched == 0) break;
                try
                {
                    string id, name;
                    handler.GetName(out id);
                    handler.GetUIName(out name);
                    found.Add(id + "  [" + name + "]");
                }
                finally { Marshal.FinalReleaseComObject(handler); }
            }
        }
        finally { Marshal.FinalReleaseComObject(handlers); }
        return found.ToArray();
    }
}
'@

$extension = [System.IO.Path]::GetExtension($Path)
if ([string]::IsNullOrEmpty($extension)) {
    Write-Error "Path has no extension: $Path"
    exit 1
}

$identity = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$label = (whoami /groups | Select-String -Pattern 'Mandatory Label').ToString().Trim()

Write-Output "path       : $Path"
Write-Output "extension  : $extension"
Write-Output "user       : $identity"
Write-Output "integrity  : $label"
Write-Output "powershell : $($PSVersionTable.PSVersion) ($($PSVersionTable.PSEdition))"

try {
    $apps = [DshAssocProbe]::List($extension)
    Write-Output "result     : OK, $($apps.Count) handler(s)"
    foreach ($app in $apps) { Write-Output "  - $app" }
    exit 0
}
catch {
    $inner = $_.Exception.InnerException
    $message = if ($inner) { $inner.Message } else { $_.Exception.Message }
    $hr = if ($inner -is [System.Runtime.InteropServices.COMException]) { '0x{0:X8}' -f $inner.HResult } else { 'n/a' }
    Write-Output "result     : FAILED ($hr) $message"
    exit 1
}

[ltmroberthk915]

同症状第三台机器的实证补充：这个现象与 #11020 是同一个根因——SHAssocEnumHandlers 枚举本身成功，是单个失效 handler 的 GetName/GetUIName 抛 E_FAIL 拖垮了整个查询，不一定需要 Low IL 沙箱假说。

本机证据（DSH 桌面版 0.2.2-rc.3，Windows 11，Medium IL、非沙箱的普通 powershell.exe -File 同样复现原故障）：

1. 逐 handler 插桩（对每次调用单独 try/catch）：SHAssocEnumHandlers / Next 全部成功，健康成员正常解析，E_FAIL 只来自特定 stale 成员的 GetName/GetUIName。楼主帖中的复现脚本对 handler 迭代没有逐成员 catch，所以"单个坏成员的 E_FAIL"和"枚举在本上下文不可用"输出完全相同，两者需用插桩脚本区分。
2. "所有扩展名全挂"的更简单解释：坏 handler 若来自全局注册（本机为 HKCU\Software\Classes\Applications\ 下 3 个孤儿键：exe 已改名的 MarkPilot CM6.exe、安装包已删的 markpilot-Setup-3.2.15.exe、指向旧版 WPS 目录的 wpsofd.exe），会出现在每一个扩展名的枚举里——我们用一个全新未注册扩展 .zz9 也稳定复现出同样的 2 个坏成员。
3. 定位技巧：GetName 抛 E_FAIL 时，同一成员的 GetIconLocation 往往仍能返回图标路径（= 坏注册的 exe 路径），一行即可锁定元凶。
4. 修复实证：备份并删除上述 3 个 HKCU 孤儿键后，宿主未改动的 associations.ps1 立即从 E_FAIL 恢复为返回 19 个应用（宿主每次查询新起 powershell，无需重启）。若残留位于 HKLM/系统 hive，普通用户清不掉——这正是适配器应当逐成员容错（跳过坏成员，与资源管理器"打开方式"对话框行为一致）的理由。

修复建议与 #11020 一致：在 Visit() 的委托里对 GetName/GetUIName 逐成员 try/catch 并跳过失败成员（IconData() 对图标读取已有同样的隔离容错，补齐该模式即可），#11020 的实验证明改动后健康条目不受影响。