-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Windows] Window Memory Leak #22973
Comments
Hi I'm an AI powered bot that finds similar issues based off the issue title. Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you! Open similar issues:
Closed similar issues:
|
Still having similar problems in dotnet8. Can you please provide a fix for this problem? I'm cleaning all the events and even a empty window can cause this after a while. |
Can repro this issue at Windows platform on the latest 17.11.0 Preview 2.0(8.0.0-rc.2.9530&8.0.40). |
I've been running some tests with WinUI3 and apparently has the same problem, the memory still increasing and never released. |
I have the same problem in my project that has already been launched in production. Does anyone have a workaround? |
I have the same problem in my project, and this issue is crucial for us. |
Got the same issue in my project. Do we already have a workaround? |
Any update on this problem? |
Unfortunately, I am having the same problem and can't find a solution. Any feedback? |
Then it's certainly a good idea to report it in the https://github.com/microsoft/microsoft-ui-xaml repo. |
Cleaning GestureManager from MyView (ContentView) on unload, it was possbile to release some memory and remove all MauiWinUIWindow, Window and my content views instances from memory. Apparently GestureManager and GesturePlatformManager never been disposed and hold an instance of my view after window closed and view unloaded. |
(Perhaps @jonathanpeppers could comment on this one.) |
Hi @jonathanpeppers, thank you for answer me, I made the same code as you, only difference is I run GC.Collect on MainWindow Deactivated and after open new windows, close them, open again I got this result, running in Release: There's 18 mauiwinuiwindow in memory Actually FooWindows was collected in my tests, but the main problem is, the use of RAM memory still increasing, and this is the problem in my company's application, check this out: Some windows opened: My views has only some labels on it, IMHO, since MauiWinUIWindow still in memory, and task manager doesn't show significant memory decrease, something is not right. Update: This is the main problem, if user still opening and closing windows, with more complex views, the memory can reach 1gb with only main window running. |
Maybe above there's some insights to help your investigation. |
Fixes: dotnet#22973 Context: https://github.com/danielancines/memory-leak-dotnet8-maui After reviewing the above sample app, I found that the `MauiWinUIWindow` class was not ever going away. I could see it being held by `NavigationRootManager`: * `Microsoft.Maui.MauiWinUIWindow` -> * `Microsoft.Maui.Platform.NavigationRootManager` -> * `Windows.Foundation.TypedEventHandler<Microsoft.UI.Xaml.Controls.NavigationView, Microsoft.UI.Xaml.Controls.NavigationViewBackRequestedEventArgs>` After some trial and error, I found that simply changing `NavigationRootManager`'s `_platformWindow` field a `WeakReference` "untangles" things, and the sample no longer leaks `MauiWinUIWindow` instances. Unfortunately, I was not able to write a passing test for this issue. No matter what I tried, the platform `Window` is kept alive by a "strong handle". But taking a snapshot after the test ends, it goes away? I still thing the test is useful, as it verifies the other objects.
Fixes: dotnet#22973 Context: https://github.com/danielancines/memory-leak-dotnet8-maui After reviewing the above sample app, I found that the `MauiWinUIWindow` class was not ever going away. I could see it being held by `NavigationRootManager`: * `Microsoft.Maui.MauiWinUIWindow` -> * `Microsoft.Maui.Platform.NavigationRootManager` -> * `Windows.Foundation.TypedEventHandler<Microsoft.UI.Xaml.Controls.NavigationView, Microsoft.UI.Xaml.Controls.NavigationViewBackRequestedEventArgs>` After some trial and error, I found that simply changing `NavigationRootManager`'s `_platformWindow` field a `WeakReference` "untangles" things, and the sample no longer leaks `MauiWinUIWindow` instances. Unfortunately, I was not able to write a passing test for this issue. No matter what I tried, the platform `Window` is kept alive by a "strong handle". But taking a snapshot after the test ends, it goes away? I still thing the test is useful, as it verifies the other objects.
Fixes: dotnet#22973 Context: https://github.com/danielancines/memory-leak-dotnet8-maui After reviewing the above sample app, I found that the `MauiWinUIWindow` class was not ever going away. I could see it being held by `NavigationRootManager`: * `Microsoft.Maui.MauiWinUIWindow` -> * `Microsoft.Maui.Platform.NavigationRootManager` -> * `Windows.Foundation.TypedEventHandler<Microsoft.UI.Xaml.Controls.NavigationView, Microsoft.UI.Xaml.Controls.NavigationViewBackRequestedEventArgs>` After some trial and error, I found that simply changing `NavigationRootManager`'s `_platformWindow` field a `WeakReference` "untangles" things, and the sample no longer leaks `MauiWinUIWindow` instances. Unfortunately, I was not able to write a passing test for this issue. No matter what I tried, the platform `Window` is kept alive by a "strong handle". But taking a snapshot after the test ends, it goes away? I still thing the test is useful, as it verifies the other objects.
Description
I'm working for a big company and we having memory leaks issues, when user opens a new window, the memory on Task Manager never is released and still increasing. To test purposes, I created a fresh new Maui .net 8 app and got some weird behaviors.
After open 5 windows and closing them, opening more 9 windows and closing them, it appears that old 5 windows come back to life and still on the heap. Other issue is, the memory on task manager never is released and still increasing with more windows creation. Sometimes the old windows come back to life to and the number os Controls.Window are increased on the next snapshot.
Steps to Reproduce
Link to public reproduction project repository
https://github.com/danielancines/memory-leak-dotnet8-maui
Version with bug
8.0.3 GA
Is this a regression from previous behavior?
Not sure, did not test other versions
Last version that worked well
Unknown/Other
Affected platforms
Windows
Affected platform versions
No response
Did you find any workaround?
No
Relevant log output
No response
The text was updated successfully, but these errors were encountered: