[Problem/Bug]: WebView2CompositionControl fails with exception in Direct3D11CaptureFramePool.Create on first load in maximized window on virtual display adapters (VDI)

[dipsgin]

What happened?

A WPF application using WebView2CompositionControl crashes on first load when the parent Window is in WindowState.Maximized and the application is running in a VDI session with a virtual display adapter (in our case, VMware Horizon Indirect Display Driver) on a display where any dimension exceeds ~4096 pixels (e.g. a 49" ultrawide at 5120×1440, 100% DPI).

The exception is thrown synchronously from WebView2CompositionControl_Loaded and bubbles up as a DispatcherUnhandledException, terminating the host application.

Stack trace:

System.ArgumentException: Value does not fall within the expected range.
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
   at Microsoft.Web.WebView2.Wpf.GraphicsItemD3DImage.SetGraphicItem(Int32 width, Int32 height)
   at Microsoft.Web.WebView2.Wpf.WebView2CompositionControl.TryInitializeD3DImage()
   at Microsoft.Web.WebView2.Wpf.WebView2CompositionControl.WebView2CompositionControl_Loaded(Object sender, RoutedEventArgs e)

Root cause analysis:

Decompiling Microsoft.Web.WebView2.Wpf.dll shows the throw originates inside SetGraphicItem, where the WinRT call Direct3D11CaptureFramePool.Create(_device, B8G8R8A8UIntNormalized, 1, _lastSize) rejects the operation. The "Value does not fall within the expected range" message is the standard WinRT translation of E_INVALIDARG / E_BOUNDS from any of the three WinRT calls in SetGraphicItem (Direct3D11CaptureFramePool.Create, CreateCaptureSession, StartCapture) — most likely the first.

Virtual display drivers (VMware Horizon Indirect Display Driver, Citrix indirect adapters, Microsoft Basic Display Adapter, etc.) expose limited D3D11 shared-surface capabilities — typically capped around 4096 px per dimension. When the maximised window's redirection bitmap exceeds that cap, the capture pool creation fails. The bug does not affect:

• Same VDI session, same monitor, but the window is started as WindowState.Normal and later maximised.
• The same physical monitor outside VDI on a real GPU (e.g. NVIDIA RTX A1000 — works fine at 5120×1440 maximised).
• Same VDI session on a smaller monitor where no dimension exceeds 4096 px.

Critical observation: once any WebView2CompositionControl has loaded successfully in a non-maximised window in the process, all subsequent loads work regardless of window state. This indicates the failure is specifically at first capture-pool creation in the process, not at runtime resize.

Setting MaxWidth / MaxHeight on the control to small values (we tested 4000×2000, 2000×1000) does NOT prevent the crash, because the failure is not about the control's own surface size — it is governed by the maximised parent window's redirection bitmap, which the control cannot influence.

Expected behavior

WebView2CompositionControl either:

• Successfully creates the capture pipeline regardless of parent window state and display size, OR
• Surfaces a more actionable error than the generic WinRT "Value does not fall within the expected range", with a documented fallback path.

Actual behavior

• Loaded handler throws unhandled ArgumentException with no actionable message.
• The exception is not caught inside WebView2CompositionControl, so it propagates to the WPF dispatcher and crashes the host app.
• No public API to detect or pre-empt the failure short of catching the exception at the dispatcher level.

Workaround

Pre-warm the composition pipeline at startup by briefly loading a hidden WebView2CompositionControl in an offscreen WindowState=Normal window, awaiting its Loaded, then disposing. This establishes the DWM/Graphics Capture binding for the process. After this warmup, subsequent composition controls in the same process work even when their parent Window is maximised on the affected ultrawide display.

This works around the symptom but the underlying compatibility problem with virtual display adapters at large maximised window sizes remains.

Importance

Important. My app's user experience is significantly compromised.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

1.0.3065.39

SDK Version

1.0.3065.39

Framework

WPF

Operating System

Windows 10, Windows 11

OS Version

10.0.22631

Repro steps

Environment:

• Omnissa Horizon Client (formerly VMware Horizon) connecting to a Windows VDA
• Display adapter inside the session: VMware Horizon Indirect Display Driver (verified via EnumDisplayDevices)
• Physical client monitor: 49" ultrawide at 5120×1440, 100% DPI

Steps:

1. Create a WPF app with MainWindow set to WindowState="Maximized" in XAML.
2. Add a WebView2CompositionControl directly to MainWindow (or to any element loaded with the main window).
3. Build and run inside the VDI session described above.
4. Observe System.ArgumentException thrown during the Loaded event of WebView2CompositionControl. App crashes.

Compare:

• Set WindowState="Normal" on MainWindow → no crash, even after subsequently maximising.
• Run the same app outside VDI on a 5120×1440 monitor with a real GPU → no crash maximised.
• Run the same app inside the same VDI on a 1920×1080 monitor → no crash maximised.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

No response

[github-actions]

Hi, @dipsgin!

It seems that your issue contains the word "crash". If you have not already, could you attach a crash dump as a comment?

WV2 crash dumps are located in a subfolder of the app's user data folder (UDF): <UDF>\EBWebView\Crashpad\reports\. By default, the user data folder is created in the app's folder with a name like <App Exe Name>.exe.WebView2. Refer to Crash Diagnostics for more information.

Thank you for your cooperation!