[Bug] OpenClaw.Tray.WinUI v2026.7.1 UI hang/crash (AppHang + APPCRASH combase.dll) under heavy agent event streaming

[LCS-333888]

描述 / Description

OpenClaw Companion 桌面客户端（OpenClaw.Tray.WinUI.exe）v2026.7.1 在 agent 会话活动、流式输出时，UI 线程会反复无响应（AppHang），严重时崩溃（APPCRASH），需要反复手动重启。核心问题疑似是 UI 线程在收到大量 agent 流式事件时被事件风暴刷死。

The OpenClaw Companion desktop client (OpenClaw.Tray.WinUI.exe) v2026.7.1 repeatedly hangs (AppHang) and sometimes crashes (APPCRASH) when an agent session is active with streaming output. Suspected root cause: the UI thread is overwhelmed by a flood of agent streaming events.

复现步骤 / Steps to reproduce

1. 启动桌面 Companion v2026.7.1。
2. 让 agent（例如默认 main 会话）产生流式回答或长命令输出。
3. 客户端开始大量接收 agent 事件（日志中 Received event: agent、stream=item、stream=command_output），每秒可达数十条。
4. 客户端 UI 卡住 → 几秒到几十秒后被系统判定无响应（AppHangTransient / AppHangB1），严重时直接崩溃退出。

预期行为 / Expected

客户端应能正常处理事件流，不卡顿、不崩溃。

实际行为 / Actual

UI 线程在事件风暴下挂起/崩溃，频繁出现，需手动重启客户端。

环境 / Environment

• OS: Windows 10.0.26200 (x64)
• OpenClaw.Tray.WinUI.exe v2026.7.1 (Build 4206611)
• Node: 22.23.2
• 网关: OpenClaw 2026.7.1-2

崩溃证据 / Crash evidence

• APPCRASH 模块: CoreMessagingXP.dll + combase.dll，异常代码 0xc000027b
• 多次 AppHangTransient（UI 无响应）、AppHangB1（UI 挂起被强制关闭）、Application Error 1000
• 崩溃转储: OpenClaw.Tray.WinUI.exe.21280.dmp（43MB，22:52 生成）
• 客户端日志: 事件风暴期间每秒数十条 agent 事件

备注 / Notes

• 将客户端 LogLevel 从 trace 降为 warn 对运行时无效；default-config.json 看起来是安装器模板而非运行时配置，望确认。
• 网关与网页版(dashboard)工作正常，问题仅在桌面 WinUI 客户端。

附件 / Attachments

崩溃转储(2)、客户端日志、事件记录、版本信息已打包为 zip（约 20MB），将作为评论上传。

[LCS-333888]

证据附件说明 / Evidence attachments note

已收集并打包崩溃证据，因 GitHub issue 不支持直接附件，暂通过此处说明、可按需提供给维护者：

• OpenClaw.Tray.WinUI.exe.21280.dmp（43MB，22:52 崩溃转储）
• OpenClaw.Tray.WinUI.exe.23904.dmp（41MB，8/7 崩溃转储）
• openclaw-tray.log（事件风暴日志）
• crash-events.txt（12 条崩溃/挂起事件记录）
• version-info.txt（版本信息）

原始文件压缩包约 20MB，位于本机 D:\AI\OpenClaw-Downloads\Files\openclaw-crash-bug-report-20260811-230834.zip。如需通过其他渠道（如上传到临时存储、或提供本地访问方式）发送，请回复告知即可。

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 14, 2026, 7:59 PM ET / 23:59 UTC.

Summary
Keep open. Current main still routes each inbound agent event through two per-event WinUI dispatcher paths, and the explicitly linked open PR owns the bounded/coalesced repair.

Reproducibility: yes. source-reproducible: current main posts one WinUI dispatcher callback per inbound agent event in both diagnostics and native-chat paths. A live current-main Windows stress run remains needed to establish the observed hang rate.

Root-cause cluster
Relationship: canonical
Canonical: #1150
Summary: This is the canonical report; the linked open PR is the active candidate repair for the same dispatcher-overload behavior.

Members:

• fixed_by_candidate: fix(tray): bound streaming UI dispatch work #1158 - Its stated repair bounds the same diagnostics queue and coalesces the same native-chat UI dispatch path.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Next step
The open linked PR already owns the bounded-dispatch repair, so creating another fix lane would duplicate active work.

Review details

Best possible solution:

Land the linked repair only after it proves bounded UI work and sustained tray responsiveness on a current-head Windows runtime while preserving lifecycle and terminal agent events.

Do we have a high-confidence way to reproduce the issue?

Yes, source-reproducible: current main posts one WinUI dispatcher callback per inbound agent event in both diagnostics and native-chat paths. A live current-main Windows stress run remains needed to establish the observed hang rate.

Is this the best way to solve the issue?

Yes. The linked PR's bounded diagnostic batching and coalesced chat rendering target the two proven per-event dispatch paths without changing the gateway protocol.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The linked repair has not yet supplied required current-head Windows stress proof or completed its required build and tray-test validation, so landing it without that evidence could leave the reported responsiveness failure unresolved.

Codex review notes: model internal, reasoning high; reviewed against fc9add75eda7.

Label changes

Label justifications:

• P1: The tray companion can repeatedly hang or exit during ordinary agent streaming, interrupting active desktop workflows.
• impact:crash-loop: The report and corroborating comment describe AppHang and APPCRASH behavior that requires restarting the desktop process.

Evidence reviewed

What I checked:

• Current diagnostics path remains unbounded: Each agent event calls EnqueueModelUpdate, which posts one DispatcherQueue callback when off the UI thread; no batching or pending-work bound is present on current main. (src/OpenClaw.Tray.WinUI/Services/GatewayService.cs:406, fc9add75eda7)
• Current native-chat path remains per-event: Every mapped agent event calls ApplyEventAndPublish, which publishes a snapshot; the production post callback enqueues each action separately on DispatcherQueue. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:3148, fc9add75eda7)
• Released provenance: Blame attributes the current dispatcher helper, agent-event handler, and chat publish path to the v2026.7.1 commit, which is contained by tag v2026.7.1; current main has no repair for these paths. (src/OpenClaw.Tray.WinUI/Services/GatewayService.cs:88, 4206611f2b2e)
• Active canonical repair: The provided discussion context shows an open PR explicitly linked with closing syntax and describes bounded diagnostic batching plus coalesced native-chat delivery. (26475c2ef549)
• Maturity label unavailable: The required shortlist helper could not load because this checkout has no qa/maturity-scores.yaml, so a stable-maturity label is not asserted.

Likely related people:

• Scott Hanselman: The current diagnostic dispatcher helper, agent-event handler, chat provider, and dispatcher post adapter blame to the v2026.7.1 implementation commit. (role: introduced current event-dispatch implementation; confidence: high; commits: 4206611f2b2e; files: src/OpenClaw.Tray.WinUI/Services/GatewayService.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Tray.WinUI/Chat/ReactorChatHostExtensions.cs)
• Barbara Kudiess: Recent main history shows successive tray orchestration and App ownership refactors adjacent to the affected composition path. (role: recent tray orchestration contributor; confidence: medium; commits: bc518f7bd158, 3a097bc85f7b, 17a8b0363a82; files: src/OpenClaw.Tray.WinUI/App.xaml.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[AnvinaLI]

Additional repro evidence from the same version (v2026.7.1, Build 4206611), reproduced on 2026-08-12:

1. 100% CPU on a single background thread on every launch - 3 consecutive launches (normal boot autostart + 2 manual restarts), all identical. All other threads idle/waiting.
2. Network/event layer stays healthy the whole time: tick heartbeats, health checks and session.message events keep arriving and are logged, but the UI is unresponsive.
3. 100% CPU persists in pure tray mode with no main window (MainWindowHandle == 0) - so this is not only about rendering an open chat window; the dispatcher path keeps spinning even when no chat window is shown.
4. Resetting last-chat-state.json (empty DefaultThreadId) before launch does not help.
5. Repro is tied to active event flow on the bound session: after restart, CPU stays pinned at 100% as soon as session.message events arrive (the agent session has a long history, seq > 2800).

This matches the two per-event WinUI dispatcher queue paths described in the review - the coalescing fix should address it. Happy to share openclaw-tray.log + thread-level CPU sampling details if useful.