[Bug] Windows Companion 2026.9.3 crashes in WinUI ArrangeOverride after chat.history

[voyager787]

This report is redacted to exclude tokens, credentials, private messages, project contents, and protected project paths.

This report is redacted to exclude tokens, credentials, private messages,
project contents, and protected project paths.

Summary

OpenClaw Windows Companion 2026.9.3.0 crashes in the native WinUI Chat
surface after receiving chat.history. The Gateway and Ollama remain healthy,
and no provider/model request or chat.send occurs before the crash.

The failure reproduces after both selected-thread correction and a clean
Companion Chat/UI-state rebuild, so it is not tied solely to one historical
session.

Environment

• Application: OpenClaw.Tray.WinUI.exe.
• Companion version: 2026.9.3.0.
• Product version: 2026.9.3+84928c4370bc52d7f19127c65a637c7a28aab46e.
• Windows build: 10.0.26200.9445.
• Architecture: x64.
• Faulting runtime module: Microsoft.UI.Xaml.dll 3.2.3.0.
• Installed package dependency metadata includes Windows App SDK / WinUI and
  Microsoft UI Reactor components.

Reproduction

1. Launch Windows Companion.
2. Connect to the existing Gateway.
3. Open the Chat surface with the validated Crestodian session selected.
4. Allow the session history to load.
5. The UI exits during history rendering. A user-visible attempt to type/send a
   normal message exposes the same failure, but the recorded crash occurs before
   chat.send is submitted.

The same crash was reproduced after:

• redirecting the selected dashboard thread to the validated Crestodian
  session; and
• rebuilding Companion-owned Chat/UI state.

The protected Gateway sessions were not modified.

Crash evidence

Latest WER-enabled reproduction:

• Timestamp: approximately 2026-09-14 17:19:34.440 local time.
• Application Error event: 1000.
• Exception: System.ArgumentException: The parameter is incorrect.
• Exception code: 0xc000027b.
• Faulting module: Microsoft.UI.Xaml.dll 3.2.3.0.
• Fault offset: 0x00000000003a9c5d.
• Stack boundary: Microsoft.UI.Xaml.FrameworkElement.ArrangeOverride.

Associated WER APPCRASH record:

• WER fault module: combase.dll.
• WER parameter: 80070057.
• WER fault offset: 0x00000000000579e4.

Earlier repeated timestamps were approximately:

• 2026-09-13 22:28:25.120;
• 2026-09-13 23:45:29.503;
• 2026-09-14 00:17:17.385;
• 2026-09-14 00:17:49.307;
• 2026-09-14 00:19:00.884.

Lifecycle correlation

Observed order:

1. Companion connects/reconnects.
2. Companion requests or receives chat.history.
3. History response is received.
4. Chat rendering enters WinUI layout.
5. FrameworkElement.ArrangeOverride raises the unhandled argument exception.
6. Companion exits.

Not observed before the crash:

• chat.send;
• agent invocation;
• provider request;
• Ollama request;
• model generation;
• Gateway process failure.

Gateway health remained ok=true with a healthy event loop. Ollama remained
running and received no request in the crash window.

Session/state checks

The validated user-facing session was selected:

agent:crestodian-coder:companion-crestodian

Its intended runtime is:

• agent: crestodian-coder;
• provider: ollama;
• model: qwen3:14b-12k;
• context: 12288;
• thinking: off.

The protected validation session
agent:crestodian-coder:ollama-clean was not modified.

The selected dashboard thread had previously contained stale thinking metadata,
but redirecting away from it did not fix the layout crash. A clean Companion
Chat/UI state rebuild also reproduced the crash. This points to a general Chat
history/rendering path rather than one malformed selected session alone.

State-reset results

• Selected-thread redirection: crash remained.
• Companion-owned Chat/UI state rebuild: crash remained.
• Gateway session deletion or modification: not performed.
• Package update/reinstall: not performed.

Dump capture

One temporary per-application WER LocalDumps registration was used with a
dedicated dump folder and full-dump mode. The single reproduction generated no
.dmp file. No usable archived WER dump was available, and no debugger or
ProcDump installation was available in the diagnostic environment.

The current report therefore gives the framework boundary but not the exact
Chat control or invalid layout value below ArrangeOverride.

Expected behavior

Chat history should render without terminating the Companion process. The
operator should be able to type and send a normal message, and the Companion
should remain connected while the Gateway handles the request.

Actual behavior

The Companion process terminates with an unhandled WinUI argument exception
during Chat/history rendering. The Gateway and Ollama continue running.

Related upstream evidence

• [Bug] OpenClaw.Tray.WinUI v2026.7.1 UI hang/crash (AppHang + APPCRASH combase.dll) under heavy agent event streaming #1150 discusses Windows Companion UI failure under event-stream pressure.
• [Bug] Switching sessions can hang WinUI while projecting ~200 history messages (v2026.7.1) #1167 discusses Chat history projection/re-render instability after session switching.
• PR fix(chat): make snapshot coalescing race-free #1301 describes a similar Reactor visual-tree/layout crash pattern (closed).
• PR fix(chat): make snapshot delivery race-free #1386 addresses snapshot-delivery races (merged), but the installed build still reproduces this crash and no exact fix attribution is claimed.

Requested maintainer investigation

Please inspect the native Chat history hydration and Reactor visual-tree update
path for a layout update that reaches WinUI with an invalid argument or with
multiple competing snapshot/layout mutations. A symbolized stack below
FrameworkElement.ArrangeOverride would identify the responsible control.

Security/privacy notes

This report intentionally excludes tokens, credentials, private message text,
project contents, and protected project paths. The validated Local AI
infrastructure, Gateway, Ollama, model configuration, approvals, and security
policy were not changed during diagnosis.

[clawsweeper]

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

Summary
Keep open: the released-build crash remains actionable, and the linked mitigation is still an unmerged draft with crash-recovery validation outstanding. Current main does not contain that mitigation.

Reproducibility: no. high-confidence current-main reproduction is established. The released-build steps and crash evidence are concrete, but this read-only review did not execute WinUI or identify the reporter's exact native failing control.

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

Ways to help us reproduce this

• Add expected vs actual behavior.

Next step
Continue validation through #1426 (fix(chat): avoid session-switch crashes without clipping Markdown lists); the existing implementation candidate and no-new-fix-pr signal rule out a competing automated repair.

Review details

Best possible solution:

Restore crash-free native history loading while preserving final-message visibility, Markdown wrapping, and reader position; provide visible in-app recovery if mitigation cannot ship promptly.

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

No high-confidence current-main reproduction is established. The released-build steps and crash evidence are concrete, but this read-only review did not execute WinUI or identify the reporter's exact native failing control.

Is this the best way to solve the issue?

Unclear: the existing dependency mitigation is a focused candidate, but its own evidence leaves the crash and full-history navigation unresolved; the alternative extent-based workaround reportedly stops short of the final message.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The reporter's framework-level stack does not yet identify the exact native invalid-anchor transition.
• The candidate mitigation has not demonstrated recovery through the complete affected history-loading and scrolling path.

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

Label changes

Label justifications:

• P0: Opening existing chat history repeatedly terminates the released Companion and blocks normal chat use.
• impact:crash-loop: Repeated launches or chat opens produce an unhandled native layout exception and process exit.
• impact:ux-release-blocker: The affected user cannot reach usable chat, and no working in-product recovery is established.

Evidence reviewed

What I checked:

• Concrete released-build failure: The report identifies version 2026.9.3.0, repeated WER crashes, and an ArrangeOverride argument exception after chat.history but before chat.send. The reporter confirms that selecting a clean session and rebuilding Companion-owned UI state did not resolve it. (84928c4370bc)
• Current production rendering boundary: The root subscribes to provider snapshots and requests history for the selected connected thread; ReactorChatTimeline constructs keyed ItemsView rows and binds tail navigation. The architecture ledger assigns virtualization and scrolling to this Reactor path. (src/OpenClaw.Tray.WinUI/Chat/OpenClawReactorChatRoot.cs:86, ddb54a9614a5)
• Native navigation remains on main: StartTailRequest validates the current tail identity and bounds, then calls StartBringItemIntoView. Existing source-contract tests explicitly preserve this navigation API; neither proposed mitigation is established as landed. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, ddb54a9614a5)
• Dependency signal and current versions: The application directly references Microsoft.UI.Reactor and Microsoft.UI.Reactor.Advanced preview.15. The proposed preview.12 mitigation therefore concerns an actual production dependency, not a similarly named implementation. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:97, ddb54a9614a5)
• Upstream native crash mechanism: ItemsView crashes with E_INVALIDARG when a pending bring-into-view target is collapsed microsoft/microsoft-ui-xaml#11865 documents a pending bring-into-view target becoming invalid and causing E_INVALIDARG. Its native and Reactor reproductions strengthen this investigation lead, but do not establish the exact native frames for this reporter's x64 crash.
• Existing mitigation owns implementation work: fix(chat): avoid session-switch crashes without clipping Markdown lists #1426 (fix(chat): avoid session-switch crashes without clipping Markdown lists) remains open, draft, and unmerged at 3cda150. Its captured body explicitly references this report and leaves repeated live-app switching, actual final-message visibility, Gateway history loading, and streaming behavior unverified. (3cda150580b1)

Likely related people:

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

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.

[voyager787]

Expected vs actual

Expected:
Opening the Windows Companion Chat and loading an existing conversation should render the conversation history and leave the Chat UI usable for reading and sending messages.

Actual:
After chat.history completes successfully, the Windows Companion process terminates during native WinUI layout/rendering. The crash occurs before chat.send, provider execution, model invocation, or any Ollama request. The OpenClaw Gateway and Ollama remain healthy.

The issue reproduces after both:

• selecting the clean Crestodian session, and
• rebuilding the Companion-owned Chat/UI state.