Geek Answers Handbook

Detection of memory leaks in a mixed environment (controlled-unsteered)

I have an application written in VC ++ MFC 6.0. It has recently been upgraded to .NET 3.5 by compiling vs2008 and adding some WPF applications to it using a managed and unmanaged environment. Mostly hosted by WPF in the win32 window. If I just open a WPF application window, the memory will continue to grow as 1 KB / 10 seconds. I tried to use the Profiler .NET Memory Profiler and Memory Ants. But both do not help me in detecting leaks! I deleted all the WPF controls from the hosted WPF application. He simply contains a page that has only the frame. But still there is a leak !! Somebody, please help me, which may lead to an increase in the amount of memory the application?

+1
memory-leaks wpf managed unmanaged
source share
3 answers

Well, after some soul searching revealed that the leak is actually related to an error in the frame. Read more http://social.msdn.microsoft.com/Forums/zh/wpf/thread/5b9ae245-9067-4ca4-b846-180db9f7bde5

+1
source share

First, you must determine whether you have a leak managed memory leaks or internal memory:

Use these PerfMon counters for this:

  • Process / private bytes
  • Memory .NET CLR / # Bytes in all heaps
  • .NET CLR LocksAndThreads / # of current logical thread.

If 1 is increasing, but remains stable 2, you have a memory leak. If 1 and 2 are increased, you have a leak managed memory.

If 3 suddenly increases, stacks drain flows.

If you find a leak managed memory, you will .NET profiling tools like Ants, YourKit etc. Since they do not help in your case, you probably have a leak.

Important. Be sure to call the collector manually garbage before looking at memory usage. If the memory pressure is not enough, the GC will not work, and the memory of your process increases (which is not a leak in this particular case.) Causes the GC as follows:

GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect();
+5
source share

This article describes some common causes of memory problems in WPF — it might be worth a read:

http://www.red-gate.com/products/dotnet-development/ants-memory-profiler/learning-memory-management/WPF-Silverlight-pitfalls

As for your attempts to find a leak using memory profiles, try using ANTS:

1) Take two snapshots in a minute or two (profiler automatically triggers garbage collection until a snapshot every time).

2) Make sure the snapshot set to baseline snapshot 1, and for the last snapshot set snapshot 2.

3) Go to the class list.

4) In the "Basic Filters" section, select "Show only new objects from the current snapshot."

5) Select the largest class, then go to the list of instances.

6) For one of the instances, open the instance's storage graph, which shows the link chains holding this instance in memory.

7) A little luck, you will see that the object holds on to what it should not, which you can fix. If not, repeat steps 5 and 6, but select different classes / instances.

+1
source share

More articles:


All Articles