locked
Memory Leak? RRS feed

  • Question

  • Hi,


    One of our clients is reporting a memory leak in one of our winforms application.
    I asked them how they came to that conclusion and they gave me a print screen of their task manager with the .NET application process at 400mb.

    Now my questions is .. Is that task manager (Win2k Server SP4) a valid tool in detecting application memory consumption?
    Is that manager accurate in reporting the actual memory foot print?

    I ask because I used perfmon to monitor the application as well. I used the 2 counters, Total Reserved Bytes and Total Commited bytes under .NET CLR Memory for my application instance. But both the values of the perf counters do not match that of task manager. In fact it is alot less!

    1/. Can some one explain to me how I can get an accurate real time memory usage of my .NET winforms app?

    2/. Can some one explain the differences in the 2 perf counters I am using, the Reserved Byte and Committed Bytes counter?



    Thanks
    Jim
    Thursday, September 6, 2007 9:53 AM

Answers

  • The best tool to use in these cases is a profiler, there are several available (as indicated by the link in Ollie's post). The leak in this case is caused by objects that are kept alive, a quick technique to find leaks is to use the CLRProfiler, you have find it at http://www.microsoft.com/downloads/details.aspx?familyid=A362781C-3870-43BE-8926-862B40AA0CD0&displaylang=en

    One of the features is the ability of taking snapshots of the managed heap. You can use the feature to check the delta in the managed heap between two points in time when you know the delta should be zero (for instance just before a dialog is opened and just after it is closed). 

    The heap snapshot is taken when you click on ' Show Heap now'. The second time what you will see is the delta so the objects that are still alive in the heap between the two snapshots.

    Anyway this is only one way, other profilers can help you tracking down object graphs and figure out the lifetime of the app's objects.

     

    About reserved and committed bytes: reserved bytes is the amount of Virtual address space that the GC reserve. The GC reserve Address space is 'big' chunks in order to avoid memory fragmentation. REserving address space only means that that specific address range is reserved and cannot be used by other components in the process, it does not mean that memory needs to be allocated. Committed bytes instead is the actual physical memory used for managed code. So you will see that reserved bytes is always greater than committed bytes.These numbers are also different from what you see in the task manager because the task manager report the total process working set so it includes code and memory allocated by unmanaged components. A more accurate way to check the application's working set is to use the VADUMP tool (you can find it in the platform SDK). If you use VADUMP -sop <ProcessID>.

     

    Hope this helps

    Claudio

     

    Saturday, September 8, 2007 12:19 AM
  • Hi,

     

    You can use ".NET CLR Memory(<processname>)\# Bytes in all Heaps" and "Process(<processname>)\Working Set" perfmon's counters for checking managed or unmanaged memory leaks. If values of both counters will increase, then we have managed's memory leaks.

    For example, you can see unmanaged's memory leaks on screenshot below:

     

    .NET CLR Memory              Process

         # Bytes in all Heaps    2521152

    Process                      Process

         Working Set          1206472704

     

     

    Sunday, September 9, 2007 9:34 AM

All replies

  • I suggest that you follow the instructions in the following link to determine if you have a memory  leak

     

    http://blogs.msdn.com/ricom/archive/2004/12/10/279612.aspx

     

    Also have you tried profiling the application at all? using a memory profiler will detail your application usage very well in a graphical manner. Check out some of the profilers list in the following link, I have used the MS & Ants profiler alot and think they are great tools.

     

    http://msdn2.microsoft.com/en-us/vcsharp/aa336818.aspx#profilers

     

     

    HTH

     

    Ollie Riches

    Thursday, September 6, 2007 12:22 PM
  • The best tool to use in these cases is a profiler, there are several available (as indicated by the link in Ollie's post). The leak in this case is caused by objects that are kept alive, a quick technique to find leaks is to use the CLRProfiler, you have find it at http://www.microsoft.com/downloads/details.aspx?familyid=A362781C-3870-43BE-8926-862B40AA0CD0&displaylang=en

    One of the features is the ability of taking snapshots of the managed heap. You can use the feature to check the delta in the managed heap between two points in time when you know the delta should be zero (for instance just before a dialog is opened and just after it is closed). 

    The heap snapshot is taken when you click on ' Show Heap now'. The second time what you will see is the delta so the objects that are still alive in the heap between the two snapshots.

    Anyway this is only one way, other profilers can help you tracking down object graphs and figure out the lifetime of the app's objects.

     

    About reserved and committed bytes: reserved bytes is the amount of Virtual address space that the GC reserve. The GC reserve Address space is 'big' chunks in order to avoid memory fragmentation. REserving address space only means that that specific address range is reserved and cannot be used by other components in the process, it does not mean that memory needs to be allocated. Committed bytes instead is the actual physical memory used for managed code. So you will see that reserved bytes is always greater than committed bytes.These numbers are also different from what you see in the task manager because the task manager report the total process working set so it includes code and memory allocated by unmanaged components. A more accurate way to check the application's working set is to use the VADUMP tool (you can find it in the platform SDK). If you use VADUMP -sop <ProcessID>.

     

    Hope this helps

    Claudio

     

    Saturday, September 8, 2007 12:19 AM
  • Taking 400mb doesn't mean that your application has memory leak because .NET garbage collector work on its own way you can use GC.Collect to release unused memory.
    But If you do such thing and still the memory isn't released and your application still has no reference to those objects it can be a leak.
    Sunday, September 9, 2007 6:28 AM
  • Hi,

     

    You can use ".NET CLR Memory(<processname>)\# Bytes in all Heaps" and "Process(<processname>)\Working Set" perfmon's counters for checking managed or unmanaged memory leaks. If values of both counters will increase, then we have managed's memory leaks.

    For example, you can see unmanaged's memory leaks on screenshot below:

     

    .NET CLR Memory              Process

         # Bytes in all Heaps    2521152

    Process                      Process

         Working Set          1206472704

     

     

    Sunday, September 9, 2007 9:34 AM