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

Activity

1. github-project-automation

   added this to Windows Companion Appon Aug 11, 2026
2. github-project-automation

   moved this to Backlog in Windows Companion Appon Aug 11, 2026
3. LCS-333888 commented on Aug 11, 2026

   

   LCS-333888

   on Aug 11, 2026

   Author

   More actions

   证据附件说明 / 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。如需通过其他渠道（如上传到临时存储、或提供本地访问方式）发送，请回复告知即可。
4. clawsweeper

   added

   clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.ClawSweeper found a clear likely implementation shape for this issue.

   clawsweeper:queueable-fixClawSweeper marked this issue as an existing queue_fix_pr work candidate.ClawSweeper marked this issue as an existing queue_fix_pr work candidate.

   clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.

   impact:crash-loopThis issue is about crashes, hangs, restart loops, or process-level availability.This issue is about crashes, hangs, restart loops, or process-level availability.

   issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.

   no-staleExempts this issue from stale automation.Exempts this issue from stale automation.

   P1Urgent regression or broken agent/channel workflow affecting real users now.Urgent regression or broken agent/channel workflow affecting real users now.

   on Aug 11, 2026
5. clawsweeper commented on Aug 11, 2026

   

   clawsweeperBot

   on Aug 11, 2026 – with ClawSweeper

   Last edited by clawsweeper

   More actions

   Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 2, 2026, 1:21 PM ET / 17:21 UTC.

   Summary
   Keep open. Current main still converts processed agent events into individual snapshots, queues each snapshot onto the WinUI dispatcher, and immediately applies each one to the native chat render root. The linked open repair PR explicitly owns the bounded/coalesced fix, so a second fix lane would duplicate active work.

   Reproducibility: yes. at source level. A burst of accepted agent events reaches one Publish call per resulting snapshot, each producing a dispatcher callback and native setSnapshot render; no live Windows reproduction was executed in this read-only review.

   Root-cause cluster
   Relationship: canonical
   Canonical: #1150
   Summary: This issue is the canonical report for live agent-event streaming saturation. The linked PR is the candidate repair, while the history-projection report describes a distinct trigger.

   Members:

   • fixed_by_candidate: fix(tray): bound streaming UI dispatch work #1158 - Its supplied body explicitly closes this issue and implements the bounded/coalesced streaming repair, but it remains open.
   • adjacent_distinct: [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167 - Its supplied report identifies a session-switch history-projection hang rather than a high-rate live event stream.

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

   Next step
   The open linked repair PR #1158 already owns the bounded-dispatch change, so another automated fix PR would duplicate active work.

   Review details

   Best possible solution:

   Land a narrowly validated bounded/coalesced event-publication path that preserves lifecycle events and proves the tray remains responsive under a real high-rate Windows agent-event stream.

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

   Yes, at source level. A burst of accepted agent events reaches one Publish call per resulting snapshot, each producing a dispatcher callback and native setSnapshot render; no live Windows reproduction was executed in this read-only review.

   Is this the best way to solve the issue?

   Yes, conditionally. Bounding disposable event work and coalescing snapshot delivery addresses the demonstrated queue-and-render amplification path, but the linked implementation still needs current-head Windows proof before it resolves the report.

   AGENTS.md: found and applied where relevant.

   Remaining risk / open question:

   • The linked repair PR is still open and its supplied context reports unresolved current-head Windows responsiveness proof, so it cannot yet be treated as a landed resolution.
   • The separately reported Sandbox XAML failure, session-history hang, and native crash signature are not proven to share this streaming-event cause; the session-history behavior is separately tracked by [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167.

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

   Label changes

   Label justifications:

   • P1: Multiple reporters describe recurring WinUI hangs during active agent sessions, while gateway health continues to operate.
   • impact:crash-loop: The issue documents AppHang symptoms and occasional desktop-client process crashes.

   Evidence reviewed

   What I checked:

   • Current per-event publication path: Each accepted agent event iterates its resulting snapshots and publishes each one; this remains present on current main. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1397, 2cf875d5529a)
   • Dispatcher enqueue remains uncoalesced: Publish creates a changed-event payload and posts one callback per snapshot when a UI dispatcher is configured. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:1810, 2cf875d5529a)
   • Queued snapshots drive native rendering: The native chat root subscribes to provider changes and calls setSnapshot for every delivered snapshot. (src/OpenClaw.Tray.WinUI/Chat/OpenClawReactorChatRoot.cs:84, 2cf875d5529a)
   • Production UI-dispatch wiring: App constructs the chat coordinator with the DispatcherQueue-backed posting adapter, connecting provider publications to the WinUI queue. (src/OpenClaw.Tray.WinUI/App.xaml.cs:600, 2cf875d5529a)
   • Relevant feature history: Recent history shows the chat provider’s runtime-state refactor and the native Reactor chat surface work, identifying the shared ownership area without establishing a regression cause. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, f8a8825ccbb4)
   • Release and current-main check: The reported v2026.7.1-2 release commit is an ancestor of current main, which is four commits newer; current main still contains the unbounded publication path. The linked fixing PR remains open in the supplied GitHub context. (2cf875d5529a)

   Likely related people:

   • Barbara Kudiess: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
   • Caleb Eden: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
   • Karen: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

   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.
6. AnvinaLI commented on Aug 12, 2026

   

   AnvinaLI

   on Aug 12, 2026

   More actions

   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.
7. clawsweeper

   added

   status: 🚢 actively landingA maintainer or agent is actively driving this item through implementation, validation, or merge.A maintainer or agent is actively driving this item through implementation, validation, or merge.

   and removed

   issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.

   clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.

   on Aug 13, 2026
8. 10 remaining items

   Load more
9. clawsweeper

   added

   issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.

   on Aug 14, 2026
10. zhtty67-rgb commented on Aug 16, 2026

    

    zhtty67-rgb

    on Aug 16, 2026

    More actions

    Same build (v2026.7.1 / 4206611) — confirming, and adding a separate crash path not covered by the streaming-storm description:

    SandboxPage XamlParseException (deterministic): navigating to the Sandbox page (or saving any setting that triggers a UI refresh to it) throws an unhandled XamlParseException:

    Failed to assign to property 'Microsoft.UI.Xaml.Controls.Primitives.RangeBase.Minimum'. [Line: 0 Position: 0]
       at OpenClawTray.Pages.SandboxPage.InitializeComponent()  (SandboxPage.g.i.cs:99)
       at OpenClawTray.Windows.HubWindow.NavigateInternal(String tag)  (HubWindow.xaml.cs:710)
    

    Recorded twice in crash.log on 2026-08-16 (23:25:51 / 23:25:56); tray log shows Settings saved -> [SETTINGS] Change impact: UiOnly immediately before the crash. The element is SandboxPage.xaml:427:

    <Slider x:Name="TimeoutSlider" Minimum="5" Maximum="300" StepFrequency="5" Value="30" SmallChange="5" LargeChange="15" ValueChanged="OnTimeoutChanged" />

    Literals are valid (5 <= 30 <= 300) — looks like a WinUI RangeBase.Minimum property-assignment failure during XAML load, not a bad value.

    Workaround that works for us: downgraded to v0.6.12 — same XAML, but does not crash (different WinAppSDK). Verified by selecting the 沙盒 (Sandbox) nav item under 0.6.12: process stays alive, no new crash.log entry. Also had to re-approve device pairing after the downgrade (openclaw devices approve) — fine afterwards.

    Environment: Windows 11, tray v2026.7.1 (4206611), gateway 2026.7.1-2, also reproduced AppHang (100% CPU single thread) matching the report above.
11. zhtty67-rgb commented on Aug 16, 2026

    

    zhtty67-rgb

    on Aug 16, 2026

    More actions

    Same build (v2026.7.1 / 4206611) — confirming, and adding a separate crash path not covered by the streaming-storm description:

    SandboxPage XamlParseException (deterministic): navigating to the Sandbox page (or saving any setting that triggers a UI refresh to it) throws an unhandled XamlParseException:

    Failed to assign to property 'Microsoft.UI.Xaml.Controls.Primitives.RangeBase.Minimum'. [Line: 0 Position: 0]
       at OpenClawTray.Pages.SandboxPage.InitializeComponent()  (SandboxPage.g.i.cs:99)
       at OpenClawTray.Windows.HubWindow.NavigateInternal(String tag)  (HubWindow.xaml.cs:710)
    

    Recorded twice in crash.log on 2026-08-16 (23:25:51 / 23:25:56); tray log shows Settings saved -> [SETTINGS] Change impact: UiOnly immediately before the crash. The element is SandboxPage.xaml:427:

    <Slider x:Name="TimeoutSlider" Minimum="5" Maximum="300" StepFrequency="5" Value="30" SmallChange="5" LargeChange="15" ValueChanged="OnTimeoutChanged" />

    Literals are valid (5 <= 30 <= 300) — looks like a WinUI RangeBase.Minimum property-assignment failure during XAML load, not a bad value.

    Workaround that works for us: downgraded to v0.6.12 — same XAML, but does not crash (different WinAppSDK). Verified by selecting the 沙盒 (Sandbox) nav item under 0.6.12: process stays alive, no new crash.log entry. Also had to re-approve device pairing after the downgrade (openclaw devices approve) — fine afterwards.

    Environment: Windows 11, tray v2026.7.1 (4206611), gateway 2026.7.1-2, also reproduced AppHang (100% CPU single thread) matching the report above.
12. sebastian-openclaw commented on Aug 16, 2026

    

    sebastian-openclaw

    on Aug 16, 2026

    More actions

    Independent Omega reproduction on the same release: Companion v2026.7.1, commit 4206611f2b2e47cd575e1c8aa94e3e7708f6dd96.

    Recurring AppHang evidence

    • Observed UI hangs on 2026-08-13 around 14:00 and 2026-08-16 around 13:12 local time while the gateway remained healthy.
    • The Aug 13 hang followed session.message and then a very large agent-event stream.
    • During the reproduced Aug 16 13:12 hang, Companion logs showed approximately 495 agent events and 80 session.tool events in roughly two minutes, peaking around 114 log/event operations per second.
    • The native WinUI stopped updating/became unresponsive and Windows recorded AppHangB1; gateway health checks continued to pass.

    Exact-release source inspection matches this issue's proposed mechanism: OpenClawChatDataProvider.OnAgentEventReceived maps each event and calls ApplyEventAndPublish; each publication raises Changed, and the OpenClawReactorChatRoot handler calls setSnapshot(args.Snapshot), producing a render for every publication. This independently supports the bounded/coalesced publication direction in #1158.

    Scope clarification

    Omega also reproduced a session-switch hang while loading approximately 200 history messages. That path is now tracked separately in #1167 because it can require batching the initial history projection/render even after per-event streaming updates are coalesced.

    There was one 2026-08-13 crash involving CoreMessagingXP.dll, but the available evidence does not establish that the crash and the recurring AppHang/UI-saturation path have the same cause. This confirmation should therefore be treated as evidence for the recurring AppHang behavior, not as attribution of that separate crash.
13. MilkyWay008 commented on Aug 20, 2026

    

    MilkyWay008

    on Aug 20, 2026

    More actions

    Saw the 0xc000027b crash in CoreMessagingXP.dll too, that's the nasty one. The reproducible bit looks like the SandboxPage TimeoutSlider failing to set RangeBase.Minimum (SandboxPage.xaml:427), which then blows up in native code, so it reads like a XAML binding bug rather than your box. Sticking with the v0.6.12 downgrade is the sane call until they patch it, and the crash bundle you grabbed is exactly what the maintainers need. Oh btw, when these agent updates leave an install half-broken I keep a portable Hermes OTG on a USB stick around to diagnose the sick one side-by-side, imo it's saved me a few times, https://github.com/MilkyWay008/Hermes-OTG
14. shanselman

    removed

    status: 🚢 actively landingA maintainer or agent is actively driving this item through implementation, validation, or merge.A maintainer or agent is actively driving this item through implementation, validation, or merge.

    on Sep 2, 2026
15. samanthamsong

    added this to the 9/30 MXC Release milestone on Sep 4, 2026
16. oywino commented on Sep 6, 2026

    

    oywino

    on Sep 6, 2026

    Last edited by oywino

    More actions

    Additional observation from my system:

    I previously reproduced the WinUI hang/crash with the same CoreMessagingXP.dll / 0xc000027b signature. At the time of the hang, I noticed that two OpenClaw.Tray.WinUI.exe processes were running even though I only launched it once. I then killed both processes, started the Companion once, and again it launched a second process by itself, and hung.

    I then killed both processes, started the Companion once with the Gateway stopped, and confirmed only one process existed. After starting the Gateway, the Companion automatically reconnected and remained responsive. A process check showed exactly one OpenClaw.Tray.WinUI.exe.

    So on my system, Gateway connectivity/event streaming by itself is currently not sufficient to reproduce the hang. The hang I observed coincided with two Companion instances being present.

    I have not yet determined what caused the second Companion instance to start, so I cannot say whether duplicate instances are the root cause, a contributing factor, or unrelated. But it may be worth checking whether multiple tray instances exacerbate the dispatcher/event-stream problem addressed by #1158.

    A single manual launch appeared to start two Companion instances concurrently. Evidence: the Companion startup/greeting notification appeared twice. Only one tray icon was visible. Task Manager initially showed one OpenClaw.Tray.WinUI.exe; after terminating it, another running instance became visible and could also be terminated.
17. github-actions commented on Sep 20, 2026

    

    github-actionsBot

    on Sep 20, 2026 – with GitHub Actions

    Contributor

    More actions

    This issue has been automatically marked as stale due to inactivity.
    Please add updated OpenClaw Windows details or it will be closed.
18. github-actions

    added

    stale

    on Sep 20, 2026
19. oywino commented on Sep 20, 2026

    

    oywino

    on Sep 20, 2026 – with ChatGPT Codex Connector

    More actions

    Current-status update to prevent stale closure:

    This still appears unresolved and worth keeping open.

    • The original candidate repair PR fix(tray): bound streaming UI dispatch work #1158 was closed without merging.
    • The later overlapping chat-coalescing PR fix(chat): make snapshot coalescing race-free #1301 was also closed without merging.
    • I cannot find a current open PR owning [Bug] OpenClaw.Tray.WinUI v2026.7.1 UI hang/crash (AppHang + APPCRASH combase.dll) under heavy agent event streaming #1150.
    • Current main still routes each received agent event individually through GatewayService.OnAgentEventReceived() → EnqueueModelUpdate(() => _state.AddAgentEvent(evt)), so the high-rate dispatcher-pressure path identified in this issue is still present at least at that layer.

    I am not claiming that the separate 0xc000027b crash necessarily has the same cause as the recurring AppHang/event-stream saturation. The useful point here is that the source-proven streaming-pressure issue does not appear to have a landed fix yet.

    My earlier duplicate-Companion-process observation remains documented above, but I do not currently have a fresh reproduction of that behavior on the latest build.
20. github-actions

    removed

    stale

    on Sep 21, 2026
21. samanthamsong

    closed this as a duplicateof Windows Companion (WinUI) crashes with System.ArgumentException: The parameter is incorrect when opening a chat session #1419 on Sep 23, 2026
22. github-actions

    locked as resolved and limited conversation to collaborators on Sep 26, 2026
23. samanthamsong

    removed this from Windows Companion Appon Oct 16, 2026