The CLR fully introduces

It can be difficult to discover and correct memory problems in managed applications. Memory problems are manifested in a variety of ways. For example, you will observe that the memory usage of your application is increasing, resulting in an "out-of-memory" (OOM) exception (your application may even raise an out-of-memory exception if there is a large amount of available physical memory). However, any of the following conditions indicate that there may be a problem with memory:

Throws a OutOfMemoryException (Out-of-memory exception).

The process takes up too much memory, and you cannot determine any obvious cause.

It seems that the garbage collection feature does not quickly clean up objects.

Too many managed heap fragments.

The application is overly CPU intensive.

This column discusses the research process and shows you how to collect the data you need to determine the type of memory problem in the application you are facing. This column does not include how to actually fix the problems you have discovered, but can provide you with an in-depth analysis of the root cause of the problem.

Let's start with a brief introduction to the most useful performance counters available for studying managed memory issues. We then introduce the tools that are commonly used in the research process, and then introduce a series of common managed memory issues and how to study these issues.

Before you begin, however, you should first familiarize yourself with some basic concepts:

Garbage collection in the Microsoft®.net Framework. For more information, see the following two blog records: Blogs.msdn.com/156626.aspx and blogs.msdn.com/234273.aspx.

The workings of virtual memory in Windows®. This includes the concept of reserving memory and allocating memory.

Use Windows Debugger (WINDBG and CDB).

Tools to use

Before we begin, we should spend some time discussing some of the tools that are commonly used to diagnose memory-related problems.

Performance counters in general, you will want to understand performance counters first. These counters allow you to gather the necessary data to determine the exact location of the problem. While some other tools are noteworthy, the most useful performance counters are the performance counters described on the. NET Framework.

Debugger Here we will use WINDBG, which is provided with the Windows debugging tools. The Son of Strike Extension (SOS) provided in SOS.dll is used to debug managed code in WINDBG. After you start the debugger and attach it to a managed process (or load a crash dump), you can load the SOS.dll by typing the following code:

. Loadby SOS Mscorwks

If the application you are debugging is using a different version of Mscorwks.dll, the command cannot be executed, you should find the Mscorwks.dll version of SOS.dll that the application is using, and then run the following command:

. Load 

<path_to_sos>\sos.dll

SOS.dll is installed with the. NET Framework under the%windir%\microsoft.net\framework\<.net version > directory. The SOS.dll extension provides a number of useful commands for checking the managed heap. For documentation on all of these commands, see SOS Debugging Extension (SOS.dll).

Windows Task Manager Taskmgr.exe can easily find out more memory usage than expected and can examine trends in some simple process metrics over time. Note that there are two commonly misunderstood metrics in Taskmgr: Mem Usage (Memory usage) and VM size (virtual memory size). The Mem Usage represents a process working set (just like a process \ Working set performance counter). It does not represent the number of bytes used. VM Size reflects the number of bytes (like process \ Private byte count performance counters) that are used by the process. VM Size provides a first clue as to whether you are facing a memory leak problem (if your application is compromised, the VM size will increase over time).

Memory dumps most of the research techniques described in this column are dependent on memory dumps. There are two ways to use the debugger-you can attach it to a running process, or use it to analyze a crash dump. The first method provides a direct view that allows you to understand the state of the application at run time, but this technique is not always feasible.