Repository navigation
Windows Companion (WinUI) crashes with System.ArgumentException: The parameter is incorrect when opening a chat session #1419
Description
Activity
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 reported stable-release crash has no verified fix on current main. An assigned, draft mitigation already owns the work, but its full crash-recovery proof remains incomplete.Reproducibility: no. high-confidence current-main reproduction is established. The reporter provides repeatable v2026.9.3 steps and crash signatures, but this read-only review did not execute Windows or the affected history.
Regression provenance
Possible regression — suspected (failure trace). No predecessor PR is attributed.Ways to help us reproduce this
- Add expected vs actual behavior.
- Include redacted logs or terminal output.
Next step
Concentrate validation and repair in #1426 (fix(chat): avoid session-switch crashes without clipping Markdown lists); keep this issue open until that candidate or another verified fix lands.Review details
Best possible solution:
Restore stable native history rendering while preserving final-message visibility and scroll position, with a visible in-app recovery route if native chat remains unavailable.
Do we have a high-confidence way to reproduce the issue?
No high-confidence current-main reproduction is established. The reporter provides repeatable v2026.9.3 steps and crash signatures, but this read-only review did not execute Windows or the affected history.
Is this the best way to solve the issue?
Unclear: the dependency rollback is a concrete existing candidate, but it needs native session-switching proof; the alternative extent-based scrolling workaround reportedly stopped before the final message.
AGENTS.md: found and applied where relevant.
Remaining risk / open question:
- The exact native failure in this reporter's history has not been reproduced on current main.
- The draft mitigation demonstrates Markdown wrapping but still lacks full session-switching and final-message visibility evidence.
Codex review notes: model internal, reasoning medium; reviewed against ddb54a9614a5.
Label changes
Label justifications:
P0: The current stable Companion repeatedly terminates when the reporter opens chat, blocking reading and sending with no reported in-app recovery.impact:crash-loop: Opening affected history consistently terminates the native Companion process.impact:ux-release-blocker: The installed app cannot complete the reported chat workflow, and its updater offers no recovery release.
Evidence reviewed
What I checked:
- Concrete affected release: The report identifies official v2026.9.3 on Windows 11, repeatable termination after chat.history, and WinUI argument exceptions while other Gateway clients remain healthy. The supplied discussion contains no subsequent reporter confirmation of recovery.
- Current main retains the implicated scrolling path: At the fetched main revision, StartTailRequest validates the current tail and then invokes ItemsView.StartBringItemIntoView. The alternate ScrollTo mitigation is not present. (
src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, ddb54a9614a5) - Dependency rollback has not landed: Both Microsoft.UI.Reactor packages remain at preview.15; the candidate mitigation proposes preview.12. These direct package references establish the Reactor dependency boundary, but do not independently prove the reported upstream lifetime defect. (
src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:97, ddb54a9614a5) - Existing scrolling contract: Current tests require stable tail identity, discrete row-targeted navigation, bottom-follow guards, and disposal handling. These source-contract assertions are not native crash-recovery proof. (
tests/OpenClaw.Tray.Tests/ChatTimelinePresentationTests.cs:56, ddb54a9614a5) - Open mitigation candidate: fix(chat): avoid session-switch crashes without clipping Markdown lists #1426 (fix(chat): avoid session-switch crashes without clipping Markdown lists) is verified open, draft, and unmerged at 3cda150. Its supplied body explicitly leaves repeated session switching, real Gateway history loading, final-message visibility, and streaming behavior unverified. (3cda150580b1)
- Inspected candidate screenshot: The prepared proof-image-1.png visibly shows a narrow unordered list wrapping through its final words. This supports the candidate's Markdown-layout claim, not recovery from the session-history crash. Source attachment: https://github.com/user-attachments/assets/246b6a2e-b33f-4fd2-82d5-1f12bbebc969.
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)
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-reviewcomments, 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-reviewor@clawsweeper re-runon an open PR or issue to request a fresh review only. - Maintainers can also comment
@clawsweeper reviewto 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 explainto ask for more context, or@clawsweeper stopto stop active automation.
- marked Windows Tray app crash-loops with Microsoft.UI.Xaml.LayoutCycleException under rapid event throughput #1270 as a duplicate of this issue
on Sep 23, 2026 - unmarked Windows Tray app crash-loops with Microsoft.UI.Xaml.LayoutCycleException under rapid event throughput #1270 as a duplicate of this issue
on Sep 23, 2026 - locked as resolved and limited conversation to collaborators
on Sep 26, 2026
Metadata
Metadata
Labels
Type
Fields
Priority
Projects
- Status
Describe the bug
The Windows Companion app (OpenClaw.Tray.WinUI) crashes consistently when opening/viewing a chat session. It connects and authenticates with the Gateway successfully, then crashes ~1 second after loading the session's message history or receiving live agent events. No data loss — the Gateway, Telegram channel, and browser Control UI all keep working.
To Reproduce
Expected behavior
Chat view renders and stays open; can read and send messages.
Actual behavior
Unhandled System.ArgumentException: The parameter is incorrect. in the WinUI layer; app terminates. Repeatable on every open of the chat view. Crash log shows it immediately after the Gateway returns the full session payload (e.g. Wizard response payload ... len=~276321-339587), i.e. during chat-history rendering.
Crash evidence
• crash.log: System.ArgumentException: The parameter is incorrect. (multiple entries, e.g. 20:00:44, 20:05:00, 20:21:11)
• openclaw-tray.log sequence: handshake complete → chat.history sent → large Wizard response payload → CRASH
• Event Log (Application) also shows WinUI faulting module Microsoft.UI.Xaml.dll and coreclr.dll; exceptions 0xc000027b (stowed/HREXAML) and 0xc0000005 (access violation)
Check first
• Gateway is healthy: other clients (browser Control UI, Telegram) work fine
• Not auth/pairing related — handshake completes and operator scopes granted before crash
• App version 2026.9.3.0; no updates available in-app; v2026.9.4-alpha.1 published but notes mention only MSIX/Store packaging
Happy to attach crash.log and openclaw-tray.log on request.