Repository navigation
OpenClaw Companion (Windows) crashes within 6-90s of startup - WinUI 3 ArrangeOverride throws E_INVALIDARG #1410
Description
Summary
Companion (v2026.9.3, Windows 11 24H2) reliably crashes 6–90 seconds after startup, every launch. The crash happens while the native XAML chat view is rendering the gateway-pushed wizard/startup data. It is an app-side WinUI 3 layout bug, not an environment problem. Setting "UseLegacyWebChat": true in %APPDATA%\OpenClawTray\settings.json (chat falls back to the legacy Web rendering path) fully avoids the crash — verified stable for 180s+ across multiple restarts.
Environment
| Item | Value |
|---|---|
| OS | Windows 11 Home CN 24H2, Build 10.0.26100 (UBR .768) |
| Hardware | Lenovo Legion laptop, NVIDIA RTX 4050 (driver 32.0.15.8088) |
| Display | Single monitor 2560×1600, system scale 150% (AppliedDPI=144) |
| OpenClaw Companion | 2026.9.3.0 (official installer, %LOCALAPPDATA%\OpenClawTray) |
| Gateway / CLI | 2026.9.4 (node26 runtime) |
| WinUI runtime | Bundled Microsoft.UI.Xaml.dll 3.2.3.2608; system WindowsAppRuntime 1.1–2.x registered fine |
| Third-party injection | Nahimic audio (AudioDevProps2.dll), Oray virtual display driver — both ruled out |
Symptoms
- App exits 6–90s after launch, every time; window may flash and disappear.
- Windows Event Log (Application Error): exception code
0xc000027b(STATUS_STOWED_EXCEPTION), faulting moduleMicrosoft.UI.Xaml.dll. - App
crash.log:System.ArgumentException: 参数错误。with the stack pinned toIFrameworkElementOverrides.ArrangeOverride(see below). - App log shows the crash happens ~137ms after the gateway handshake completes and the
chat.historywizard response (~84KB,kind=Object) arrives — i.e., exactly while the main chat view is rendering. - Unrelated to gateway connectivity: crashing also occurs with the gateway unreachable (
ws://127.0.0.1:19999dead).
Crash stack (crash.log)
System.ArgumentException: 参数错误。
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)
App log (137ms before crash):
[13:49:05.126] [GatewayClient] Sending frame: chat.history
[13:49:05.144] Wizard response payload kind=Object len=84585
[13:49:05.283] [ERROR] CRASH UnhandledException: System.ArgumentException: 参数错误。
Root cause analysis
The crash originates in the native layout implementation of Microsoft.UI.Xaml.dll: the managed layer calls IFrameworkElementOverrides.ArrangeOverride, and the native side returns E_INVALIDARG (0x80070057). In WinUI 3 this is typical when a chat message / wizard payload with a specific structure (nested cards, Markdown, tool-call blocks) produces an invalid size during measure/arrange.
Evidence chain:
- Crash timing strictly matches the wizard response rendering (137ms window).
- With the gateway disconnected the app still crashes — the main chat view requests and renders that data regardless, so disconnecting cannot bypass it.
"UseLegacyWebChat": trueswitches the chat to the WebView path, which never touches the native XAML chat controls — crashes stop. This inversely confirms the native chat view layout path as the culprit.- Scale 150%, third-party injections, and system component state were all ruled out one by one (Oray disabled, Nahimic stopped,
sfc /scannowclean, DPI compat flags, reinstall,NodeCanvasEnabled/NodeScreenEnabled=false).
Workaround (verified)
Edit %APPDATA%\OpenClawTray\settings.json:
{
"UseLegacyWebChat": true,
"AppTheme": "Light"
}Result: 0 crashes across multiple restarts, 180s+ continuous uptime, all features (chat/settings/notifications/hotkeys) functional. AppTheme: Dark also crashes in the same environment, so the theme change alone is not sufficient — the key switch is UseLegacyWebChat.
Reproduction steps
- Windows 11 24H2 + Companion 2026.9.3 + Gateway 2026.9.4 (node26).
- Complete pairing, then start Companion and wait for the main chat view to load the wizard startup data. Reproduces consistently at 150% display scale (appears deterministic).
Suggested fix direction
- Review the rendering path of
sessions.messages/chat.historywizard payloads (kind=Object, ~84KB) in the native chat message-list control; focus on layout measurement of wizard card structures (nested cards / Markdown / tool-call blocks). - Regression-check the Dark theme path (
AppTheme=Dark), which crashes in the same environment. - Consider auto-falling back to
UseLegacyWebChatfor affected users, or routing wizard startup data to a Web-chat-only channel.
Additional material
A full 7-page troubleshooting report (Chinese) with all logs, timeline and verification data is available on request — happy to share it here if maintainers want the complete evidence.
Activity
taardissss commentedon Sep 13, 2026
Attaching the full 7-page troubleshooting report (Chinese) as PDF evidence: crash.log stack traces, Windows Event Log details, WER info, the 137ms wizard-rendering sequence, the full exclusion matrix (Oray driver, Nahimic, DPI compat, reinstall, sfc, node canvas), and the verified workaround + before/after comparison.
PDF: https://gist.githubusercontent.com/taardissss/1312e615ae1b592eb2121e105eef0dd1/raw/6be364c78905f75d3db749b0fbfc60c6f97be504/openclaw-companion-crash-report.pdf
Happy to provide the raw logs or any additional data if needed.
clawsweeper commentedon Sep 13, 2026
Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 13, 2026, 2:23 AM ET / 06:23 UTC.
Summary
Keep open: this is a concrete crash in the latest release, with corroborating layout failures and no verified fix on main. An existing workaround PR is relevant, but its coverage of this startup failure remains unproven.
Reproducibility: no. high-confidence current-main reproduction is established. The released-build startup scenario and corroborating stacks are concrete, but the triggering native row/state transition has not been isolated or executed here.
Regression provenance
Possible regression — suspected (failure trace). No predecessor PR is attributed.
Ways to help us reproduce this
Next step
Route native investigation through the existing crash thread and evaluate #1407 (fix(chat): work around WinUI session-switch crash) against this startup case before commissioning another repair.
Review details
Best possible solution:
Repair the identified native layout failure while preserving history, and expose the existing web-chat preference through a safe-start recovery button accessible before chat mounts.
Do we have a high-confidence way to reproduce the issue?
No high-confidence current-main reproduction is established. The released-build startup scenario and corroborating stacks are concrete, but the triggering native row/state transition has not been isolated or executed here.
Is this the best way to solve the issue?
Unclear: the existing retained-anchor workaround is the strongest focused candidate to evaluate first. Payload filtering, theme changes, or wizard-specific routing are not supported by the inspected source.
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 official release repeatedly terminates shortly after launch, blocking ordinary use.impact:crash-loop: The reporter describes process termination on every launch with a consistent native layout exception.impact:ux-release-blocker: The demonstrated recovery requires manually editing settings outside the app; accessible in-product recovery before termination is not established.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 official release repeatedly terminates shortly after launch, blocking ordinary use.impact:crash-loop: The reporter describes process termination on every launch with a consistent native layout exception.impact:ux-release-blocker: The demonstrated recovery requires manually editing settings outside the app; accessible in-product recovery before termination is not established.Evidence reviewed
What I checked:
src/OpenClaw.Tray.WinUI/Chat, bd9ce43b4d9c)src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, bd9ce43b4d9c)src/OpenClaw.Shared/OpenClawGatewayClient.cs:477, bd9ce43b4d9c)src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:203, bd9ce43b4d9c)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 15, 2026
I can confirm no more crashes in 2026.9.4. Probably fixed by #1426
taardissss commentedon Sep 16, 2026
Thanks @mnowrot for confirming the fix in v2026.9.4 — glad the startup crash is resolved. I've also re-tested on Windows 11 24H2 at 150% scaling with repeated launches and no longer hit the crash-loop / layout exception.
Appreciate PR #1426 and everyone involved. I'll close this issue once it stays stable for a few more days.
Thanks again!