Clever Geek Handbook

WPF Application Memory Leak

After a specific action (clicking a button that starts a computation sequence), a WPF application leaks memory (visible in the Task Manager under the vm size section) about 10 megabytes after each button click.

The calculation sequence contains no errors.

Using a memory profiler ( .NET Memory Profiler

) showed that there are no leaks in .net, but after each button click, the memory size listed under Name / Resource (marked with HeapMemory) grows by about 10 megabytes.

I've read posts about leaks in WPF but this is not my case.

What could be wrong? Any suggestions? Maybe someone else had the same problem?

+2


source to share


3 answers


Observing an increase in memory usage is incorrect in .NET for detecting a memory leak.

However, it is easy to leak memory in WPF. I would suggest using a slightly more visual tool like Redgate Ants Memory Profiler (14 days free trial). Use this method to check for leaks:

  • Press the button once (to eat any workout you may have)
  • Take a picture
  • Press the button again
  • Take a picture


When you go to the "Class List" and check the "From Current Snapshot: New Object Only" filter. This should give you a better idea of ​​whether you have objects that will never be released.

Another thing about Ants Memory Profiler is that it has video links everywhere that instruct you on how to find the leak. Tracking leaks is a bit of a black art and it's nice to have some help.

No, I don't work for Redgate :)

+3


source


Perhaps you need to use the WeakEvent Pattern as described on MSDN to avoid leaks?

Listening for events can lead to memory leaks. The typical method for listening to an event is to use language-specific syntax, which attaches a handler to the event at the source. For example, in C # this syntax: source.SomeEvent += new SomeEventHandler(MyEventHandler)

.

This method creates a strong link from the event source to the event listener. Typically attaching an event handler to the listener results in the listener having an object lifetime, which is affected by the object lifetime for the source (unless the event handler is explicitly removed). But in certain circumstances, you may want the listener lifetime to be controlled only by other factors, such as whether it currently belongs to the application's visual tree and not the source lifetime. Whenever the lifecycle of the original object goes beyond the lifetime of the listener, the normal event pattern leads to a memory leak: the listener is kept alive longer than intended.



(My emphasis.)

+2


source


I can fix the WPF application memory leak issue by thinning GC.Collect () .

Hope for this help!

0


source






More articles:


All Articles