原文出自：http://msdn.microsoft.com/en-us/library/ms859415.aspx
Remember that only unexpected increases in memory usage suggest a memory leak. For example, if you check memory in the Directions application after starting it for the first time and check it again after calculating a complex route, the memory page number increases. In this case, however, it is an expected increase because the Directions application needed to allocate some memory to calculate and store the route. The best method of determining whether or not a memory leak exists is to perform the same operation multiple times within a single application. An application must allocate temporary memory to perform a new task for the first time. Thereafter, the application can either re–use existing allocated memory or re–allocate the same amount of memory if it was already freed. In either case, the total number of allocated pages should not increase at a value greater than the previous increase.
To locate a memory leak, use the following process:
- Find the memory leak – Detect the presence of a memory leak in the system, given a particular reproducible sequence. You should be able to identify a specific process, but demonstrating an overall increase in committed system memory can qualify a memory leak as well.
- Isolate the memory leak – Determine the exact location in the source code where the un–freed allocation occurs. This can be a lengthy and tedious process, requiring specific tools, trial–and–error, and teamwork with the original author of the code.
- Fix the memory leak – After the first two steps are completed, this is easy. Fixing the memory leak usually involves adding some code to free the memory in the questionable code path.