Situation
We are running a large WPF application which does not release memory for quite some time. It is not a real memory leak, as the memory will be released eventually. I know that normally, this would not be considered to be a problem. Unfortunately it becomes a performance issue in conjunction with the WPF commanding infrastructure. See below for a more detailed description.
Findings
We have automated tests, that perform typical use cases. Some cases are working fine and are releasing the memory in time. Others are hogging the memory until the client is minimized, a new Window is opened or some other conditions occur that triggers a Gen2 collection.
• With ANTS we see, that the objects do not have a GC Root, but a lot of references to other objects that require finalization.
• WinDbg does not show any objects to be ready for finalization.
• Running several GC.Collect(), GC.WaitForPendingFinalizers() completely frees the memory.
• We know which UI action causes the high memory condition, but we could not identify any suspicious code.
Question
We would appreciate any advice on debugging such a problem.
WPF CommandManager Background
The WPF CommandManager holds private collection of WeakReferences (_requerySuggestedHandlers) for raising the CanExecuteChanged Event. Handling CanExecuteChanged is quite costly (especially finding the EventRoute for CanExecute, which apparently is a RoutedEvent). Anytime the CommandManager feels like requerying if commands can be executed, it iterates through this collection and calls the CanExecuteChanged event on the respective command sources.
The WeakReferences are not removed from that collection as long as there is a GC handle for the referenced object. While the object has not been collected, the CommandHelper keeps processing CanExecute events for these elements (ButtonBase or MenuItems). In case there is a lot of garbage (as in our case), this can result in an extremely large number of calls the CanExecute event handlers, which causes the application to be really laggy.
I have the same issue with one of my applications. On every opening of a window I call:
GC.GetTotalMemory(true);
This will force GC to clean the memory immediately without waiting. You can read more about this method here:
http://msdn.microsoft.com/en-us/library/system.gc.gettotalmemory.aspx
About the problem with the calls to CanExecute, I try to avoid them because of the same performance problems. Instead, I use properties in my view model and bind the IsEnabled property of the visual elements from XAML to the properties from the view model. In this way, the overall performance is improved and the CanExecute calls are gone.
I hope this will help.
Try CLRProfiler, here's the downloading link. It shows the event handlers allocated, disposed and survived. I am sure you can trace to the root cause by using this tool.
The book Advanced .NET Debugging lists some good tools for debugging, you can read it for some help.
Related
I have a WPF application which uses MEF to load some dialogs.
I noticed that after some time it starts to build up more and more WeakReferences which seem to not be freed. The test scenario has a memory pressure item to build up ~3GB. The dialog calls a DataService and reloads the contents of a DataGrid.
What can be the cause for such amount of WeakReferences not being freed?
I cannot see any application specific references being kept.
Below a picture of the memory profiling session with a view on the last added items. Number of WeakReferences added is noticable.
Thank you in advance.
UPDATE:
The profiler I used on a remote computer shows that the build up is mainly caused by new WeakReferences. WaitCallback is probably beacuse of a loop which I made to elaborate the problem and cause a refresh every second. Otherwise the Objects delta is clean.
I have developed one UWP application.In that nearly 20 windows are there.
Every window contains lot of Xaml controls. For some time it's working fine.
But after usage of some time application is getting very slow.
After doing some R&D I came to know that it's called Memory Leakage.
As per my knowledge in .Net Garbage Collector has to take care of this if I am not wrong.It seems like In UWP Application it is not happening. So I thought I should use GC.Collect() in Page Unload Event.
Is that correct approach or anything else I need to do to release memory which are used by the window controls?
The performance optimization is a vast subject and may not be possible to answer on an open ended question (without knowledge of your environment and architecture etc).
However you can use the Visual Studio profiler to measure and track performance and to find out the area where you need to take action, these can be;
Data binding
UI Virtualization
Image rendering
Visual Tree Size
Further reading these urls may also help you.
ms docs and this blog
The GC takes care of orphaned objects or objects that are no longer referenced by any other classes. when the GC finds objects like these it removes them from memory. memory leaks happen when an object is referenced by another class even after it is done with it. this means you need to look at your code and find where this is happening. you need to help GC in doing its job by making sure you no longer reference objects you don't need.
I also wouldn't recommend using GC.Collect in page unload event since GC has to freeze threads in order to collect. this might impact performance.
Is it instantaneous after the GC runs?
I was monitoring Memory (Available MBytes) using perfmon while running an application I'm working on. As I loaded files I could see the Available MBytes going down as expected, but as I closed them it didn't go back up so I'm wondering if I am not disposing correctly or if there is something else that affects this.
When a file is loaded:
the contents are stored in some objects
a new instance of a UserControl is created
a new TabPage is created
the UserControl is added to the TabPage
the TabPage is added to the TabControl
Reading on SO I saw that one of the most common things that can cause Memory Leaks is not unsubscribing from event handlers and so I made sure I did that in my UserControl's dispose method. I subscribe to the 'RemovingTab' event of the TabControl but the TabPages themselves have no attached handlers.
When closing a file, I remove stored instances of the objects and call dispose on both the UserControl and the TabPage. I tried running the CLR profiler (which I haven't had any experience with) and it said there was no GC runs.
Another common source of memory not being released is holding onto unmanaged resources, open files being one example.
The memory is available after the GC cleans up whatever is using it. Not every GC run results in memory being released. Any object that survives at least one GC run can end up living a long time because it's no longer in generation 0 - those could end up being around until the app actually needs more memory than is currently available to it. Large objects (larger than 85kb, as far as I remember) are stored on the large object heap which also isn't part of every GC run.
Your best bet is to look at what is actually holding the memory. Use the Visual Studio performance tools or try PerfView. Once you know what is actually holding the memory you'll be in a better position to figure out how to get it released.
Is it instantaneous after the GC runs?
No. As a matter of fact, depending on the memory pressure of your particular application, the GC might not free up any memory during the whole lifespan of your application.
Reading on SO I saw that one of the most common things that can cause Memory Leaks is not unsubscribing from event handlers and so I made sure I did that in my UserControl's dispose method.
Yes that is a common cause.
When closing a file, I remove stored instances of the objects and call dispose on both the UserControl and the TabPage. I tried running the CLR profiler (which I haven't had any experience with) and it said there was no GC runs.
The GC is very good at doing what it's supposed to do and it has been fined tuned to extremes. If it doesn't run its probably because it has decided that it doesn't need to run. Therefore, when the memory is freed up by the GC is up to the GC to decide and, if I'm not mistaken, is implementation defined, so it is not something you can rely upon.
And last but not least, the IDisposable pattern is not, by any means, a deterministic pattern for reclaiming memory; that is most definitely not the pattern's goal.
I have an application which does a bunch of text parsing. After each pass it spits out some info into a database and clears out all the internal state.
My issue is the memeory allocated in Windows Task Mgr / Resource Monitor keeps growing and growing. I've done some profile using .Net Mem Profiler and it looks like it should be going down. Here is a screen shot from the profiler:
But in the Task Mgr after each pass the memory private working set increases. I'd like for the memory to grow as its used and then return to a normal level after each pass, that way I could keep this thing running.
Any advice on what to look for or any ideas what causes this?
A few things to check for are:
Event handlers keeping objects alive, make sure that if the object which subscribes to an event goes out of scope before the object publishing the event that it unsubscribes from the event to prevent the publishing object keep a reference to it.
Make sure that you call dispose on any object which implements IDisposable. Generally speaking objects which implement IDisposable contains resources which need special tidy up.
If you reference any com objects, make sure you release them properly.
You shouldn't ever have to call GC.Collect() within production code.
Task Mgr is not an accurate representation of the memory your application is actually using. Its more a representation of how much memory windows has allotted or planned for your application- if you app needs more, windows can expand this number, but if your app needs less, windows may not re-allocate this memory until another application actually needs it..
I think what you have above is a pretty accurate representation of what your application is actually doing (ie, its not leaking).
This forces .NET to collect all unused objects from memory, therefore reclaiming some of it:
GC.Collect();
GC.WaitForPendingFinalizers();
If you do have a memory leak, you can use the SOS debugging extension to try to find it. This article is also a very good example and a little more complete then what my answer will include.
You can use this in either VS or WinDbg, and the only difference is how you load the dll. For Visual Studio, first enable unmanaged debugging in the debug tab of your project's properties. When it comes time to load it, use .load SOS.dll in the Immediate Window. For WinDbg, either open the executable or attach to the process, and, to load it, use .loadby sos clr for .NET 4 or .loadby sos mscorwks for 2 or 3.5.
After letting the application run for a while, pause it (break all). Now you can load SOS. Upon success, enter !dumpheap -stat. This will list off how much memory each class is using. If this isn't enough to find the leak, the other article I linked goes into more depth on how to locate the memory leak.
One way to solve this is break up your work into separate executable programs. Once a program completes its work and ends, all its memory will be reclaimed by the system.
Working with WinForms you have to free memory after using gdi objects, event handlers, objects from native code, etc.
In WinForms I used to remove for example event handlers in the dispose method.
What is the best workaround to prevent memory leaks in Wpf? Is it the same as in Winforms using Dispose pattern? At all, do I have to care about event handlers, gdi objects in Wpf? What about the runtime created resources(Brushes, etc)?
This blog post lists the most common situations that cause memory leaks in WPF applications.
Event handlers to objects in parent windows
Registering to events from static objects
Using timers
Data binding
Changing the Text property of a text box
It also describes how to fix these common issues.
Another good approach is to develop an app while following the standard guidelines and then use some kind of profiler to determine any memory leaks or performance bottlenecks.
From MSDN: Any WPF framework-level element (those objects deriving from either FrameworkElement or FrameworkContentElement) has three common lifetime events: Initialized, Loaded, and Unloaded.
.....
Unloaded is raised last and is initiated by either the presentation source or the visual parent being removed. When Unloaded is raised and handled, the element that is the event source parent (as determined by Parent property) or any given element upwards in the logical or visual trees may have already been unset, meaning that data binding, resource references, and styles may not be set to their normal or last known run-time value.
Some helpful links on WPF resource dictionary leaks:
DynamicResource\StaticResource cause memory leaks
Memory leak problem with ResourceDictionary and MergedDictionaries
Watch out for events: it's very easy to miss something, because all references from the delegate will exist until the delegate lives. I suggest to use weak event pattern when it's possible. Actually Microsoft uses it in their Prism framework.
http://msdn.microsoft.com/en-us/library/aa970850.aspx
Also check out an issue that I was catched by many times when learning WPF http://support.microsoft.com/kb/938416/en-us