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

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)

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.

Start at OpenClawTray.Program.Main and trace the UI mount paths named in the report, especially V1Protocol.Descriptor.OneWayPropEntry.Mount and RichTextBlockElement within an ExpanderHandler. Reproduce an Expander containing rich text or capture a WER dump, then verify the tray no longer terminates or enters the RestartAgent crash loop.