Identifying a Memory Leak

 The symptoms of a memory leak include the following:

• A gradually worsening response time.
• The appearance of error messages indicating that system services have stopped.

• The appearance of the following error message  indicating that the system is low on virtual memory.

If you suspect that a particular application or service is causing a memory leak, investigate the memory use of your applications using the following counters:

• Memory\Available Bytes reports available bytes; its value tends to fall during a memory leak.
• Memory\Committed Bytes reports the private bytes committed to processes; its value tends to rise during a memory leak.
• Process\Private Bytes reports bytes allocated exclusively for a specific process; its value tends to rise for a leaking process.
• Process\Working Set reports the shared and private bytes allocated to a process; its value tends to rise for a leaking process.
• Process\Page Faults/sec reports the total number of faults (hard and soft faults) caused by a process; its value tends to rise for a leaking process.
• Process\Page File Bytes reports the size of the paging file; its value tends to rise during a memory leak.
• Process\Handle Count reports the number of handles that an application opened for objects it creates. Handles are used by programs to identify resources they must access. The value of this counter tends to rise during a memory leak; however, you cannot rule out a leak simply because this counter's value is stable.

Memory Leaks and the Nonpaged Pool

Although any leak is serious, memory leaks are of particular concern when they involve the nonpaged pool. Many system services allocate memory from the nonpaged pool because they need to reference it when processing an interrupt and cannot take a page fault at that time. To identify whether or not a leak affects the nonpaged pool, include the following counters in your monitoring:

• Memory\Pool Nonpaged Bytes
• Memory\Pool Nonpaged Allocs
• Process\Pool Nonpaged Bytes

Portrait of a Leaky Application

The following graphs are an example of an application with a memory leak. The leaky application is constantly requesting more memory. It is characterized by increasing Process/Page File Bytes at the same rate as the system Committed Bytes; i.e. all memory commitment is due to one process. Available Bytes are decreasing steadily until the system pages something out and then the Virtual Bytes increase to make room for more Available Bytes. The Working Set of the leaky application actually decreases when parts of it get paged out. Note how Page Faults/sec increases as Available Bytes decline.

Keyboard Exercise

The Windows Resource Kit includes an example program called LeakyApp.exe. This program has the typical fault of constantly allocating more and more memory. Start LeakyApp and investigate the memory counters with System Monitor.