问题
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?
回答1:
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:
- When to call GC.Collect()
- Scott Dorman - .NET Memory Management – Resources
回答2:
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.
回答3:
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.
回答4:
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
来源：https://stackoverflow.com/questions/334174/can-i-run-a-net-garbage-collection-from-windbg