[Problem/Bug]: WebView2 leaks GDI objects on mouse movement over rendering surface

[johnsideserf]

Description

WebView2 leaks GDI objects when the mouse moves over its rendering surface. The leak occurs regardless of CSS, JavaScript, or host application behavior. Over time this exhausts the Windows per-process GDI limit (10,000), causing system-wide cursor stutter and UI lag.

Reproduction

1. Create a WebView2 window (via WRY/Tauri, but likely reproducible with any host)
2. Load a simple HTML page (static text is sufficient)
3. Monitor GDI objects: `GetGuiResources(GetCurrentProcess(), GR_GDIOBJECTS)`
4. Move the mouse over the WebView2 surface continuously

Result: GDI object count climbs ~2000+ per 30 seconds of mouse movement and never decreases.

Control: With the mouse stationary or outside the WebView2 window, GDI count is stable.

Evidence

Monitoring via PowerShell (`GetGuiResources` every 30 seconds):

Mouse hovering over static text in WebView2

```
12:26:36 | gdi=42
12:27:06 | gdi=2268 (+2226 in 30 seconds)
```

Mouse stationary (no interaction)

```
gdi stable at 30-36 for 30+ minutes
```

What we ruled out

Extensive testing ruled out application-side causes:

• Not CSS: Removed all `:hover` rules and `transition` properties — still leaks
• Not JavaScript: JS heap stable, DOM node count stable (47 nodes unchanged)
• Not the host app: Instrumented all Rust-side GDI operations (`GetIconInfo`, `GetDIBits`, `DeleteObject`) with `GetGuiResources` delta checks — zero delta from application code
• Not rendering count: Debouncing React re-renders from 4/event to 1/event had no effect
• `SetIsVisible(false/true)` makes it WORSE — toggling visibility causes even MORE GDI objects to leak (~6000 in 30 seconds vs ~2000 without toggling)
• `pointer-events: none` in CSS does not help — WebView2 still receives `WM_MOUSEMOVE` at the OS level

Impact

This particularly affects taskbar/widget-style applications where the WebView2 window sits at a screen edge and the mouse frequently crosses it. In our case (Zebar, a desktop widget app using Tauri/WRY), users experience cursor stutter and UAC dialog lag after 1-2 hours of normal use.

Environment

• Windows 11 (MSYS_NT-10.0-26200)
• WebView2 Runtime (latest stable)
• Tested via WRY 0.51.2 / Tauri 2.x
• Multiple WebView2 windows active

Additional context

Filed via investigation on:

• WebView2 leaks GDI objects on mouse movement over rendering surface tauri-apps/wry#1691
• WebView2 leaks GDI objects on GlazeWM workspace switch glzr-io/zebar#264

[castorix]

I don't see any GDI leaks (checked with Process Explorer) with MS samples, like WebView2GettingStarted
on Windows 10 22H2, WebView2 Runtime 145.0.3800.97

[johnsideserf]

Thanks for testing. Our environment differs in a few ways:

• Windows 11 (build 26200), not Windows 10
• WebView2 Runtime 146.0.3856.59 (pre-release/edge channel)
• Host app uses WRY 0.51.2 (Rust WebView2 wrapper from Tauri project), not the Win32 C++ API directly

WRY creates the WebView2 with these additional browser args:

--disable-features=msWebOOUI,msPdfOOUI,msSmartScreenProtection --enable-features=RemoveRedirectionBitmap

It may be worth testing on Windows 11 specifically, or with the RemoveRedirectionBitmap feature enabled, as that changes how DWM composition interacts with the WebView2 surface.

We also confirmed the leak persists with --disable-gpu-compositing, so it's not specific to GPU rendering.

[johnsideserf]

Additional testing: disabling RemoveRedirectionBitmap via WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--disable-features=RemoveRedirectionBitmap had no effect on the GDI leak. So it is not related to that feature flag.

To summarize what we have ruled out on the host side:

• Not browser args (RemoveRedirectionBitmap, --disable-gpu-compositing)
• Not JavaScript (tested with plain HTML, zero JS)
• Not CSS (removed all hover/transition styles)
• Not the host app's GDI usage (instrumented all Win32 GDI calls with GetGuiResources deltas, all zero)
• Not WRY's NotifyParentWindowPositionChanged or SetBounds handling

The leak reproduces with a plain <p> tag HTML document, no scripts, no styles, just mouse movement over the WebView2 surface.

Our environment:

• Windows 11 build 26200
• WebView2 Runtime 146.0.3856.59
• Host: WRY 0.51.2 (Rust/Tauri WebView2 wrapper)

Since the commenter above could not reproduce on Windows 10 + WebView2 145, this may be specific to Windows 11 and/or WebView2 146.

[castorix]

I also tested with Runtime : 147.0.3912.0 canary (still on Windows 10, but in WinUI 3/C# and Visual Hosting (CreateCoreWebView2CompositionControllerWithOptions))

[johnsideserf]

Thanks for testing across multiple runtimes and hosting models. Since you can't reproduce on Windows 10 with either 145 (stable) or 147 (canary), and we consistently reproduce on Windows 11 build 26200, it's looking like this may be a Windows 11-specific issue, possibly related to DWM composition differences between the two OS versions.

Would you be able to test on a Windows 11 machine by any chance? Even a minimal Win32 or WinUI 3 WebView2 app with a simple HTML page would be enough. Just move the mouse over the WebView2 surface and watch GDI object count in Task Manager or Process Explorer.

[BadhriRavi91]

@johnsideserf Thanks for the detailed investigation and information.

Could you please provide us following information ? This would help us narrow down the investigation.

1. Exact WebView2 SDK NuGet package version used by WRY 0.51.2 -
2. Exact WebView2 Runtime version — confirm via CoreWebView2Environment.BrowserVersionString (you mentioned 146.0.3856.59, please confirm)
3. Can you reproduce with the Stable runtime channel? WebView2 Runtime 145.x stable instead of 146.x edge/canary — this would confirm or rule out a 146-specific regression
4. Can you reproduce with a minimal Win32 C++ sample? You can find out sample apps here
   https://github.com/MicrosoftEdge/WebView2Samples/tree/main/SampleApps
5. GDI handle types — Can you identify which specific GDI object types are leaking using GDIView (by NirSoft) or a similar tool? Knowing whether the leaks are cursors (HCURSOR), bitmaps (HBITMAP), device contexts (HDC), or regions (HRGN) would significantly narrow the internal code path
6. Does the leak occur with Visual Hosting (Composition Controller) vs. Windowed hosting mode? WRY uses windowed hosting by default. Please confirm.
7. Does --disable-gpu (not --disable-gpu-compositing) have any effect? This switches to software rendering entirely

Thanks!

[jasonria]

One of my customers is currently experiencing GDI leak issue as well. Through joint investigation, we have identified a Chromium bug related to a GDI Device Context (DC) leak. We have filed a tracking bug for this in Chromium: https://issues.chromium.org/issues/495262780

The problem is easy to reproduce: simply minimizing and maximizing the Edge window repeatedly causes the number of GDI DC objects to increase steadily, one per cycle.

This behavior has been observed not only in Microsoft Edge, but also in WebView2 and Google Chrome, indicating that the root cause lies in Chromium.

Our analysis shows that the issue is caused by code that calls GetDC without a corresponding ReleaseDC, resulting in a resource leak. The relevant code path can still be reproduced in the current Edge Canary build:

https://source.chromium.org/chromium/chromium/src/+/main:ui/display/win/screen_win.cc;l=486;bpv=1

Given that this regression is affecting an increasing number of business users, could the Edge PG please consider prioritizing this issue and coordinating with the Chromium team to drive a fix as soon as possible?

[jasonria]

Steps to reproduce the GDI leak in WebView2
Repeatedly click the Windows Search button on the taskbar.

While performing this action, monitor the GDI object count in Task Manager for the msedgewebview2.exe process.
The WebView2 instance associated with Windows Search is launched with the following command line:
C:\Program Files (x86)\Microsoft\EdgeWebView\Application\145.0.3800.97\msedgewebview2.exe --embedded-browser-webview=1 --webview-exe-name=SearchHost.exe --webview-exe-version=...

Observed result
The number of GDI objects for the msedgewebview2.exe process continues to increase each time the Windows Search button is clicked, indicating a resource leak.

Additional diagnostics
Using HUD, the captured call stack shows repeated calls to GetDC.
A review of the source code indicates that the corresponding ReleaseDC call is not made, which explains the continuous growth in GDI object usage.