Repository navigation
[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 #1406
Description
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
- Start the Companion; it connects (
gateway.selfevent logged,presenceCountpopulated) and shows Connected. - Open Chat, select a session with history (e.g. the agent's main session).
- 10–15 s later the process crashes. Reopening reproduces it every time. Deleting
last-chat-state.jsondid 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.starteach 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?
Reacted by Marcin Nowrot
Reacted by clawsweeper
Activity
clawsweeper commentedon Sep 12, 2026
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
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:
Codex review notes: model internal, reasoning medium; reviewed against bd9ce43b4d9c.
Label changes
Label changes:
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.issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.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:
src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:751, bd9ce43b4d9c)src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, bd9ce43b4d9c)src/OpenClaw.Tray.WinUI/Chat, 84928c4370bc)src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:97, 84928c4370bc)Likely related people:
How this review workflow works
@clawsweeper re-reviewcomments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.@clawsweeper re-reviewor@clawsweeper re-runon an open PR or issue to request a fresh review only.@clawsweeper reviewto request a fresh review only.@clawsweeper autofix,@clawsweeper automerge,@clawsweeper fix ci, or@clawsweeper address review.@clawsweeper explainto ask for more context, or@clawsweeper stopto stop active automation.mnowrot commentedon Sep 12, 2026
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
OpenClaw.Tray.WinUI.exe)wss://, device-token auth, protocol 4)Crash signature (tray log,
%LOCALAPPDATA%\<app>\openclaw-tray.log)Interpretation: an unhandled
E_INVALIDARG(System.ArgumentException) escaping the WinUI layout pass (ArrangeOverride). That is consistent with the outer signature reported in the issue (0xc000027binMicrosoft.UI.Xaml.dll, WERP7: 80070057=E_INVALIDARG) — i.e. a layout/measure failure terminating the process, not a transport, auth, or reconnect fault.Corroboration on this machine
CRASH UnhandledExceptionentries in the tray log on 2026-09-12, identical message and identicalArrangeOverridestack every time.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.runactivity, 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 commentedon Sep 12, 2026
Fourth machine + a new datapoint: a clean portable extraction reproduces it
Environment
OpenClawTray-2026.9.3-win-x64.zip, sha256795cc381624ceebaa884582d2ac00a26d7fad506899b67353bce914ed25d1b5a— matches the release asset)ws://, no Tailscale)Repro — same as the OP: start the tray →
connection.status Connectedandgateway.selflogged 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)
Tray log (
%LOCALAPPDATA%\OpenClawTray\openclaw-tray.log) — byte-identical to the stack @mnowrot posted (message is参数错误。on a zh-CN system):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.jsonwas 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 commentedon Sep 12, 2026
Additional reproduction with dump-derived
ItemsRepeater::MeasureOverridestackI can confirm this crash on another Windows 11 machine, using Windows Companion
2026.9.3.Sanitized environment
2026.9.326200.9445Microsoft.UI.Xaml.dll: image version3.2.3.0, file version3.2.3.26080.8.0Reproduction observed
The process terminated in both of these situations:
system.runrequest such aswhoami.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:
Sanitized WinDbg result
Relevant resolved stack:
The process terminates through:
Interpretation boundary
Confirmed: an unhandled
E_INVALIDARGescapes 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 commentedon Sep 12, 2026
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:
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::MeasureOverridefailure 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 commentedon Sep 14, 2026
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
Observed behavior
crash.logcontains repeated unhandled exceptions:The most recent occurrence included in the bundle is:
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
2026.9.32026.9.44I have a sanitized Windows Companion diagnostic bundle available and can provide it if useful.
Buda8989 commentedon Sep 15, 2026
Additional confirmation and a working no-data-loss workaround
I reproduced this on Windows x64 with Companion 2026.9.3 and again after a clean uninstall/reinstall to 2026.9.4-alpha.1. In both cases the process exited immediately after
chat.historyreturned, with the sameSystem.ArgumentException/ArrangeOverride/Microsoft.UI.Xaml.dllsignature. Resettinglast-chat-state.jsondid not resolve it.The gateway and chat data were healthy throughout. The successful workaround was to change the existing setting in
%APPDATA%\OpenClawTray\settings.jsonto:After restarting Companion, it stayed running, processed chat events and received a final assistant response with no new crash record. This switches the chat surface to the legacy WebView path and avoids the native WinUI history renderer; no conversation data, gateway configuration, or credentials needed to be deleted.
This is not fixed by the currently available 2026.9.4-alpha.1 build.
Reister777 commentedon Sep 15, 2026
Confirming on a third machine — Windows 11 Pro (build 26100.8875), Companion v2026.9.4 (OpenClaw.Tray.WinUI.exe 2026.9.4.0):
Microsoft.UI.Xaml.dll3.2.3.0, exception0xc000027b, WER P4combase.dll10.0.26100.8875, P780070057(E_INVALIDARG). The faulting offset0x3a9c5dis identical across v2026.9.3, v2026.9.4-alpha.1 and v2026.9.4.last-chat-state.jsononly postpones it until a session with history is opened again.system.runinvokes time out even thoughnodes statusshows the node connected just before. Looks like the history projection blocks the UI thread (consistent with [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167, but the threshold here is tiny).OpenClawGateway), node paired + approved,sessions.visibility=all.WER
.mdmpdumps fromReportArchiveavailable if useful.mnowrot commentedon Sep 15, 2026
I can confirm no more such crashes in 2026.9.4. Probably fixed by: #1426