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?
views:
1146answers:
4
+4
A:
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:
Grant Wagner
2008-12-02 16:17:29
I'm interested. Could you explain why you don't think it's necessary?
Roger Lipscombe
2008-12-02 16:47:30
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
2008-12-02 16:52:07
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
2010-02-12 02:42:26
+3
A:
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
2008-12-02 16:35:26
+1
A:
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
2008-12-02 16:46:36
"I've never needed anything like that to troubleshoot memory leaks" So what *did* you use?
Damian Powell
2010-02-03 11:37:09
A:
AaronBa
2009-02-21 22:05:59
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
2009-02-22 07:31:17