A memory leak refers to a programming bug where an application program repeatedly allocates virtual memory, but never deletes it. Eventually, a program with a memory leak will cause something bad to happen. For example, the system or some of its applications might lock up because all the available virtual memory is allocated.
Several aspects of typically memory leaks make them especially insidious programming bugs. A program with a memory leak is not obviously incorrect, and may even produce the correct output or calculate the proper results. Memory leaks are often not evident until a program has been executing successfully for hours, days, or weeks. It is not always obvious which program is causing the memory leak. The memory leak may not manifest itself in the same way all the time. A program with a memory leak will eventually exhaust the supply of virtual memory pages available so that simple calls to allocate a new segment of virtual memory fail. When simple application calls to allocate a new segment of virtual memory fail, the results are often unpredictable. Finally, applications frequently make calls to allocate and free virtual memory. These calls are typically sprinkled in various spots in the program. Because system functions and DLL library routines also make frequent calls to allocate and free virtual memory, it is not easy to isolate what is causing the bug in the program. Fortunately, there are excellent automated tools for Windows application developers that can help programmers find many types of memory bugs. There is no excuse for not using some of these development and testing tools on your Windows 2000 applications in order to catch many types of memory leaks before they manifest themselves in critical product environments.
The procedure for finding a memory leak depends on what type of virtual memory is being allocated. The bug may be local to an application so that its only effect is on the process virtual address space where the leak is occurring. The bug may be in a shared DLL or other common module so that the bug will be manifest first in this application and then that one. Finally, the problem could be a leak affecting shared system memory, which can make it very difficult to pinpoint the specific application or module causing the leak. To diagnose a memory leak, be prepared to look at any or all of the following:
% Committed Bytes in Use. The Commit Limit is an upper limit on the amount of virtual memory that can be allocated on your system. The Commit Limit is tied to the size of RAM and the amount space defined for paging files (and remember that paging files can and do expand the system looks like it may run short of virtual memory). The % Committed Bytes in Use Counter reports Committed Bytes as a percentage of the Commit Limit. Whenever % Committed Bytes in Use exceeds 80-90%, application requests to allocate
per process Virtual Bytes. Virtual Bytes records the amount of virtual memory allocated by individual processes. If the program with the memory leak is allocating virtual memory in its own address space, the memory leak should be evident by tracking the per process Virtual Bytes Counter. If the amount of Virtual Bytes allocated for a process increases steadily over the life of a process, there is good reason to suspect a leak.
Pool Paged Bytes. Virtual memory for various system functions, including shared memory files (like DLLs), is allocated from the Paged Pool, which is an area of the system's virtual memory that is limited in size. A program with a memory leak that is allocating, but never freeing memory from the Paged Pool will eventually exhaust the Paged Pool. Subsequent allocations that request the Paged Pool will then fail, with unpredictable (but predictably bad) results. The Pool Paged Bytes Counter in the Memory Object reports the current number of bytes allocated from the Paged Pool. The upper limit on the size of the Paged Pool is calculated by the system at start-up. This calculation can be overridden by setting the Paged Pool Limit explicitly using the Registry parameter PagedPoolSize at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management. In either case, the upper limit on the size of the Paged Pool, according to Microsoft documentation in Windows 2000 Resource Kit is 192 MB in NT 4.0 and up to 470 MB in Windows 2000.
Pool Nonpaged Bytes. Some kernel functions and device drivers in particular require real memory buffers that can never be paged out of the system. These programs allocate memory from the nonpaged pool, which also has an upper limit. (The upper limit on the size of the nonpaged pool in Windows NT is 128 MB and 256 MB in Windows 2000.) A device driver with a memory leak will eventually exhaust the supply of Nonpaged Pool Bytes, which will cause subsequent allocations that request the nonpaged pool to fail. Running out of space in the nonpaged pool often results in a Blue Screen.