OpenClaw Companion (Windows) crashes within 6-90s of startup - WinUI 3 ArrangeOverride throws E_INVALIDARG

[taardissss]

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 module Microsoft.UI.Xaml.dll.
• App crash.log: System.ArgumentException: 参数错误。 with the stack pinned to IFrameworkElementOverrides.ArrangeOverride (see below).
• App log shows the crash happens ~137ms after the gateway handshake completes and the chat.history wizard 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:19999 dead).

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:

1. Crash timing strictly matches the wizard response rendering (137ms window).
2. With the gateway disconnected the app still crashes — the main chat view requests and renders that data regardless, so disconnecting cannot bypass it.
3. "UseLegacyWebChat": true switches 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.
4. Scale 150%, third-party injections, and system component state were all ruled out one by one (Oray disabled, Nahimic stopped, sfc /scannow clean, 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

1. Windows 11 24H2 + Companion 2026.9.3 + Gateway 2026.9.4 (node26).
2. 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.history wizard 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 UseLegacyWebChat for 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.

[taardissss]

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]

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

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

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:

• The managed stack does not identify the originating control or prove that this startup failure uses the retained-anchor path.
• The existing workaround's reported ARM64 session-navigation result does not establish recovery on the reported x64 startup scenario.

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

Label changes

Label changes:

• add P0: The latest official release repeatedly terminates shortly after launch, blocking ordinary use.
• add impact:crash-loop: The reporter describes process termination on every launch with a consistent native layout exception.
• add impact:ux-release-blocker: The demonstrated recovery requires manually editing settings outside the app; accessible in-product recovery before termination is not established.
• 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 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:

• Concrete released-build crash and workaround: The supplied report identifies official Companion v2026.9.3, Windows 11 24H2 at 150% scaling, repeated startup termination, and an ArrangeOverride E_INVALIDARG stack. It reports multiple stable restarts after enabling the existing legacy web-chat setting.
• Latest release and main retain identical chat source: GitHub releases/latest identifies v2026.9.3. Separate tree inspections returned the same Chat directory tree, 8497cefd5c4ebb1770cfe6c56084d9b3f3d7b4b5, for that release and HEAD. No subsequent chat implementation fix is established. (src/OpenClaw.Tray.WinUI/Chat, bd9ce43b4d9c)
• Native scrolling boundary remains present: The timeline builds keyed ItemsView rows with StackLayout. After loaded-state and tail-identity checks, its scrolling owner still calls StartBringItemIntoView. This is a concrete investigation boundary, not proof of this report's exact cause. (src/OpenClaw.Tray.WinUI/Chat/ReactorItemsViewScrollController.cs:269, bd9ce43b4d9c)
• Wizard log wording does not identify wizard cards: Ordinary chat.history requests use SendWizardRequestAsync; its response handler logs payload shape under the Wizard category. The reported log therefore establishes response timing, not a distinct wizard-card rendering path. (src/OpenClaw.Shared/OpenClawGatewayClient.cs:477, bd9ce43b4d9c)
• Existing alternate renderer: ChatPage selects WebView or Reactor from UseLegacyWebChat; ChatWindow likewise disposes the native host when selecting web chat. Settings already exposes this preference, although the reported startup crash required editing settings externally. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:203, bd9ce43b4d9c)
• Independent matching failure reports: Discussion at [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 includes matching ArrangeOverride stacks, clean portable-install reproduction, and a sanitized ItemsRepeater::MeasureOverride dump analysis. Reports also describe background termination, so chat history size alone is not an established trigger.

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)

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]

I can confirm no more crashes in 2026.9.4. Probably fixed by #1426

[taardissss]

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!