[Bug] Windows Hub tray (OpenClaw.Tray.WinUI.exe) crashes repeatedly with access violation in Microsoft.UI.Reactor.Core during UI mount

[CharlieZhang0917]

Moved from openclaw/openclaw#125576 — that repo's maintainers closed it as outside their boundary and directed Windows Hub / tray issues here (docs/platforms/windows.md: "openclaw-windows-node release page"). Reposting the full report below.

---

Summary

The Windows Hub system tray app (OpenClaw.Tray.WinUI.exe, v2026.7.1.0) crashes with an access violation (0xc0000005) inside Microsoft.UI.Reactor.Core while mounting UI elements. Since installation it has crashed 8 times in two distinct stack paths. The gateway itself is unaffected.

Environment

• OpenClaw: 2026.7.1-2 (latest stable at time of report)
• Companion / Windows Hub: OpenClaw.Tray.WinUI.exe v2026.7.1.0
• OS: Windows 11, build 10.0.26200 (x64)
• .NET runtime: 10.0.10 (coreclr.dll 10.0.1026.32716)
• Windows Error Reporting: APPCRASH, P1 OpenClaw.Tray.WinUI.exe, exception 0xc0000005

Crash timeline (Windows Application event log, .NET Runtime 1026 + Application Error 1000)

Time (local, +08:00)	First stack frame
2026-08-14 19:18	V1Protocol.Descriptor.OneWayPropEntry\3.Mount`
2026-08-14 19:19	V1Protocol.Descriptor.OneWayPropEntry\3.Mount`
2026-08-14 19:49	V1Protocol.Descriptor.OneWayPropEntry\3.Mount`
2026-08-14 19:55	V1Protocol.Descriptor.OneWayPropEntry\3.Mount`
2026-08-14 19:56	V1Protocol.Descriptor.OneWayPropEntry\3.Mount`
2026-08-14 19:58	V1Protocol.Descriptor.OneWayPropEntry\3.Mount`
2026-08-18 02:16	RichTextBlockElement+<>c.<.cctor>b__109_22
2026-08-18 11:11	RichTextBlockElement+<>c.<.cctor>b__109_22

Notes:

• Companion installed 2026-08-14 ~16:44. Six crashes within 40 minutes that evening (19:18 → 19:58) = crash / auto-restart loop (RestartAgent.exe restarts the tray after each crash).
• The 2026-08-18 02:16 crash happened while unattended, suggesting the bug can be triggered by background rendering, not only explicit UI actions.
• All 8 crashes share the same exception code and the same subsystem (Microsoft.UI.Reactor.Core); the two stack paths differ only in which Reactor element is being mounted.

Stack traces

Path A (6 crashes): OneWayPropEntry.Mount

at Microsoft.UI.Reactor.Core.V1Protocol.Descriptor.OneWayPropEntry`3[[System.__Canon,...],[System.__Canon,...],[System.Boolean,...]].Mount(System.__Canon, System.__Canon)
at Microsoft.UI.Reactor.Core.V1Protocol.Descriptor.DescriptorHandler`2[...,...].Mount(Microsoft.UI.Reactor.Core.V1Protocol.MountContext, System.__Canon)
at Microsoft.UI.Reactor.Core.Reconciler.Mount(Microsoft.UI.Reactor.Core.Element, System.Action)
at Microsoft.UI.Reactor.Core.V1Protocol.V1HandlerAdapter`2[...,...].DispatchChildrenMount(...)
... (repeated DispatchChildrenMount/Mount frames) ...

Path B (2 crashes): RichTextBlockElement

at Microsoft.UI.Reactor.Core.RichTextBlockElement+<>c.<.cctor>b__109_22(Microsoft.UI.Xaml.Controls.RichTextBlock, Boolean)
at Microsoft.UI.Reactor.Core.V1Protocol.Descriptor.DescriptorHandler`2[...,...].Mount(...)
at Microsoft.UI.Reactor.Core.Reconciler.Mount(...)
... (repeated DispatchChildrenMount/Mount frames) ...
at Microsoft.UI.Reactor.Core.V1Protocol.Handlers.ExpanderHandler.Mount(...)
...
at Microsoft.UI.Xaml.Application.Start(Microsoft.UI.Xaml.ApplicationInitializationCallback)
at OpenClawTray.Program.Main(System.String[])

Path B shows the mount tree includes an ExpanderHandler whose children contain a RichTextBlock — the crash occurs while the Reactor mounts that element (unhandled exception in the static cctor lambda, then the process is terminated by the runtime).

Expected behavior

The tray app should not crash when rendering expandable/rich-text items, and should not enter a crash-restart loop.

Actual behavior

Unhandled exception → process terminated; RestartAgent restarts it; crash repeats (observed up to 6 times in 40 minutes). The gateway is not affected.

Workaround (user-side)

Disable the tray app's startup entry (HKCU\...\Run OpenClawTray) and use the browser Control UI instead. This avoids the crash loop but does not fix the underlying rendering bug.

Repro hints

• Triggering seems to involve rendering an Expander containing rich text (e.g., a message/notification list item). Exact user action unknown; the unattended 02:16 crash suggests it can fire from background updates too.
• Happy to run any debug build / capture more traces (e.g., WER dump) if useful.

[clawsweeper]

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

Summary
Keep open. Two users corroborate the native crash, and the newly shipped session-switch mitigation does not establish that this older access violation is fixed.

Reproducibility: no. high-confidence current-main reproduction is established. Two users provide matching native failure evidence, but the precise tool payload, action sequence, and current-release result remain missing.

Ways to help us reproduce this

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

Next step
Continue the existing request for redacted native analysis, module versions, and the triggering tool action on the current release before assigning a narrow repair; the evidence does not support automatic fix dispatch.

Review details

Best possible solution:

Restore stable rich-text mounting and tail navigation while preserving selection and scrolling, with an in-app recovery action if repeated crashes prevent opening Hub.

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

No high-confidence current-main reproduction is established. Two users provide matching native failure evidence, but the precise tool payload, action sequence, and current-release result remain missing.

Is this the best way to solve the issue?

Unclear: the shipped rollback addresses a documented newer row-lifetime regression, while replacing tail navigation also has reported final-message positioning problems; neither is yet a proven repair for this access violation.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The exact triggering action and native lifetime failure remain unknown; shared WinUI stack frames do not establish that the newer session-switch regression has the same cause.
• No current-release reproduction or after-fix result from either affected machine establishes whether v2026.9.4 resolves the original crash.

Codex review notes: model internal, reasoning medium; reviewed against 3c43751b2bac.

Label changes

Label justifications:

• P0: Repeated native-app termination with automatic relaunch and no demonstrated in-product recovery meets the required crash-loop and blocked-recovery rubric.
• impact:crash-loop: The reporter records six crashes within forty minutes with RestartAgent relaunching the tray.
• impact:ux-release-blocker: The documented escape requires disabling tray startup and abandoning the native app for browser Control UI.

Evidence reviewed

What I checked:

• Corroborated native failure and existing diagnostic request: The report records eight crashes on Companion v2026.7.1.0. A second reporter identifies RichTextBlock.set_IsTextSelectionEnabled during Reactor mounting beneath StartBringItemIntoView. shanselman requested redacted WinDbg analysis, loaded module versions, the preceding action, and payload shape, explicitly warning against public process dumps. See [Bug] Windows Hub tray (OpenClaw.Tray.WinUI.exe) crashes repeatedly with access violation in Microsoft.UI.Reactor.Core during UI mount #1173 (comment) and [Bug] Windows Hub tray (OpenClaw.Tray.WinUI.exe) crashes repeatedly with access violation in Microsoft.UI.Reactor.Core during UI mount #1173 (comment).
• Current source retains the reported rendering and navigation surfaces: ToolCallCardRenderer builds expandable tool details containing a selectable RichTextBlock. ReactorItemsViewScrollController.StartTailRequest still calls StartBringItemIntoView after checking loaded state and tail identity. These establish an owned, relevant path, but do not prove the native failure mechanism. (src/OpenClaw.Tray.WinUI/Chat/ToolCallCardRenderer.cs:108, 3c43751b2bac)
• Existing native test has a relevant coverage boundary: ReactorToolActivityProofTests reconciles production tool controls without attaching them to the VSTest visual tree because applying the unpackaged Expander template crashes Microsoft.UI.Xaml. Its selectable-output assertions therefore do not establish that the reported mounted, scrolling scenario is safe. (tests/OpenClaw.Tray.UITests/ReactorToolActivityProofTests.cs:48, 3c43751b2bac)
• Latest release mitigates a distinct documented regression: GitHub confirms fix(chat): avoid session-switch crashes without clipping Markdown lists #1426 (fix(chat): avoid session-switch crashes without clipping Markdown lists) merged as 3dda3cf. Its body attributes the targeted E_INVALIDARG regression to Reactor preview.13 and rolls both packages back to preview.12, which current source confirms. It explicitly leaves StartBringItemIntoView unchanged and records incomplete full-app crash verification. That does not establish resolution of this August access violation. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:99, 3c43751b2bac)
• Release inclusion checked without claiming this issue fixed: The latest-release API lists the rollback in v2026.9.4, published September 15, 2026; git tag containment also returns v2026.9.4 for its merge commit. Release inclusion proves shipment of that mitigation, not resolution of this report. (3dda3cf87fb9)
• Canonical search did not establish a replacement: The access-violation search found Windows Companion (WinUI) crashes with System.ArgumentException: The parameter is incorrect when opening a chat session #1419, whose full body describes v2026.9.3 ArgumentException crashes. fix(chat): work around WinUI session-switch crash #1407 (fix(chat): work around WinUI session-switch crash) remains open and unmerged. [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167 separately describes a sustained history-load hang. None establishes identical root cause or resolves this report.

Likely related people:

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

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.

[CharlieZhang0917]

Additional repro observation (2026-08-18, Windows 11, tray v2026.7.1.0): while interacting with the tray UI (tool-call card area), the app hung and Windows recorded AppHangTransient at 12:37:29; RestartAgent relaunched a fresh instance at 12:37:33. No screenshot/video captured, but WER metadata for the hang is in the Application event log (report id feefca5a-e35e-4727-89ec-f5a5200d6acf). Happy to grab the WER dump if useful.

[MilkyWay008]

The 0xc0000005 in Microsoft.UI.Reactor.Core during mount smells like the Windows App Runtime being out of sync with what the app manifest expects...... that's the classic native crash cause. Check the installed runtime against the manifest (winget list Microsoft.WindowsAppRuntime), repair or reinstall to match, and clear the %LOCALAPPDATA% OpenClaw cache in case there's a stale XBF. Also grab the WER dump (report id feefca5a-e35e-4727-89ec-f5a5200d6acf) for the maintainers, they'll need it to repro. Oh btw, I keep a portable Hermes OTG on a USB stick as my rescue agent for exactly these broken Windows installs, handy for diagnosing the machine from a working agent, https://github.com/MilkyWay008/Hermes-OTG if you want to look at it.

[shanselman]

Thanks for offering the WER dump. Please do not attach a full process dump publicly because it may contain prompts, paths, tokens, or other user data. The most useful next evidence is: (1) redacted WinDbg !analyze -v output for report feefca5a-e35e-4727-89ec-f5a5200d6acf, including the exception stack and loaded versions of Microsoft.UI.Reactor.Core, Microsoft.WindowsAppRuntime, and OpenClaw.Tray.WinUI; (2) the exact tool-card action or background update immediately before the crash; and (3) a redacted shape of the tool detail payload, without content or credentials. If a full dump is needed after that, please share it only through a maintainer-approved private channel.

[ljy520423]

Additional instance confirming the same crash, with a more precise stack trace.

Environment matches: Windows 11 10.0.26200 x64, Companion OpenClaw.Tray.WinUI.exe v2026.7.1.0, .NET 10.0.10 (coreclr 10.0.1026.32716), Microsoft.UI.Xaml.dll 3.2.3.0.

Two crashes observed today (2026-08-19, +08:00), with two distinct exception codes:

Time	Exception	Faulting module
14:27:55	0xc000027b (stowed exception)	Microsoft.UI.Xaml.dll 3.2.3.0
14:40:51	0xc0000005 (access violation)	coreclr.dll

The second crash's full .NET Runtime (Event 1026) stack traces precisely to:

Microsoft.UI.Xaml.Controls.RichTextBlock.set_IsTextSelectionEnabled
  ← Microsoft.UI.Reactor.Core.RichTextBlockElement (.cctor)
  ← V1Protocol Reconciler.Mount (…ExpanderHandler…)
  ← ItemsView.StartBringItemIntoView
  ← OpenClawTray.Chat …StartTailRequest (auto-scroll to tail)
  ← Program.Main

This confirms the "selectable rich text inside a mounted Reactor expander" hypothesis (matches the maintainer summary), and ties the crash directly to auto-scroll-to-tail + mounting a rich-text/expander message during chat rendering.

No dump attached (per the note about sensitive data). Happy to run redacted WinDbg !analyze -v if a specific WER report id is still useful.