Memory Leak RRS feed

  • Question

  • I am debugging an application for an apparent a memory leak.  

    As the application runs, about once per cycle (cycles every 10 seconds), the task manager reports this application has about 1.2 megs more memory than it previously had.  

    Resharper's DotMemory reports that it is "unmanaged memory" but I can't find anything more than this since resharper only debugs managed memory.

    Since we are not explicitly creating any unmanaged resources, I assume this would relate to something like a bmp or a file.

    Any thoughts on how to find the memory leak?  Besides the main thread, there are typically about 30 threads running  

    • Edited by danielsn Monday, December 23, 2019 5:33 PM
    Monday, December 23, 2019 5:33 PM

All replies

  • Without code there is no way for us to help. However there are many things to bear in mind. Firstly if you're running under the debugger then it may just be the debugger eating up some memory. Secondly, apps tend to eat up memory early in their lifetime and then level off. For .NET there is a minimal memory usage before it'll start worrying about cleaning things up. Hence you can expect your memory usage to grow until it reaches a threshold at which time memory cleanup occurs. This is to reduce the amount of time you waste cleaning up memory just to allocate it again.

    The key for determining if you have a memory leak is that your process memory slowly creeps up over time and never drops. Depending upon the app 15 mins or more may be required. Of course if your app is eating up GB of memory then you may just be using all that memory but otherwise you probably have a leak.

    If you are running managed code then install the Microsoft.FxCop.CodeAnalysis NuGet packages so it can analyze your code. You may have `IDisposable` objects hanging around which can eat up memory. If it is in unmanaged land then it could be native calls you're making or simply resources that haven't been collected yet.

    Michael Taylor http://www.michaeltaylorp3.net

    Monday, December 23, 2019 7:17 PM
  • Search for previous answers; there are hundreds. You will at least find hundreds of replies saying that the Task Manager is not a debugging tool, especially not for memory leaks.

    It is totally normal for unmanaged Windows to allow allocated memory to remain allocated by Windows when it has been freed by the application.

    Search for previous answers. You can and should use the debugger to report memory leaks. It can also help you find the cause(s).

    If you are using a third-party library used by others then there is a good chance there is no memory leak and the only problem is using the Task Manager as a debugging tool. It is a mistake that is made very frequently.

    Sam Hobbs

    Monday, December 23, 2019 7:29 PM
  • It is very hard to check it. Count of objects in second generation in garbage collector can be helpful. Large amount of objects in second generation means garbage collector cannot clean it. As count of same type of object is growing it can show there can be memory leak. 

    It is better and easier when you know which action causes memory leaks. We have problem when close window in application. There was cyclic reference when object A had reference to form and form had reference to A. When form was disposed object A held reference to form and form cannot be disposed and was still in memory. 

    I used to investigate it by .NET Memory Profiler but it is more expensive. It is very nice to see live memory using graph so you can repeatedly try to do some action and you can see memory using. Task manager cannot be right tool to detect memory leaks because allocation can be grown until garbage collector is launched. It is important check there is same memory using after garbage collector action. 

    Monday, December 23, 2019 7:41 PM
  • for questions on a Resharper tool, you should ask in their forum.
    as far as I know, it is for managed memory only.

    When this is a pure .Net program, unmanaged memory would be due to Windows resource, which is referenced by handles.
    You could could use Windbg with SOS extension and look at the finalizer queue (!fq) .
    When there are a lot of objects from the namespace Microsoft.Win32.SafeHandles, and they are increasing with time, you probably have missing Dispose calls.

    for a mixed mode process (so managed and unmanaged code), you will have to use tools to profile unmanaged memory. Visual Studio has a memory profiler build in.
    Monday, December 23, 2019 7:50 PM