17

I'm looking into why a managed process is using a lot of memory. Is there a way to run GC.Collect(3) from WinDbg, so that I can focus on the actual memory allocation?

Mark
  • 6,269
  • 2
  • 35
  • 34
Roger Lipscombe
  • 89,048
  • 55
  • 235
  • 380

4 Answers4

5

I don't think there is any way to run a .NET garbage collection from WinDbg, but I also don't think it is necessary.

See Rico Mariani's Performance Tidbits - Tracking down managed memory leaks (how to find a GC leak) for information about finding out what kind of stuff is on your heap.

Additional possibly useful links:

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Grant Wagner
  • 25,263
  • 7
  • 54
  • 64
  • 2
    I'm interested. Could you explain why you don't think it's necessary? – Roger Lipscombe Dec 02 '08 at 16:47
  • It isn't necessary because Rico Mariani's information about tracking down managed memory leaks describes a process to determine what may be leaking, or what is on the heap at any point in your application without having to force a GC. – Grant Wagner Dec 02 '08 at 16:52
  • 3
    Won't you often run into a problem with step 7 (of Rico Mariani's blog post) if you have lots of objects lying around that could be GC'd? Seems like a common frustration to !gcroot object after object and find no reference chains at all. – IV. Feb 12 '10 at 02:42
  • @IV I agree - it's a real pain. I often use the 'disposed' flag as a proxy for this information but not all classes implement IDisposeable or use this flag in its implementation. For example: .foreach (obj {!dumpheap -type Oracle.DataAccess.Client.OracleConnection -short}) { .printf "\n\n"; .printf "Object at: %p\nDisposed: %d", ${obj}, poi(${obj}+12a) & 0x00FF; } – Thomas Bratt Jun 21 '12 at 21:34
  • In a huge dump, analyzing memory leaks without GC.Collect is very hard. – cskwg Mar 23 '22 at 07:16
3

I do not believe that you can trigger a GC from WinDbg.

Here are some useful tools that I have come to rely on for memory allocation tracking:

  • SOSEX -- a further extension for WinDbg to complement SOS which adds !dumpgen to dump objects from a particular generation (great for figuring out what is on the LOH and in Gen 2) and the !refs command which will give the parent refs for an object.
  • .Net Memory Profiler -- this is a very useful tool when running interactively but it also contains an option to load from a dump file. This gives a reasonably intuitive way to track through memory usage. Easily worth the 250USD price but they also have a 14 day eval.
Dave Ganger
  • 611
  • 3
  • 8
2

WinDBG is first and foremost a Win32/Kernel Debugger. So you may want to try one of the managed debuggers, like mDBG. But I used to do .NET Debugging support for MSFT, and I've never needed anything like that to troubleshoot memory leaks.

Cory Foy
  • 7,202
  • 4
  • 31
  • 34
0

Hey Roger, Hopefully your memory leak is resolved by now. :-)

I would first be sure that it is "managed memory leak". By that I mean that when you look at Performance Monitor counters .NET CLR Memory -> # Bytes in all heaps is increasing at the same rate as the Process -> Private Bytes counter for the same process. If it is, then you can use the techniques described above.

If it is not, you may have a native leak that is a result of running managed code. The most common that I have see is related to .NET Assemblies being loaded in the process and not unloaded. This looks like a native memory leak in Perfmon.

I would suggest that you try running a Leak Rule in DebugDiagand see what the memory report shows as the leaking callstacks.

Here is another great resource on the subject: I have a memory leak!!! What do i do? (defining the "where")

Thanks, Aaron

AaronBa
  • 741
  • 6
  • 5
  • It's solved. I used the techniques from the other answers to find out what was being "leaked". It was a load of PaintEventArgs objects or something. The cause: an animated progress bar that was redrawing 10 times a second. So it wasn't actually a leak, just a control using way too much memory. – Roger Lipscombe Feb 22 '09 at 07:31