[Problem/Bug]: A memory leak issue occurs in WebView2CompositionControl. And problems arise when attempting to display it simultaneously with the WebView2 control.
What happened?
Hello, I am pleased that WebView2CompositionControl, which resolves the airspace issue in WPF applications, has been officially released. I am developing in a .NET Framework 4.6.2 environment and encountered several issues while using this control to display web pages.
Even after disposing of the WebView2CompositionControl, a memory leak issue occurs. Additionally, when DPI awareness is disabled, attempting to display WebView2 simultaneously may result in WebView2 not being displayed. Detailed information is provided in the Repro steps section.
I would appreciate it if you could check this issue.
[!NOTE] Please understand that I used a translation tool, so the message may be difficult to read. Thank you.
Importance
Moderate. My app's user experience is affected, but still usable.
Runtime Channel
Stable release (WebView2 Runtime)
Runtime Version
132.0.2957.140
SDK Version
1.0.2957.106
Framework
WPF
Operating System
Windows 11
OS Version
26100.3037 (24H2)
Repro steps
[Issues]
-
Memory Leak Issue
- A new window is opened, displaying
WebView2CompositionControl. - When the window is closed, the
Disposemethod ofWebView2CompositionControlis called, but the object is not reclaimed. - This issue does not occur with the
WebView2control.
- A new window is opened, displaying
-
Issue When Displaying
WebView2CompositionControlandWebView2Simultaneously with DPI Awareness Disabled- Open a window containing
WebView2CompositionControlwhile DPI awareness is disabled. - After waiting for the web page to load, open another window containing the
WebView2control. TheWebView2control will not be displayed. - If you call the
WebView2.EnsureCoreWebView2Async()method, the following error will occur:
"System.Runtime.InteropServices.COMException: The group or resource is not in the correct state to perform the requested operation. (HRESULT: 0x8007139F)" - However, this issue does not occur when DPI awareness is enabled!
- Open a window containing
[Attachments]
I have attached a file to help you easily reproduce this issue.
The project was built in a VS2022, .NET 4.6.2 environment.
Since the program is very simple, I will not provide additional explanations.
Download: WebView2CompTest_20250205.zip
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
I experience the same thing.
Seems like it's some problems with unhooking ShutdownFinshed:
I'm experiencing the same memory leak issue in WebView2CompositionControl, in the latest stable version (1.0.3065.39). I took a look at the code using reflection, and it does indeed seem to be that it is hooking Dispatcher.ShutdownFinished on load but not unhooking it on dispose.
Can also reproduce the behavior. I decoupled the event using reflection and noticed that the RenderCapability.TierChanged event is attached to GraphicsItemD3DImage but is not removed again when disposing
I started receiving the following error without changing anything in the app (and tried Microsoft.Web.WebView2 versions 1.0.3065.39, 1.0.2957.106, 1.0.2210.55). Is it relevant to this topic?
WebView runtime version is 133.0.3065.82.
"The group or resource is not in the correct state to perform the requested operation. (0x8007139F)"
Microsoft.Web.WebView2.Core.CoreWebView2Environment.CreateCoreWebView2ControllerAsync(System.IntPtr)
Microsoft.Web.WebView2.Wpf.WebView2.Microsoft.Web.WebView2.Wpf.IWebView2Private.InitializeController(System.IntPtr, Microsoft.Web.WebView2.Core.CoreWebView2ControllerOptions)
Microsoft.Web.WebView2.Wpf.WebView2Base.EnsureCoreWebView2Async.__Init|0()
https://github.com/MicrosoftEdge/WebView2Feedback/issues/3008#issuecomment-1916313157 - this advice helped me.
I experience the same thing.
Seems like it's some problems with unhooking ShutdownFinshed:
Will this memory leak be fixed? @prija-microsoft ?
It's still there in version 1.0.3124.44
Would love to see this resolved. Currently preventing us from utilizing compositing.
This issue still occurs even in version 1.0.3240.44. The most urgent issue is the memory leak. I hope this problem gets resolved quickly.
Can also reproduce the behavior. I decoupled the event using reflection and noticed that the RenderCapability.TierChanged event is attached to GraphicsItemD3DImage but is not removed again when disposing
An image showing the Graphics3D still keeping the CompositionControl in memory after the ShutdownFinished event has been released via reflection. Both cases needs to be handled to fully release the webview.
For others who would like to experiment with the CompositionControl without it leaking here is a short method that can be called on Unloaded.
OBS: The code assumes that you run with a wrapper around the WebView2CompositionControl. If you rather run with inheritance, replace WebView with this.
/// <summary>
/// https://github.com/MicrosoftEdge/WebView2Feedback/issues/5090
/// </summary>
private bool FixCompositionControlMemoryLeaks()
{
try
{
var wvccType = typeof(WebView2CompositionControl);
// Remove memoryleak where the Dispatcher.OnDispatcherShutdownFinished event is never unsubscribed on the WebView2CompositionControl
var shutdownMethod = wvccType.GetMethod("OnDispatcherShutdownFinished", BindingFlags.NonPublic | BindingFlags.Instance);
var shutdownEvent = Dispatcher.GetType().GetEvent(nameof(Dispatcher.ShutdownFinished));
var shutdownHandler = shutdownMethod.CreateDelegate(shutdownEvent.EventHandlerType, WebView);
shutdownEvent.RemoveEventHandler(Dispatcher, shutdownHandler);
// Remove memoryleak where the 3DImage on the WebView2CompositionControl is always bound in a pool due to:
// WindowsRuntimeMarshal.AddEventHandler((Func<TypedEventHandler<Direct3D11CaptureFramePool, object>, EventRegistrationToken>)framePool.add_FrameArrived, (Action<EventRegistrationToken>)framePool.remove_FrameArrived, (TypedEventHandler<Direct3D11CaptureFramePool, object>)OnFrameArrived);
// We fix it by removing the internal reference to Image which is the one with an actual reference to our DataContext
var d3dImageField = wvccType.GetField("_d3dImage", BindingFlags.NonPublic | BindingFlags.Instance);
var d3dImage = d3dImageField.GetValue(WebView);
var internalImageField = d3dImage.GetType().GetField("_image", BindingFlags.NonPublic | BindingFlags.Instance);
internalImageField.SetValue(d3dImage, null);
return true;
}
catch (Exception ex)
{
Logger.Warn(ex);
return false;
}
}
It's already been four months since I reported this issue. Is it particularly difficult to fix this problem? This issue still occurs even in both version 1.0.3296.44 and the 1.0.3344 pre-release.
While resolving the PDF print margin issue is important, the memory leak is just as urgent. The memory leak renders the app unusable.
As a temporary measure, I was able to resolve the memory leak issue using the code posted by @cbra-caa . I sincerely thank cbra-caa for analyzing the issue and helping to resolve it.
What I truly hope is that this issue will be fixed in an official release as soon as possible.
For others who would like to experiment with the CompositionControl without it leaking here is a short method that can be called on Unloaded.
OBS: The code assumes that you run with a wrapper around the WebView2CompositionControl. If you rather run with inheritance, replace WebView with this.
/// <summary> /// https://github.com/MicrosoftEdge/WebView2Feedback/issues/5090 /// </summary> private bool FixCompositionControlMemoryLeaks() { try { var wvccType = typeof(WebView2CompositionControl); // Remove memoryleak where the Dispatcher.OnDispatcherShutdownFinished event is never unsubscribed on the WebView2CompositionControl var shutdownMethod = wvccType.GetMethod("OnDispatcherShutdownFinished", BindingFlags.NonPublic | BindingFlags.Instance); var shutdownEvent = Dispatcher.GetType().GetEvent(nameof(Dispatcher.ShutdownFinished)); var shutdownHandler = shutdownMethod.CreateDelegate(shutdownEvent.EventHandlerType, WebView); shutdownEvent.RemoveEventHandler(Dispatcher, shutdownHandler); // Remove memoryleak where the 3DImage on the WebView2CompositionControl is always bound in a pool due to: // WindowsRuntimeMarshal.AddEventHandler((Func<TypedEventHandler<Direct3D11CaptureFramePool, object>, EventRegistrationToken>)framePool.add_FrameArrived, (Action<EventRegistrationToken>)framePool.remove_FrameArrived, (TypedEventHandler<Direct3D11CaptureFramePool, object>)OnFrameArrived); // We fix it by removing the internal reference to Image which is the one with an actual reference to our DataContext var d3dImageField = wvccType.GetField("_d3dImage", BindingFlags.NonPublic | BindingFlags.Instance); var d3dImage = d3dImageField.GetValue(WebView); var internalImageField = d3dImage.GetType().GetField("_image", BindingFlags.NonPublic | BindingFlags.Instance); internalImageField.SetValue(d3dImage, null); return true; } catch (Exception ex) { Logger.Warn(ex); return false; } }
After applying and testing the code posted by cbra-caa, I found that while objects are released when closing the window, the issue of memory usage continuously increasing when repeatedly opening and closing the window still remains. It seems that something inside the control is not being properly cleaned up...
It's already been five months since I reported this issue. This issue still occurs even in both version 1.0.3351.48. 🥲
I don’t understand why this issue has been left unresolved. It’s been six months since it was reported, and the memory leak still occurs. This problem happens in both versions 1.0.3405.78 and 1.0.3477-prerelease!
I don’t understand why this issue has been left unresolved. It’s been six months since it was reported, and the memory leak still occurs. This problem happens in both versions 1.0.3405.78 and 1.0.3477-prerelease!
Totally agree. Shocking that the Microsoft team is not addressing such a serious problem as this.
The fix has been made for the memory leak issue, and it will be available in the next pre-release version of sdk (>1.0.3477-prerelease) I am closing this issue, and suggest you to log a different bug for the second issue.
I have been waiting for this memory leak issue to be fixed.
I just tried stable release 1.0.3485.44 and the leak was still occurring.
However, pre-release 1.0.3530.0 does not leak for me. YAY!