[recording] Windows 2.0.2 Beta.2 录音期间因堆损坏静默退出

Offen
  • Stimmt etwas nicht?
#1,261 4 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
audio-video-rtc, backend

Rechercherichtung

Start by reproducing the recording crash with the stated WO Mic configuration (48 kHz, mono, F32) and inspect the audio capture, recording callback, stop, and Stream release paths. The report does not name source files or tests; use a matching PDB or diagnostic build with Windows page heap to locate the first invalid write or release. Done means the crash is fixed, the stated recording regression checks pass, and recordings no longer exit silently.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

现象

环境

  • 版本：2.0.2-Beta.2+build.20261023，EXE 文件版本 2.0.2.0
  • 构建提交：af14756d3d9d1474fa7db782c332b61deef58688
  • EXE SHA-256：73e12ff0f3c89cd75a628a9030aad63be105107da19195c96d090efb94c877ca
  • 系统：Windows 11，Build 26200
  • 识别链路：云端 ASR + DeepSeek 润色，未使用本地 ASR 模型
  • 输入设备：麦克风 (WO Mic Device)，日志记录 48000 Hz / 1 channel / F32
  • 文字插入模式：TSF

当前表现

OpenLess 在录音期间无弹窗、无 Rust panic、无普通异常日志，进程直接退出，约 20~25 秒后自动重启。最近 5 天保留了 6 份崩溃转储；按进程 PID 去重，至少对应 5 次独立崩溃。

本地时间（UTC+8） 异常码 WER 签名
2026-10-20 01:04:13 c0000374 PCH_63_FROM_ntdll+0x1628A4，StackHash 4b54
2026-10-22 13:35:09 c0000374 PCH_63_FROM_ntdll+0x1628A4，StackHash 8458
2026-10-23 00:25:27 c0000005 openless.exe+0x2cc96e7，StackHash b819
2026-10-23 00:25:33 c000041d openless.exe+0x2cc96e7，StackHash c945
2026-10-24 15:32:30 c0000374 PCH_63_FROM_ntdll+0x1628A4，StackHash e65a
2026-10-24 16:16:35 c0000374 PCH_63_FROM_ntdll+0x1628A4，StackHash e65a

今天两次的签名完全一致，均为 ntdll.dll + 0x1628a4 的堆损坏检测；16:16 的转储中，异常线程名为 main。

与录音阶段的对应关系

  • 15:32:22 开始录音，设备为 WO Mic，15:32:30 生成崩溃转储，约 8 秒后退出；15:32:51 自动重启。
  • 16:16:09 开始录音，设备为 WO Mic，16:16:35 生成崩溃转储，约 26 秒后退出；16:17:00 自动重启。
  • 两次均已经收到 first_raw_pcm 和 first_output_pcm，但退出前没有 cpal Stream dropped (mic released)。
  • 两次对应 WAV 文件的修改时间分别与 15:32:30、16:16:35 对齐。
  • 两次退出前均未进入 ASR 完成、润色或文字插入阶段。

日志中没有 panic、abort 或明确的堆错误记录，说明是进程级原生崩溃，应用日志来不及记录。当前日志中的 TSF stale_or_unknown 0x4F4C0005、更新检查“尚未发布过 Beta 版本”和 e2ee 初始化 ERROR 与上述崩溃时间不吻合，暂不作为根因。

转储线索

  • 最近两次都停在 Windows 堆损坏处理路径，应用侧仅有少量偏移可解析：
    • openless.exe+0x1bb90b5
    • openless.exe+0xd9ff7c
    • openless.exe+0x1bbd35b
  • 转储中加载了 MacType64.dll、MacType64.Core.dll、OpenLessIme.dll、WebView、UIAutomation 和 AUDIOSES.DLL。
  • 堆损坏通常在内存已被写坏后才由 ntdll 检测，因此这些模块只能作为排查方向，不能仅凭栈顶认定根因。
  • 当前主要嫌疑是 WO Mic/WASAPI 音频采集路径；MacType 的进程内钩子是第二嫌疑。TSF 可能性较低，因为两次都在插入文字之前退出。

这与 #1227 中的 c0000374 属于相同异常类型，但本报告补充了更新的 2.0.2 Beta.2、连续的 WO Mic 录音期时间线，以及今天两次完全一致的 WER StackHash。目前尚不能证明与 #1227 是同一条内存破坏路径；如维护者判断相同，可直接合并处理。

影响
  • 崩溃无预兆、无提示，正在进行的语音输入会丢失。
  • 最近 5 天出现 4 次 c0000374；今天在约 44 分钟内连续发生 2 次。
  • 崩溃发生在录音阶段，用户无法通过避免转写、润色或文字插入来规避。
  • 自动重启只能恢复应用，不能恢复崩溃时的录音和识别结果。
  • 当前无法仅靠日志定位最初写坏内存的代码，继续排查需要匹配该构建的 PDB 或维护者的诊断构建。
建议接受标准
  • 使用相同 WO Mic 配置，连续执行至少 50 次录音启动/停止，并包含多次 5 分钟以上录音，不再出现 c0000374。
  • 在启用 Windows page heap 或使用带符号的诊断构建时，能够定位首次越界写或非法释放的位置，而不是只看到事后堆检查。
  • 对 48 kHz、单声道、F32 的虚拟音频设备补充录音回调、停止和 Stream 释放路径的回归测试。
  • 如果确认是特定音频驱动或第三方进程内钩子导致，OpenLess 应安全拒绝该设备或提示用户，而不是静默崩溃。
  • 修复版连续正常使用至少 3 天，崩溃频率从当前约 2 次/天降为 0。
TODO / 不确定项
  • 缺少与 2.0.2 Beta.2 EXE 匹配的 PDB，无法从现有转储还原完整应用调用栈。
  • 尚未隔离 WO Mic、MacType 和 OpenLess 音频生命周期三者的责任，也未在实体麦克风上完成对照测试。
  • 尚未启用 page heap，也未安装 #1227 中维护者提供的诊断构建。
  • 未确认 #1227 的 Windows 10/2.0.1 报告与本次 Windows 11/2.0.2 Beta.2 报告是否属于同一根因。
  • 未公开上传语音、完整日志或内存转储，以免包含设备名称、输入内容或其他敏感信息；如有需要，可提供进一步脱敏的事件与时间线。
Vorherrschende Sprache
Rust
Sterne
3.7k
Forks
349
Ø Merge
2 T. 14 Std.
Gemergte PRs (30 T.)
97

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus Open-Less/openless

Alle Issues in Open-Less/openless

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.