[Problem/Bug]: Frame renderer crash (0xC0000005) when pinned Outlook add-in iframe is recreated on message switch — FRAME_RENDER_PROCESS_EXITED causes new Outlook ShutdownOnFailure (Runtime 150.0.4078.105)

What happened?

We publish a taskpane add-in for Outlook. Starting recently, the renderer process hosting our add-in's iframe intermittently crashes with an access violation. This reproduces across two Chromium-based hosts with the same add-in bundle, and does not reproduce in Firefox:

• New Outlook for Windows (olk.exe): the frame renderer process exits with COREWEBVIEW2_PROCESS_FAILED_KIND_FRAME_RENDER_PROCESS_EXITED, reason COREWEBVIEW2_PROCESS_FAILED_REASON_CRASHED, exitCode -1073741819 (0xC0000005, access violation). Outlook then shuts down entirely (unrecoverableWebViewFailureCause: ShutdownOnFailure) — a crash in one add-in iframe takes down the whole mail client.
• Outlook on the web in Edge/Chrome: the same add-in's site-isolated iframe process dies, showing the Chromium "Aw, Snap" sad-face inside the taskpane while OWA keeps running.
• Outlook on the web in Firefox: no crash, ever. The add-in's own JavaScript runs cleanly in all hosts (no uncaught exceptions before the crash; DevTools console simply stops mid-boot when the renderer dies).

The trigger correlates with iframe destroy/recreate cycles when the user switches messages with the add-in pinned. The crash occurs ~1–2 seconds after the new iframe is created, while the page is booting.

Notably, immediately before the crash, the Outlook host log shows its own frame-tracking assertion failing twice:

Check failed errorMessage Root frame already exists for instance
expression m_instanceRootFrames[instanceId] != nullptr
functionName Microsoft::NativeHost::WebHostDepr::WebViewInstanceIframeTrackerImpl::AddFrameToTree(...)
sourceLocationFileName dev\src\nh\hosting\webhost-tracking\win\WebViewInstanceIframeTracker.cpp lineNumber 1155

Relevant excerpt from the olk log (timestamps 2026-07-30, times local):

20:05:10.884 Iframe removed from tracker iframeID 1 ... (message switch)
20:05:14.190 Check failed: Root frame already exists for instance (x2, WebViewInstanceIframeTracker.cpp:1155)
20:05:14.192 Iframe added to tracker iframeID 5 iframeURL https://base-url/message-read?manifestV=3.2.2.1 rendererProcessId 23520 cumulativeRendererCommit 59
20:05:15.979 Crashing on web view process failure
20:05:15.979 Report Webview Crashpad Status reportSubmitted false
20:05:15.979 Webview failure kind COREWEBVIEW2_PROCESS_FAILED_KIND_FRAME_RENDER_PROCESS_EXITED
reason COREWEBVIEW2_PROCESS_FAILED_REASON_CRASHED exitCode -1073741819 webViewFailureRecoveryAction 1
20:05:15.980 WebView failure recorded unrecoverableWebViewFailureCause ShutdownOnFailure

Memory was not a factor: the add-in renderer was at ~59 MB commit at crash time, and the failure reason is CRASHED, not OUT_OF_MEMORY.

This may be related to the frame/window lifecycle regressions reported against the v149/v150 runtime wave in #5630 (Office.js Dialog windows crashing) and #5631 (child window creation failing on 150.0.4078.42), but the symptom here is distinct: an out-of-process iframe's renderer dying with an access violation during frame recreation.

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

150.0.4078.105

SDK Version

No response

Framework

Other

Operating System

Windows 11

OS Version

No response

Repro steps

1. Switch between messages so the host destroys and recreates the add-in iframe.
2. Intermittently (not every switch), ~1–2 s after the iframe is recreated, the frame renderer exits with 0xC0000005 and Outlook shuts down with ShutdownOnFailure.

Same pattern in Outlook on the web in Edge/Chrome produces a sad-face crashed frame in the taskpane. Firefox never reproduces it. The crash occurs with multiple versions of our add-in bundle, including builds unchanged for months, so it is not correlated with an add-in code change.

Repros in Edge Browser

Yes, issue can be reproduced in the corresponding Edge version

Regression

Regression in newer Runtime

Last working version (if regression)

No occurrences reported while machines were on 148.x.