Crash at startup on Windows 11 #1707

Activity

1. github-project-automation

   added this to Windows Companion Appon Oct 12, 2026
2. clawsweeper

   added

   P0Emergency: data loss, security bypass, crash loop, or unusable core runtime.Emergency: data loss, security bypass, crash loop, or unusable core runtime.

   clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.

   clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.

   impact:crash-loopThis issue is about crashes, hangs, restart loops, or process-level availability.This issue is about crashes, hangs, restart loops, or process-level availability.

   impact:ux-release-blockerA non-technical user is blocked without terminal, logs, config, or support.A non-technical user is blocked without terminal, logs, config, or support.

   issue-rating: 🦪 silver shellfishThin issue quality; more reproduction proof or environment detail is needed.Thin issue quality; more reproduction proof or environment detail is needed.

   on Oct 12, 2026
3. clawsweeper commented on Oct 12, 2026

   

   clawsweeperBot

   on Oct 12, 2026 – with ClawSweeper

   Last edited by clawsweeper

   More actions

   Codex review: this still needs some work.

   Summary
   Keep open: this issue identifies an official-release startup failure, and no inspected fix demonstrably resolves its specific XAML exception.

   Reproducibility: no. high-confidence current-main reproduction is established: the report identifies an official build and fault signature but omits the exception stack and triggering startup state; this review ran no application, builds, or tests.

   Next step
   Provide guided collection of the redacted exception stack, exact installer asset, and startup state, with a visible recovery launcher, before selecting a focused repair.

   Review details

   Best possible solution:

   Repair the diagnosed startup failure and provide a visible Doctor or safe-start recovery launcher accessible before the failing UI initializes.

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

   No high-confidence current-main reproduction is established: the report identifies an official build and fault signature but omits the exception stack and triggering startup state; this review ran no application, builds, or tests.

   Is this the best way to solve the issue?

   A targeted repair requires identifying the failing startup path first; changing Reactor versions, resetting user state, or suppressing exceptions from the fault code alone would be speculative.

   AGENTS.md: found and applied where relevant.

   Remaining risk / open question:

   • The exception stack, exact installer asset and architecture, and last visible startup state are missing.
   • No current-main reproduction or reporter-confirmed recovery establishes the responsible component.

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

   Label changes

   Label changes:

   No label changes.

   Label justifications:

   • P0: The reported official-installer startup termination blocks ordinary application use without an established in-product recovery path.
   • impact:crash-loop: The reported failure terminates Companion during startup.
   • impact:ux-release-blocker: The user cannot reach application setup or diagnostics, leaving recovery dependent on external logs or support.

   Evidence reviewed

   What I checked:

   • Official-release failure remains unresolved in discussion: The complete report specifies Windows 11 24H2, official installer application version 2026.9.8.0, exception 0xc000027b, and Microsoft.UI.Xaml.dll 3.2.3.0. All three comments are automated; none supplies a stack, successful retest, or fixing PR.
   • Current default branch verified: GitHub identifies main as the default branch, its SHA matches the checkout, and the final working-tree status is clean. (ed1444b0de69)
   • Startup diagnostic boundary: InitializeComponent and run-marker operations precede exception-handler registration, so absence of a crash log would not exclude an earlier initialization failure. (src/OpenClaw.Tray.WinUI/App.xaml.cs:312, ed1444b0de69)
   • Earlier chat mitigation predates the affected release: Both Reactor packages remain pinned to preview.12 by merged fix(chat): avoid session-switch crashes without clipping Markdown lists #1426 (fix(chat): avoid session-switch crashes without clipping Markdown lists). Containing tags include v2026.9.4, v2026.9.8, and v2026.9.8-1; GitHub releases/latest identifies v2026.9.8-1. In OpenClaw Companion (Windows) crashes within 6-90s of startup - WinUI 3 ArrangeOverride throws E_INVALIDARG #1410, mnowrot and taardissss confirmed the older ArrangeOverride crash stopped in v2026.9.4, which does not establish resolution of this later report. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:106, 3dda3cf87fb9)
   • Canonical search does not establish a shared cause: Exact exception, startup-crash, and item-reference searches found nearby reports but no verified fixing item. OpenClaw Companion crashes on startup with .NET Runtime error 0x80131506 #1706 reports a CoreCLR failure, while [Bug] Windows Hub tray (OpenClaw.Tray.WinUI.exe) crashes repeatedly with access violation in Microsoft.UI.Reactor.Core during UI mount #1173 includes rich-text mounting stacks and [Bug] Windows Companion 2026.9.3 crashes in WinUI ArrangeOverride after chat.history #1421 identifies chat-history ArrangeOverride failures. This issue lacks the stack needed to equate those causes.
   • Current tests cover different startup cases: StartupWindowUiTests covers configured and unconfigured launches, reactivation, post-setup restart, and unreadable identity recovery; it does not establish a reproduction or repair of the reported native XAML exception. No builds or tests were run in this read-only review. (tests/OpenClaw.Tray.UITests/StartupWindowUiTests.cs:14, ed1444b0de69)

   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; those execution lanes are retired.
   • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

   Reviewed October 27, 2026, 10:05 AM ET / 14:05 UTC.
4. github-actions commented on Oct 27, 2026

   

   github-actionsBot

   on Oct 27, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue has been automatically marked as stale due to inactivity.
   Please add updated OpenClaw Windows details or it will be closed.
5. github-actions

   added

   stale

   on Oct 27, 2026
6. clawsweeper

   added

   clawsweeper:intake:bugPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   clawsweeper:intake:needs-reproPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   and removed

   clawsweeper:intake:bugPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   clawsweeper:intake:needs-reproPreliminary submission classification; full source review pending.Preliminary submission classification; full source review pending.

   on Oct 27, 2026
7. yehorsolodkyi-glitch commented on Oct 27, 2026

   

   yehorsolodkyi-glitch

   on Oct 27, 2026

   Author

   More actions

   last update fix that problem
8. yehorsolodkyi-glitch

   closed this as completedon Oct 27, 2026
9. github-actions

   locked as resolved and limited conversation to collaborators on Oct 30, 2026