Bug：电脑添加文件到传输列表，第一次大概率闪退

[lisiupython]

复现：在windsend上右键选择“添加文件”，弹出文件选择框，添加文件（我一般是复制文件到路径），然后鼠标转圈1秒，windsend闪退。
第二次继续添加，就成功。
已经是最新版本1.71，1.70也有这个问题。我记得几个版本前没有这个问题。

[doraemonkeys]

我电脑上没复现出来，程序所在目录有个panic.log和logs文件夹，你能发出来吗。

这个功能我现在很少用了，因为鼠标直接选中文件复制更方便，效果也是一样的

[lisiupython]

我电脑上没复现出来，程序所在目录有个panic.log和logs文件夹，你能发出来吗。

这个功能我现在很少用了，因为鼠标直接选中文件复制更方便，效果也是一样的

我是便携版，没看到这个log，不过有其他相关的log，AI分析后原因应该是和mactype冲突了，排除了好像没问题了，看看源码能否修改一下：

关键线索找到了——日志末尾在崩溃前出现了 pick_files failed or canceled，而 WER 报告显示崩溃模块是 shell32.dll，异常码是访问违例 0xC0000005。现在去 GitHub 查对应源码。

诊断了崩溃根源并追溯到第三方字体渲染软件冲突。

诊断了崩溃根源并追溯到第三方字体渲染软件冲突。

现在我有足够的证据了，可以给出完整分析。

---

WindSend 闪退原因分析

两份文件已读完，结合源码，问题链路非常清晰。

一、崩溃现场还原

时间线：

22:12:51  WARN wind_send::systray: 390: pick_files failed or canceled
          ← 文件选择对话框打开失败/立刻返回 None
          ← 22 秒后进程崩溃
22:13:32  INFO wind_send::config: 348: init_global_logger success
          ← 程序已重启

WER 崩溃报告关键字段：

字段 | 值 | 含义 -- | -- | -- 故障模块 | shell32.dll | Windows Shell 文件对话框宿主 异常代码 | 0xC0000005 | Access Violation（访问违例） 异常偏移 | 0x3c9b49 | shell32.dll 内部偏移 IsFatal | 1 | 致命，进程直接终止

二、触发路径（结合源码）

用户点击托盘菜单中的"添加文件"，触发以下调用链：

systray 事件循环 (main thread)
  └─ handle_menu_event_add_files()  [systray.rs:384]
       └─ rfd::FileDialog::new().pick_files()  [systray.rs:386]
            └─ Windows IFileOpenDialog COM 接口（托管在 shell32.dll）
                 ← 崩溃在此

rfd::FileDialog 是同步文件对话框，在 Windows 上直接调用 COM IFileOpenDialog，而 IFileOpenDialog 的 UI 渲染由 shell32.dll 承载，需要调用 D2D1、DirectWrite 等图形组件。

三、根本原因：MacType DLL 注入冲突

WER 加载模块列表中出现了关键线索：

LoadedModule[26]=C:\Program Files\MacType\MacType64.dll
LoadedModule[27]=C:\Program Files\MacType\MacType64.Core.dll

MacType 是一款 Windows 字体渲染增强工具，它通过 全局 DLL 注入 的方式 Hook 所有进程的 GDI/DirectWrite/字体 API。当 WindSend 的文件选择对话框调用 IFileOpenDialog 渲染界面时：

1. shell32.dll 内部调用 DirectWrite / GDI 进行字体渲染
2. MacType 的 Hook 拦截这些调用，修改渲染上下文
3. Hook 代码与 shell32.dll 内部状态发生不兼容，触发 0xC0000005 访问违例
4. 由于崩溃在 shell32.dll 内部，Windows 错误报告将故障模块记录为 shell32.dll（而非真正的 MacType）

这是 MacType 与基于现代 COM 对话框（IFileOpenDialog）的应用程序之间的经典兼容性问题，在很多软件上都有记录。

四、为何 pick_files 返回 None 后还会崩溃

源码第 386-390 行逻辑是：

rust

let pick_task = rfd::FileDialog::new().pick_files(); // 对话框崩溃前一刻返回 None
let files = match pick_task {
    Some(files) => files,
    None => {
        warn!("pick_files failed or canceled"); // 这条 WARN 被记录了
        return; // 正常 return
    }
};

这说明 pick_files() 虽然最终返回了 None（因为对话框未能正常展示），但崩溃并不是在 Rust 代码中发生的，而是在 COM 对话框的 UI 线程 teardown 期间 shell32.dll 内部崩溃的，属于异步/延迟崩溃。

五、解决方案

立即可用的临时方案（推荐）： 将 WindSend 加入 MacType 排除列表

1. 打开 MacType 控制面板（或 MacTray）
2. 找到"进程排除列表"或"应用程序设置"
3. 添加 WindSend-S-Rust.exe → 排除（不注入）
4. 重启 WindSend

长期方案（需开发者处理）： 可以建议开发者在调用文件对话框前检测 MacType 注入，或切换到 rfd::AsyncFileDialog（它在 Windows 上会使用不同的 COM apartment 初始化策略，与部分字体 Hook 的冲突更少）。

[doraemonkeys]

我电脑上没复现出来，程序所在目录有个panic.log和logs文件夹，你能发出来吗。
这个功能我现在很少用了，因为鼠标直接选中文件复制更方便，效果也是一样的

我是便携版，没看到这个log，不过有其他相关的log，AI分析后原因应该是和mactype冲突了，排除了好像没问题了，看看源码能否修改一下：

关键线索找到了——日志末尾在崩溃前出现了 pick_files failed or canceled，而 WER 报告显示崩溃模块是 shell32.dll，异常码是访问违例 0xC0000005。现在去 GitHub 查对应源码。

诊断了崩溃根源并追溯到第三方字体渲染软件冲突。
诊断了崩溃根源并追溯到第三方字体渲染软件冲突。
现在我有足够的证据了，可以给出完整分析。

WindSend 闪退原因分析

两份文件已读完，结合源码，问题链路非常清晰。

一、崩溃现场还原

时间线：

22:12:51  WARN wind_send::systray: 390: pick_files failed or canceled
          ← 文件选择对话框打开失败/立刻返回 None
          ← 22 秒后进程崩溃
22:13:32  INFO wind_send::config: 348: init_global_logger success
          ← 程序已重启

WER 崩溃报告关键字段：

字段 | 值 | 含义 -- | -- | -- 故障模块 | shell32.dll | Windows Shell 文件对话框宿主 异常代码 | 0xC0000005 | Access Violation（访问违例） 异常偏移 | 0x3c9b49 | shell32.dll 内部偏移 IsFatal | 1 | 致命，进程直接终止

二、触发路径（结合源码）

用户点击托盘菜单中的"添加文件"，触发以下调用链：

systray 事件循环 (main thread)
  └─ handle_menu_event_add_files()  [systray.rs:384]
       └─ rfd::FileDialog::new().pick_files()  [systray.rs:386]
            └─ Windows IFileOpenDialog COM 接口（托管在 shell32.dll）
                 ← 崩溃在此

rfd::FileDialog 是同步文件对话框，在 Windows 上直接调用 COM IFileOpenDialog，而 IFileOpenDialog 的 UI 渲染由 shell32.dll 承载，需要调用 D2D1、DirectWrite 等图形组件。

三、根本原因：MacType DLL 注入冲突

WER 加载模块列表中出现了关键线索：

LoadedModule[26]=C:\Program Files\MacType\MacType64.dll
LoadedModule[27]=C:\Program Files\MacType\MacType64.Core.dll

MacType 是一款 Windows 字体渲染增强工具，它通过 全局 DLL 注入 的方式 Hook 所有进程的 GDI/DirectWrite/字体 API。当 WindSend 的文件选择对话框调用 IFileOpenDialog 渲染界面时：

1. shell32.dll 内部调用 DirectWrite / GDI 进行字体渲染
2. MacType 的 Hook 拦截这些调用，修改渲染上下文
3. Hook 代码与 shell32.dll 内部状态发生不兼容，触发 0xC0000005 访问违例
4. 由于崩溃在 shell32.dll 内部，Windows 错误报告将故障模块记录为 shell32.dll（而非真正的 MacType）

这是 MacType 与基于现代 COM 对话框（IFileOpenDialog）的应用程序之间的经典兼容性问题，在很多软件上都有记录。

四、为何 pick_files 返回 None 后还会崩溃

源码第 386-390 行逻辑是：

rust

let pick_task = rfd::FileDialog::new().pick_files(); // 对话框崩溃前一刻返回 None
let files = match pick_task {
    Some(files) => files,
    None => {
        warn!("pick_files failed or canceled"); // 这条 WARN 被记录了
        return; // 正常 return
    }
};

这说明 pick_files() 虽然最终返回了 None（因为对话框未能正常展示），但崩溃并不是在 Rust 代码中发生的，而是在 COM 对话框的 UI 线程 teardown 期间 shell32.dll 内部崩溃的，属于异步/延迟崩溃。

五、解决方案

立即可用的临时方案（推荐）： 将 WindSend 加入 MacType 排除列表

1. 打开 MacType 控制面板（或 MacTray）
2. 找到"进程排除列表"或"应用程序设置"
3. 添加 WindSend-S-Rust.exe → 排除（不注入）
4. 重启 WindSend

长期方案（需开发者处理）： 可以建议开发者在调用文件对话框前检测 MacType 注入，或切换到 rfd::AsyncFileDialog（它在 Windows 上会使用不同的 COM apartment 初始化策略，与部分字体 Hook 的冲突更少）。

我研究一下