[Bug] v2026.9.3: OpenClaw.Tray.WinUI crashes (0xc000027b in Microsoft.UI.Xaml.dll) ~12 s after connect when opening a chat session with history; v2026.7.1-4 fine

[markstones78]

Summary

Windows Companion v2026.9.3 (OpenClaw.Tray.WinUI.exe 2026.9.3+84928c43) crashes ~10–15 s after connecting to a remote gateway, every time the chat view is opened on a session that has history. Reproduced on two Windows 11 machines (build 26200) on the same day the auto-update to 2026.9.3 landed. v2026.7.1-4 on the same machines/gateway did not crash.

Environment

• Companion: v2026.9.3 (auto-updated from v2026.7.1-4 at ~03:41 UTC 2026-09-12)
• OS: Windows 11 Enterprise 10.0.26200
• Gateway: OpenClaw 2026.9.2 (remote, wss:// over Tailscale Serve, device-token auth, protocol 4)
• Chat sessions: the agent's main session with a few dozen messages; sessions carry labels; sessions.visibility=all (12 agents)

Repro

1. Start the Companion; it connects (gateway.self event logged, presenceCount populated) and shows Connected.
2. Open Chat, select a session with history (e.g. the agent's main session).
3. 10–15 s later the process crashes. Reopening reproduces it every time. Deleting last-chat-state.json did not help.

Crash signature (Windows Application log / WER)

Faulting application name: OpenClaw.Tray.WinUI.exe, version: 2026.9.3.0
Faulting module name: Microsoft.UI.Xaml.dll, version: 3.2.3.0
Exception code: 0xc000027b   (once: CoreMessagingXP.dll, 0xc000027b)
WER: APPCRASH P4: combase.dll 10.0.26100.9444, P7: 80070057

Four dumps within three minutes (12:16–12:18 local) on machine A; same signature later on machine B.

Companion diagnostics (diagnostics.jsonl, tail)

{"event":"app.start","metadata":{"nodeMode":false,"useSshTunnel":false}}
{"event":"gateway.self","metadata":{"version":"2026.9.2","protocol":4,"authMode":null,"stateVersionPresence":13,"stateVersionHealth":138,"presenceCount":4}}
{"event":"gateway.health.channels","metadata":{"channelCount":2,"healthyCount":1,"errorCount":0}}
... crash ~12 s later, nothing further logged

Notes

• Transport is fine: the reconnect to the gateway completes within ~1 s of app.start each time (device token reused, no pairing prompt).
• Looks related to [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167 (session switch hang while projecting history) and Windows Tray app crash-loops with Microsoft.UI.Xaml.LayoutCycleException under rapid event throughput #1270 (XAML crash loop under event throughput), but this is a hard crash on a modest session, not a hang.
• Workaround in use: roll back to v2026.7.1-4. Is there a supported way to pin/disable auto-update so a rollback sticks?

[clawsweeper]

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

Summary
Keep open: this is a concrete latest-release crash report on two machines, with no verified fix on main. Related reports provide useful investigation leads but do not establish the same failure.

Reproducibility: no. high-confidence current-main reproduction is established. The two-machine release report supplies a concrete history-opening scenario, but the triggering history content and terminating stack remain unidentified, and native execution was not performed.

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.

Next step
Route to a native chat owner to obtain redacted terminating stacks and compare the affected history on release and main; the unresolved failure boundary and blocked recovery make an autonomous repair premature.

Review details

Best possible solution:

Repair the identified native rendering failure while preserving conversation history, and provide visible recovery that lets users reopen Companion without restoring the failing chat.

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

No high-confidence current-main reproduction is established. The two-machine release report supplies a concrete history-opening scenario, but the triggering history content and terminating stack remain unidentified, and native execution was not performed.

Is this the best way to solve the issue?

Unclear: generic throttling, history deletion, or another rendering rewrite is not yet justified. Identify the terminating operation before choosing a focused fix in the existing history, rendering, or scrolling owner.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The reported WER codes do not identify the failing managed operation or native control; a redacted exception stack or dump-derived stack is needed before selecting a repair.
• The history-triggered hang and high-throughput layout crash reports may overlap, but a shared root cause has not been established.
• The older-build rollback's update suppression behavior has not been verified.

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

Label changes

Label changes:

• add P0: The latest update repeatedly terminates the native app during ordinary chat use on two machines, with rollback as the reported recovery.
• add impact:crash-loop: Reopening the app and selecting history repeatedly reproduces process termination.
• add impact:ux-release-blocker: The report provides no working in-product recovery; recovery requires an older installation and unresolved update suppression.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.

Label justifications:

• P0: The latest update repeatedly terminates the native app during ordinary chat use on two machines, with rollback as the reported recovery.
• impact:crash-loop: Reopening the app and selecting history repeatedly reproduces process termination.
• impact:ux-release-blocker: The report provides no working in-product recovery; recovery requires an older installation and unresolved update suppression.

Evidence reviewed

What I checked:

• Concrete released-build failure: The supplied issue reports repeatable termination on two Windows 11 machines running v2026.9.3, approximately 10–15 seconds after opening history. It includes WER exception signatures, successful gateway connection diagnostics, an unsuccessful last-chat-state deletion attempt, and a working older-version rollback. (84928c4370bc)
• History reaches native rendering: History completion obtains a generation-checked snapshot and queues fenced delivery. The chat root consumes Changed snapshots, requests history for the selected connected session, and composes the native timeline. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:751, bd9ce43b4d9c)
• Native tail-scroll boundary remains present: The timeline uses virtualized ItemsView rows and supplies the displayed tail identity to its scroll controller. After loaded-state and identity checks, the controller invokes native StartBringItemIntoView. This establishes an investigation boundary, not the cause of this crash. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, bd9ce43b4d9c)
• Release and main comparison: Separate git ls-tree checks for HEAD and v2026.9.3 returned the identical Chat directory tree, 8497cefd5c4ebb1770cfe6c56084d9b3f3d7b4b5. The release-to-main name comparison contains packaging and related changes, with no Chat directory changes. GitHub releases/latest confirms v2026.9.3; no inspected evidence establishes a subsequent fix for this crash. (src/OpenClaw.Tray.WinUI/Chat, 84928c4370bc)
• Related discussion narrows investigation without proving duplication: [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167 (comment) reports a v2026.9.3 hang inside native StartBringItemIntoView with a valid last-row index. Earlier discussion includes successful generated long-session testing and a separate dump-derived tail-scroll hang. Those observations help distinguish content/layout conditions from message count alone; none identifies the terminating exception in this issue.
• Existing layout update is already in the affected release: GitHub verifies fix(chat): prevent bubble text truncation #1400 (fix(chat): prevent bubble text truncation) merged as the reported release commit. Its stated purpose is text truncation, and current source references Reactor preview.15. This is relevant release context, not evidence that the update caused or fixed this crash. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:97, 84928c4370bc)

Likely related people:

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

[mnowrot]

Third-machine confirmation + the terminating stack

Adding the artifact the review above asks for (a redacted terminating stack) from a third independently affected machine.

Environment

• Companion: v2026.9.3 (OpenClaw.Tray.WinUI.exe)
• OS: Windows 11
• Gateway: OpenClaw 2026.9.4 (remote wss://, device-token auth, protocol 4)
• Node mode: operator + node, 9 capabilities registered

Crash signature (tray log, %LOCALAPPDATA%\<app>\openclaw-tray.log)

[ERROR] CRASH UnhandledException: System.ArgumentException: The parameter is incorrect.

The parameter is incorrect.

   at WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|38_0(Int32 hr)
   at WinRT.ExceptionHelpers.ThrowExceptionForHR(Int32 hr)
   at ABI.Microsoft.UI.Xaml.IFrameworkElementOverridesMethods.ArrangeOverride(IObjectReference _obj, Size finalSize)
   at Microsoft.UI.Xaml.FrameworkElement.ArrangeOverride(Size finalSize)
   at Microsoft.UI.Xaml.FrameworkElement.Microsoft.UI.Xaml.IFrameworkElementOverrides.ArrangeOverride(Size finalSize)
   at ABI.Microsoft.UI.Xaml.IFrameworkElementOverrides.Do_Abi_ArrangeOverride_1(IntPtr thisPtr, Size finalSize, Size* result)

Interpretation: an unhandled E_INVALIDARG (System.ArgumentException) escaping the WinUI layout pass (ArrangeOverride). That is consistent with the outer signature reported in the issue (0xc000027b in Microsoft.UI.Xaml.dll, WER P7: 80070057 = E_INVALIDARG) — i.e. a layout/measure failure terminating the process, not a transport, auth, or reconnect fault.

Corroboration on this machine

• 33 CRASH UnhandledException entries in the tray log on 2026-09-12, identical message and identical ArrangeOverride stack every time.
• 10 matching AppCrash_OpenClaw.Tray.Wi* reports in the WER ReportArchive, with timestamps matching the log entries.

Caveat worth flagging for triage: on this machine the failure also reproduced during high-volume node node.invoke.request / system.run activity, not only with a chat view (with history) open. So the trigger may be layout/measure work under event throughput (cf. #1270) rather than the chat surface specifically, and #1167 may sit on the same measure path. History-triggered and throughput-triggered cases may share this terminating frame.

Workaround in use here: rollback to v2026.7.1-4 — no such stack was observed before the 2026.9.3 update.

[sniper-chao]

Fourth machine + a new datapoint: a clean portable extraction reproduces it

Environment

• Companion: v2026.9.3 (portable OpenClawTray-2026.9.3-win-x64.zip, sha256 795cc381624ceebaa884582d2ac00a26d7fad506899b67353bce914ed25d1b5a — matches the release asset)
• OS: Windows 11 Pro 26200.9445 (x64)
• Gateway: OpenClaw 2026.9.4, protocol 4, device-token auth over LAN (ws://, no Tailscale)
• Node mode: off

Repro — same as the OP: start the tray → connection.status Connected and gateway.self logged within ~1 s → the chat view renders a session with history → the process dies 1–10 s later, every time. Two attempts, two crashes.

WER (Application log, event 1000)

Faulting application name: OpenClaw.Tray.WinUI.exe, version: 2026.9.3.0, time stamp: 0x6a890000
Faulting module name: Microsoft.UI.Xaml.dll, version: 3.2.3.0, time stamp: 0x013b7243
Exception code: 0xc000027b
Fault offset: 0x00000000003a9c5d
Faulting process id: 0x618

Tray log (%LOCALAPPDATA%\OpenClawTray\openclaw-tray.log) — byte-identical to the stack @mnowrot posted (message is 参数错误。 on a zh-CN system):

[ERROR] CRASH UnhandledException: System.ArgumentException: 参数错误。
   at WinRT.ExceptionHelpers.<ThrowExceptionForHR>g__Throw|38_0(Int32 hr)
   at ABI.Microsoft.UI.Xaml.IFrameworkElementOverridesMethods.ArrangeOverride(IObjectReference _obj, Size finalSize)
   at Microsoft.UI.Xaml.FrameworkElement.ArrangeOverride(Size finalSize)
   at Microsoft.UI.Xaml.FrameworkElement.Microsoft.UI.Xaml.IFrameworkElementOverrides.ArrangeOverride(Size finalSize)

The crash happens right after history is projected: the last log lines are [GatewayClient] Sending frame: chat.history, Wizard response payload kind=Object len=10517, a burst of [ChatHistory] role=... routed: ... lines, then the crash.

New datapoint that rules out a stale-file cause: extracting the release zip into a clean, empty directory — no overlay onto an existing install, so zero leftover assemblies from the previous version — reproduces the crash with the same stack. So this is not an artifact of an in-place update leaving old DLLs behind. (last-chat-state.json was also left untouched on that run.)

Expected vs actual: expected the chat pane to render the session; actual is an unhandled XAML layout exception (HRESULT 0x80070057) that terminates the process.

v2026.7.1 on the same machine/gateway is stable — rollback is the working workaround. Also worth noting for anyone else rolling back: the in-app updater's download of the asset is extremely slow in some networks (single connection, ~30 KB/s here, ~150 MB asset), so grabbing the zip externally is much faster.

[Shaman-lpz]

Additional reproduction with dump-derived ItemsRepeater::MeasureOverride stack

I can confirm this crash on another Windows 11 machine, using Windows Companion 2026.9.3.

Sanitized environment

• Windows Companion: 2026.9.3
• Windows: x64, build 26200.9445
• Microsoft.UI.Xaml.dll: image version 3.2.3.0, file version 3.2.3.2608
• MXC: 0.8.0

Reproduction observed

The process terminated in both of these situations:

1. Start the Companion, connect, open Chat, and submit a normal text prompt.
2. Start the Companion with its Windows node connected, then deliver a harmless remote system.run request such as whoami.

The second trigger is included only as another observed UI-update path. It does not establish MXC as the cause: submitting a normal prompt can reproduce the WinUI crash without node execution.

Windows recorded the same crash signature repeatedly:

Application: OpenClaw.Tray.WinUI.exe 2026.9.3.0
Module: Microsoft.UI.Xaml.dll 3.2.3.0
Exception code: 0xc000027b
Fault offset: 0x00000000003a9c5d

Sanitized WinDbg result

Failure.Bucket:
STOWED_EXCEPTION_80070057_Microsoft.UI.Xaml.Controls.dll!
winrt::hresult_error::hresult_error

Failure.Exception.Code: 0x80070057
Failure.ProblemClass.Primary: STOWED_EXCEPTION
Failure.Exception.IP.Offset: 0x3a9c5d
Failure.Hash: {a034972d-8e65-75bf-b428-8144dbbcd807}

Relevant resolved stack:

Microsoft_UI_Xaml_Controls!winrt::hresult_error::hresult_error
Microsoft_UI_Xaml_Controls!winrt::throw_hresult
Microsoft_UI_Xaml_Controls!ItemsRepeater::MeasureOverride
Microsoft_UI_Xaml_Controls!IFrameworkElementOverrides::MeasureOverride
Microsoft_UI_Xaml!DirectUI::FrameworkElementGenerated::MeasureOverrideProtected
Microsoft_UI_Xaml!DirectUI::FrameworkElement::MeasureOverrideFromCore
Microsoft_UI_Xaml!CFrameworkElement::MeasureCore
Microsoft_UI_Xaml!CUIElement::MeasureInternal
Microsoft_UI_Xaml!CUIElement::Measure
... repeated CUIElement::Measure frames ...
Microsoft_UI_Xaml!CLayoutManager::UpdateLayout
Microsoft_UI_Xaml!CCoreServices::NWDrawTree
Microsoft_UI_Xaml!CXcpDispatcher::Tick
CoreMessagingXP!DispatcherQueueTimer::TimerCallback

The process terminates through:

KERNELBASE!RaiseFailFastException
combase!RoFailFastWithErrorContextInternal2
Microsoft_UI_Xaml!FailFastWithStowedExceptions
Microsoft_UI_Xaml!DirectUI::ErrorHelper::ProcessUnhandledError

Interpretation boundary

Confirmed: an unhandled E_INVALIDARG escapes during WinUI list measurement and terminates the process. The outer signature and offset match the reports already collected here.

Inferred, not proven by this dump alone: this may be the same stale bring-into-view anchor path described in #1167 and addressed by the application-side workaround in PR #1407. The dump does not contain an OpenClaw frame naming the originating view or state update, so I cannot prove that every observed trigger shares that exact root cause.

Two full dumps are retained locally. I will not upload them publicly because they may contain conversation, path, or authentication data, but I can provide additional sanitized debugger output or use a maintainer-approved private channel if requested.

[Shaman-lpz]

Same crash now reproduced while running tray-only, without active UI interaction

One additional data point: after a clean restart, the Companion was left running in the system tray and connected normally. No Companion window was open, no prompt was submitted through it, and no Windows-node command was intentionally invoked. Work continued only through a separate web client connected to the same gateway. The Companion later disappeared from the tray by itself.

Windows recorded another crash with exactly the same signature:

Application: OpenClaw.Tray.WinUI.exe 2026.9.3.0
Module: Microsoft.UI.Xaml.dll 3.2.3.0
Exception code: 0xc000027b
Fault offset: 0x00000000003a9c5d

Two earlier crashes in the same test period also have the identical exception code, module, and fault offset. This shows that the same failure can also surface while the Companion is apparently idle in tray-only mode, rather than only during direct interaction with its visible window.

Confirmed: this is the same outer crash signature as the dump-derived E_INVALIDARG / ItemsRepeater::MeasureOverride failure reported above.

Not yet confirmed: whether gateway/session activity from the separate client, a background status or connection update, or a timer-driven UI refresh triggered the layout pass. The event log proves the recurring crash signature, but not the specific initiating event.

[naamah75]

Additional reproduction on an Italian Windows installation

I can confirm the issue with Windows Companion v2026.9.3 and Gateway v2026.9.4.

Steps to reproduce

1. Start Windows Companion.
2. The application opens and connects to the remote LAN Gateway normally.
3. Open the Chat section.
4. The application immediately crashes and closes.

Observed behavior

• The dashboard and Gateway connection work normally before opening Chat.
• The diagnostic bundle reports the Gateway as connected and healthy.
• crash.log contains repeated unhandled exceptions:

UnhandledException
System.ArgumentException: Parametro non corretto.

The most recent occurrence included in the bundle is:

[2026-09-14 06:40:29.719] UnhandledException
System.ArgumentException: Parametro non corretto.

This appears consistent with the E_INVALIDARG / WinUI layout crash already documented in this issue. It therefore seems to be a Companion Chat rendering problem rather than a Gateway transport or authentication failure.

Environment

• Windows Companion: 2026.9.3
• Gateway: 2026.9.4
• Topology: remote LAN
• Transport: WebSocket over LAN
• Gateway protocol: 4

I have a sanitized Windows Companion diagnostic bundle available and can provide it if useful.