WinDbg find a dumb way to leak memory.

The following items are transferred from http://www.cnblogs.com/fbird/p/5889596.html

Previous projects have encountered a problem, in the customer's site above the discovery of a serious memory leak. Fortunately, we found the steps to reproduce, with a few 10 trillion leaks in the round, but the following conventional methods are useless.

• Use WinDbg to dump the object on the heap and compare it with the previous operation, and not find anything useful.
• There's nothing useful on the big object heap.
• A more intelligent tool like the. NET memory Profiler is not available, because a round operation has been able to make the tool out of memory.

There are millions of lines of code in the project, but we think there are several points where a large memory leak can occur. Look up the code for those few points, no results. Zoo right looking, finally found a more stupid but very useful method.

1. Open WinDbg, attach process.

2. Load symbol

3. Break point (you can use. Logopen c:\memoryleak.txt log down)

bp kernel32!virtualalloc ". printf\" #alloc memory#%lu \\n \ ", Dwo (esp+8);! Clrstack;g; "

4. Enter G and then enter to let the process continue running.

5. Run the repro step again, then go to the review log.

The next process is rather stupid, review log in the process to find the more suspicious application of large chunks of memory points, comment code, compile assembly replace, see memory leaks are still in. Finally found the leak, a remoting proxy, out of scope but its point to the memory is not automatically released.

The key to solving this problem is the following command:
bp kernel32!virtualalloc ". printf\" #alloc memory#%lu \\n \ ", Dwo (esp+8);! clrstack;g; "

Its function is to break the point on the VirtualAlloc function of kernel32, and when the function is executed, the amount of memory requested by the function (in the position of Esp+8, Dwo is to convert the value inside to decimal), and the managed stack that invokes the function (clrstack Print it out, then let the function continue running (g).

It is necessary to note that this command is only valid for 32-bit processes because the calling convention,esp+4 of the 32-bit CPU is the first parameter location, Esp+8 is the second, and so on. The 64-bit process is going to check the corresponding calling convention to see where the relevant parameters are.

LPVOID WINAPI VirtualAlloc (  _in_opt_ lpvoid lpaddress,  _in_ size_t dwsize,  _in_ DWORD Flallo Cationtype,  _in_ DWORD flprotect);

WinDbg find a dumb way to leak memory.