这里产生的Leak无法用CRT方式抓到，实验了visual leak detector http://sites.google.com/site/dmoulding/vld
_CrtSetDbgFlag(_CrtSetDbgFlag(_CRTDBG_REPORT_FLAG) | _CRTDBG_LEAK_CHECK_DF);
也添加了ONNOCACHE = 1这个全局环境变量
我用了Debug Diag Tool，
Allocation type BSTR allocation(s)
Allocation Count 5 allocation(s)
Allocation Size 47.86 KBytes
Leak Probability 43%
Finding memory leaks
- From WinDbg’s command line do a !address –summary.
If RegionUsageHeap or RegionUsagePageHeap are growing, then you might have a memory leak on the heap. Proceed with the following steps.
- Enable "Create user mode stack trace database" for your image in GFlags (gflags.exe /i +ust)
- From WinDbg’s command line do a !heap -stat, to get all active heap blocks and their handles.
- Do a !heap -stat -h 0. This will list down handle specific allocation statistics for every AllocSize.
For every AllocSize the following is listed: AllocSize, #blocks, and TotalMem. Take the AllocSize with maximum TotalMem.
- Do a !heap -flt s . =AllocSize that we determined in the previous step. This command will list down all blocks with that particular size.
- Do a !heap -p -a to get the stack trace from where you have allocated that much bytes. Use the that you got in step 4.
- To get source information you must additionally enable page heap in step 1 (gflags.exe /i +ust +hpa)
- Do a dt ntdll!_DPH_HEAP_BLOCK StackTrace , where is the DPH_HEAP_BLOCK address retrieved in step 5.
- Do a dds ", where is the value retrieved in step 7.
Note that dds will dump the stack with source information included.
Think about it: If you are leaking something, then there are going to be a lot of them. Whereas things you aren’t leaking will be few in number. Therefore, if you grab something at random, it will most likely be a leaked object! In mathematical terms, suppose your program’s normal memory usage is 15 megabytes, but for some reason you’ve used up 1693 megabytes of dynamically-allocated memory. Since only 15 megabytes of that is normal memory usage, the other 1678 megabytes must be the leaked data. If you dump a random address from the heap, you have a greater-than-99% chance of dumping a leaked object.
So grab a dozen or so addresses at random and dump them. Odds are you’ll see the same data pattern over and over again. That’s your leak. If it’s a C++ object with virtual methods, dumping the vtable will quickly identify what type of object it is. If it’s a POD type, you can usually identify what it is by looking for string buffers or pointers to other data.
Your mileage may vary, but I’ve found it to be an enormously successful technique. Think of it as applied psychic powers.