Windows Tray app crash-loops with Microsoft.UI.Xaml.LayoutCycleException under rapid event throughput

Environment

OpenClaw Windows Tray version: 2026.7.1 (also reproduced on 2026.7.1-2)
OS: Windows 10.0.29648.0, x64
Gateway version: 2026.7.1 (remote gateway over wss://)
Topology: Remote gateway, node mode enabled
Summary
The Windows tray app repeatedly crashes and auto-restarts under load, with the following unhandled exception in crash.log:

Copy
Microsoft.UI.Xaml.LayoutCycleException: The text associated with this error code could not be found.
Element is already the child of another element.
Observed pattern
Over a ~30 minute window, the tray app restarted at least 6 times:

21:05:41, 21:08:54, 21:12:30, 21:25:43 (local +02:00), plus the crash itself at 21:21:02
Restart intervals as short as ~3 minutes apart during the worst period
Suspected trigger
Tray log (openclaw-tray.log) shows very high-frequency inbound events during active sessions — presence, health, node.invoke.request/result, chat, sessions.changed, agent stream events — sometimes multiple events within the same millisecond. These appear to feed directly into UI-bound collections (activity stream, node list, session list). Under sustained high throughput, this likely races the WinUI layout/measure-arrange pass, causing an element to be re-parented while still attached elsewhere — the classic root cause of LayoutCycleException.

Impact

Tray app becomes unusable during high-activity sessions (agent actively running tool calls/exec approvals)
Requires manual force-kill + relaunch to recover
No user-facing error dialog observed — app just disappears/restarts silently
Suggested fixes

Batch/throttle UI updates from the event stream (e.g. coalesce rapid presence/health ticks before dispatching to UI thread)
Ensure all collection mutations happen on the UI thread via DispatcherQueue, not directly from the websocket receive callback
Add global unhandled-exception handling around the XAML layout pass to prevent full app termination (log + recover instead of crash)
Attached crash.log tail:

Copy
[2026-08-30 21:21:02.506] UnhandledException
Microsoft.UI.Xaml.LayoutCycleException: The text associated with this error code could not be found.
Element is already the child of another element.

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 4, 2026, 12:52 AM ET / 04:52 UTC.

Summary
Keep open for targeted maintainer diagnosis. The report documents a severe current-release crash loop, but the supplied exception tail does not identify the reparented control or a reproducible event sequence; current code already serializes gateway-driven state changes onto the UI thread and coalesces Event Stream rendering.

Reproducibility: no. The supplied crash tail and timestamps establish an observed failure, but do not name the control or provide a repeatable event burst; no current-main or latest-release load reproduction was available to inspect.

Regression provenance
Possible regression — suspected (failure trace). No predecessor PR is attributed.

Ways to help us reproduce this

Add a screenshot or short recording showing the behavior.
Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should a Windows tray owner first collect a sanitized control-level stack or dump and a current-release high-throughput reproduction before selecting a UI repair?	Collect focused diagnostics: Obtain a sanitized stack or dump and a reproducible event-burst trace on v2026.7.1-4 before assigning a code change.

Why: The report establishes serious user impact, but source review disproves the proposed direct background collection-mutation mechanism and does not identify the actual WinUI owner.

Next step
The report remains actionable but lacks the control-level failure evidence needed for a safe bounded repair, and its existing labels already route it to maintainer review rather than a new fix PR.

Review details

Best possible solution:

Capture a sanitized full exception stack or dump plus a focused high-throughput reproduction on the latest tray release, then repair the identified view update boundary with a regression-oriented load test.

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

No. The supplied crash tail and timestamps establish an observed failure, but do not name the control or provide a repeatable event burst; no current-main or latest-release load reproduction was available to inspect.

Is this the best way to solve the issue?

Unclear. UI-thread dispatch and Event Stream refresh coalescing already exist, so adding another generic throttle or exception handler is not yet a demonstrated fix; identify the reparenting owner first.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

The exception tail lacks the reparented WinUI element and stack frames, so changing the current dispatcher or debounce path now could mask rather than fix the failure.
No current-release high-throughput reproduction has been captured, so the affected view may be outside the Event Stream path named in the report.

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

Label changes

Label justifications:

P1: Repeated tray termination during active gateway sessions breaks a real user workflow, but the currently supported scope is limited to the reported high-throughput condition.
impact:crash-loop: The report describes at least six tray restarts and manual recovery during a roughly 30-minute activity window.

Evidence reviewed

What I checked:

Reported current-release failure: The issue supplies a LayoutCycleException tail, reports repeated restarts during remote-gateway activity, and identifies versions 2026.7.1 and 2026.7.1-2. A second user comment reports seeing the same exception on 2026.7.1-2, but neither report provides the control-level stack or a load recipe.
Gateway updates are marshaled to the UI thread: GatewayService captures a client generation and uses DispatcherQueue before applying model updates. Its agent-event handler routes events through that helper into AppState. (src/OpenClaw.Tray.WinUI/Services/GatewayService.cs:88, c5105ab06a2f)
State owner enforces UI-thread mutation: AppState documents UI-thread-only property writes and throws in production if AddAgentEvent is called without UI access. (src/OpenClaw.Tray.WinUI/Services/AppState.cs:178, c5105ab06a2f)
Event Stream refresh is coalesced: The Event Stream page marks its filter dirty and posts one low-priority ApplyFilter callback rather than resetting the ListView ItemsSource for every received event. (src/OpenClaw.Tray.WinUI/Pages/AgentEventsPage.xaml.cs:155, c5105ab06a2f)
Feature-history routing: Commit cff1033 introduced the shared AppState and GatewayService event architecture; commit ece875 moved AgentEventsPage to direct AppState observation. This establishes the most relevant historical routing area, not a confirmed regression cause. (src/OpenClaw.Tray.WinUI/Services/GatewayService.cs, cff1033b3bb3)
Latest-release comparison found no known fix: The latest release commit is an ancestor of current main, and the release-to-main range contains no changes to the central GatewayService, AppState, or AgentEventsPage paths. There is no source or history evidence that this report is already fixed. (c5105ab06a2f)

Likely related people:

Ranjesh Jaganathan: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
Barbara Kudiess: 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.

Saw your LayoutCycleException on 2026.7.1-2 too, the silent crash-loop with no dialog is the worst part of it. Before you keep force-killing, flip on WER LocalDumps (HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps) and grab a full dump the next time it dies, then check the .NET Runtime entries in Event Viewer...... those two together will show whether it's really the reparenting view or something earlier in the event burst. Correlating the crash timestamps with the openclaw-tray.log flood is what finally pinned it down for me. oh btw, I keep a portable Hermes OTG on a USB stick as my rescue agent for these Windows agent crash moments, https://github.com/MilkyWay008/Hermes-OTG if you want to look at it.

The "Element is already the child of another element" under LayoutCycleException is a reparenting race in WinUI 3, and it usually hides behind rapid collection churn like you're seeing from the gateway event bursts. What helped me narrow a similar one down: enable the WinAppSDK XAML diagnostics (XamlDiagnostics) and capture a dump at the crash, then look at which ItemsRepeater/ListView is mid-update; the reparenting owner is almost never where the crash log points. In the meantime, one thing worth trying is disabling the tray's live event list rendering during active agent sessions (a settings toggle, or just let the tray show only status and route the event log to a window you open on demand), since batching the UI updates is a legit stopgap while the actual owner gets found. If you want to poke at a standalone Windows tool that runs beside a broken gateway install to test this pattern in isolation, I keep a portable Hermes OTG on a USB stick for exactly these crash-loop situations, https://github.com/MilkyWay008/Hermes-OTG. Hope that unblocks you.

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

Navigation Menu

Repository navigation

Windows Tray app crash-loops with Microsoft.UI.Xaml.LayoutCycleException under rapid event throughput #1270

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Windows Tray app crash-loops with Microsoft.UI.Xaml.LayoutCycleException under rapid event throughput #1270

Description

Activity

clawsweeper commented on Aug 30, 2026

MilkyWay008 commented on Aug 30, 2026

MilkyWay008 commented on Sep 1, 2026

github-actions commented on Sep 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions