Desktop app: main-window WebView2 renderer self-aborts with STATUS_BREAKPOINT (0x80000003); window goes blank until manually refreshed

[bghgary]

[Filed by Copilot on behalf of @bghgary]

The Copilot desktop app's main-window WebView2 renderer terminates itself with STATUS_BREAKPOINT (0x80000003). The window goes blank and stays blank until manually refreshed, losing any open canvas panel. Six occurrences on one machine between 2026-08-13 09:06 and 2026-08-14 09:52 PDT.

Evidence

0x80000003 is Chromium's signature for a deliberate self-abort (CHECK / IMMEDIATE_CRASH), not a bug-crash. Confirmed by three independent instruments on the same event: an open Process handle's ExitCode, Crashpad's SubCode crash key, and the minidump's own EXCEPTION_RECORD. A deliberate teardown (app restart) reads 0x00000000 on the same instrument, so it discriminates.

Crash keys from the four preserved dumps:

death (PDT)	ModuleVersion	ModuleOffset	SubCode	app
08-13 12:17	151.0.4129.78	82219836	0x80000003	1.1.8
08-13 13:37	151.0.4129.78	82219836	0x80000003	1.1.8
08-14 08:42	151.0.4129.86	82310033	0x80000003	1.1.9
08-14 09:52	151.0.4129.86	82310033	0x80000003	1.1.9

ApplicationName=msedgewebview2.exe; ProcessType=renderer; StackHash=0
ModuleName=msedge.dll
ModuleOffset=82219836   (= msedge.dll+0x4E6933C on 151.0.4129.78)
ModuleOffset=82310033   (= msedge.dll+0x4E7F391 on 151.0.4129.86)

Offsets are not comparable across the two builds, so the difference between 82219836 and 82310033 says nothing about whether it is the same check. What is meaningful is that each build repeats its own offset exactly: two deaths on .78 at one address, two on .86 at another. So on both builds this is one specific check site rather than a generic abort, and the failure survives both an app update and a WebView2 runtime update. (ibucket agrees within each pair — 1327260017987156606 and 1545587364805024286 — but it is derived from app/module/version/offset, so it restates the same fact rather than corroborating it independently.)

Not time- or load-driven: renderer lifetime at death ranged 6.8 to 164 minutes (6.8, 8.7, 30.2, 70.3, 97.0, 164.0). The 6.8-minute one died 6.8 minutes after app launch. Not memory: footprint at death was 266–534 MB across the six, while a healthy renderer peaked at 1435 MB and did not die; ~33 GB of 63.6 GB was free at the deaths where it was sampled.

Why we cannot name the check, and what would

WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--enable-logging --v=1 --log-file=... was armed across five of the six deaths. The log contains zero FATAL / Check failed / NOTREACHED lines across 41.3 MB, and no minidump carries that text in any encoding.

This is not an inactive log channel. At the 08-14 09:52 death the dying renderer had written 222 lines through that channel (1 INFO, 221 VERBOSE1), the last of them 47.7 s before it aborted, and wrote nothing at the abort — while 58 lines from other processes landed in the same minute. The channel was open, the dying process was actively using it, and it emitted nothing when it self-aborted.

That is consistent with a message-less CHECK compiled to a bare base::ImmediateCrash(), whose identity is the faulting address rather than a string. Check failed: does appear 54 times in the shipped msedge.dll, so message-bearing checks exist in this build and the flag is not inert.

Public symbols cannot resolve it either: msdl serves this build's PDB and it matches (PdbUnmatched=0), but it is publics-only (GlobalSymbols=0, Publics=1), so SymFromAddr snaps to the nearest export and returns a name 54 MB away. Naming the site needs private symbols for that exact msedge.dll build, which is why this needs someone inside.

Minidumps for all four captured deaths are retained and can be provided on request.

Two app-side defects that stand regardless of the root cause

1. No detection and no recovery. The app logs nothing at the failure — zero matches for ProcessFailed|RenderProcessGone|renderer.*(crash|gone|exit) across a full app log — and never reloads. WebView2's own Breadcrumbs records Tab1 RenderProcessGone and the following #reload only once a human notices. Observed recovery: 5 s, 2m18s, 6m20s, 18m40s.

2. A session can be created without ever receiving its permission grants, and is then degraded for its entire life. Measured across 132 sessions over 23.5 hours: the sessions that receive zero session.permissions_changed events are exactly the sessions that raise permission prompts — 5 of 5, against 127 of 127 that never prompt — and each of those 5 burns the full 600.0 s permission timeout per prompt, more than once in some cases. In healthy sessions grants arrive at a median of 0.02 s after session start (range 0.02–1.91 s), so this is not slow delivery; it is delivery that never happens, and it is never retried. A session that missed its grants stayed degraded 14 minutes past the reload that restored the window.

A renderer death is one cause of this and not the only one: 4 of 8 sessions created while no renderer existed were completely healthy, and one blinded session had no renderer death anywhere near it — it was created 1.3 s after the machine resumed from a 12.5-hour sleep. So the fix wants to be retry or repair of grant delivery for an already-created session, rather than anything keyed specifically on renderer death. Capping the permission timeout for a session that has never received any grants would separately bound the damage.

Environment

• Copilot desktop app github.exe 1.1.8 and 1.1.9; Copilot CLI 1.0.79
• WebView2 runtime 151.0.4129.78, then 151.0.4129.86
• Windows 11 build 26310, 63.6 GB RAM