[Problem/Bug]: WebView2CompositionControl causes UCEERR_RENDERTHREADFAILURE and process freeze/crash on monitor disconnect (.NET Framework 4.8)

What happened?

When a monitor is disconnected while WebView2CompositionControl is active, the WPF render thread fails with UCEERR_RENDERTHREADFAILURE (0x88980406). In apps without a global exception handler the process crashes immediately. In apps with a DispatcherUnhandledException handler the exception is swallowed but the control is left permanently frozen — rendering stops and never recovers. The only workaround is to fully dispose and recreate the control.

This does not reproduce on .NET 8. It reproduces consistently on .NET Framework 4.8.

---

Environment

• WebView2 SDK: Microsoft.Web.WebView2 1.0.4078.44
• Framework: .NET Framework 4.8
• OS: Windows 11 26100
• Reproduced on: multiple machines with multi-monitor setups

Importance

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

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

1.0.4078.44

SDK Version

1.0.4078.44

Framework

WPF

Operating System

Windows 11

OS Version

26100

Repro steps

Steps to reproduce

1. Create a WPF .NET Framework 4.8 app with a WebView2CompositionControl
2. Call EnsureCoreWebView2Async() and navigate to any URL
3. With a multi-monitor setup, disconnect the monitor the app window is on

Minimal repro (see attached project):

<!-- MainWindow.xaml -->
<wv2:WebView2CompositionControl x:Name="webView"/>

// MainWindow.xaml.cs
private async void OnLoaded(object sender, RoutedEventArgs e)
{
    await webView.EnsureCoreWebView2Async();
    webView.CoreWebView2.Navigate("https://www.example.com");
}

<!-- WebView2CompositionReproNet48.csproj -->
<TargetFramework>net48</TargetFramework>
<PackageReference Include="Microsoft.Web.WebView2" Version="1.0.4078.44" />

---

Expected behavior

The control recovers gracefully from the device loss caused by the topology change — similar to how DeviceRemoved is intended to work.

---

Actual behavior

On disconnect, the process hits UCEERR_RENDERTHREADFAILURE originating from inside WebView2's D3D composition:

System.Runtime.InteropServices.COMException (0x88980406): UCEERR_RENDERTHREADFAILURE
   at System.Windows.Media.Composition.DUCE.Channel.SyncFlush()
   at System.Windows.Interop.HwndTarget.UpdateWindowSettings(Boolean, Nullable`1)
   at System.Windows.Interop.HwndTarget.UpdateWindowPos(IntPtr)
   at System.Windows.Interop.HwndTarget.HandleMessage(WindowMessage, IntPtr, IntPtr)
   at System.Windows.Interop.HwndSource.HwndTargetFilterMessage(IntPtr, Int32, IntPtr, IntPtr, Boolean&)
   at MS.Win32.HwndWrapper.WndProc(IntPtr, Int32, IntPtr, IntPtr, Boolean&)

• Without a global exception handler: the app freezes, then crashes as the unhandled exception propagates
• With DispatcherUnhandledException / e.Handled = true: the process survives but WebView2CompositionControl is permanently frozen — rendering never recovers

The exception fires multiple times from the same disconnect event (burst), and DeviceRemoved does not fire reliably to allow for self-recovery.

We also observe a secondary NullReferenceException inside GraphicsItemD3DImage.IsFrontBufferAvailablePropertyChanged → RequestRender() after the topology change, when WPF fires IsFrontBufferAvailable = true before the D3D device has recovered and the SDK's _session/_framePool fields are already null.

---

What does NOT reproduce on .NET 8

The same minimal app targeting net8.0-windows10.0.17763.0 with the same WebView2 SDK version does not freeze or crash on monitor disconnect.

---

Workaround

We hook WM_DISPLAYCHANGE on the main window HWND and fully dispose and recreate WebView2CompositionControl when the active monitor changes. This prevents the freeze but requires tearing down the entire control. We also patch the PropertyMetadata callback for IsFrontBufferAvailableProperty on GraphicsItemD3DImage via reflection to catch the NullReferenceException.

Neither workaround should be necessary — the SDK should handle display topology changes internally.

---

WebView2CompositionReproNet48.zip

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

No, this never worked

Last working version (if regression)

No response

Inizia con il progetto allegato WebView2CompositionReproNet48, in particolare con MainWindow.xaml, MainWindow.xaml.cs e WebView2CompositionReproNet48.csproj. Esegui l’app net48 con WebView2 SDK 1.0.4078.44, naviga a una pagina e disconnetti il monitor attivo per confermare l’errore del thread di rendering e il controllo bloccato. Il lavoro è completato quando è stato identificato un percorso di ripristino a livello SDK che eviti di dover effettuare la dismissione e la ricreazione dopo la modifica della topologia dei display.