DebugDialog for Windows memory leak analysis

Articles on memory leaks in Windows I have written two articles <<Windows program memory leak (Memory Leak) analysis of UMDH>> and <<Windows program memory leak (Memory Leak) analysis of Windbg>> . Students with rich debugging experience will find that it is difficult to use one tool or method to analyze all scenarios, especially when the project is huge. This article will introduce the DebugDialog provided by Microsoft, which can be used to analyze Hang, performance problems, memory leaks and so on. For memory leaks, DebugDialog will give a complete Report after analysis, which saves you the process of analyzing memory through Windbg commands, and is suitable for beginners.

sample code

According to the usual practice, we first wrote a piece of memory leak code, causing 4M memory leaks every 20 seconds.

#include <iostream>
#include <chrono>
#include <thread>

#define STR_SIZE 4*1024*1024
class TestClass
{
public:
    char m_str[STR_SIZE];
};

void MemoryLeakObj()
{
    TestClass * pObj = new TestClass;
    strcpy_s(pObj->m_str, STR_SIZE, "Memory Leak Sample");
    std::cout << pObj->m_str << std::endl;
}

int main()
{
    std::this_thread::sleep_for(std::chrono::seconds(30));
    while (true)
    {
        MemoryLeakObj();
        std::this_thread::sleep_for(std::chrono::seconds(20));
    }
    return 0;
}

DebugDialog memory leak analysis

The first step is to open the DebugDialog Collection and select the type of problem you need to analyze. For example, what we want to analyze is the Native Memory and Handle Leak problem.

 The second step is to select the running process you need to monitor:

The third step is to select the time you need to generate Dump, at least 15 minutes, which can be determined according to the speed at which your project generates Memory Leak.

The fourth step is to activate the Rule you configured, and the process that needs to be monitored will be injected into LeakTrack.dll for auxiliary analysis. Next, wait quietly until the Dump file is generated.

The fifth step is to open DebugDialog Analysis, first configure the symbol file directory:

Then select MemoryAnalysis, and add the Dump file generated after the Monitor just now. Click Start Analysis to analyze.

DebugDialog memory leak report analysis

The report is mainly divided into four parts, Summary, Virtual Memory Analysis, Heap Analysis and Leak Analysis.

Summary

Here we mainly introduce the source of the memory application. For example, the following ucrtbase.dll has applied for more than 180 M, so we can know that the memory leak of this program is mainly through the memory leak of the CRT library application, that is, malloc and new. So where did you apply? See the Leak Analysis section for details. 

Virtual Memory Analysis

This part mainly talks about the usage of virtual memory, focusing on Committed Memory and Native Heaps, which are about 200M. That is to say, the main reason is that the heap consumes a lot of memory. Generally speaking, memory leaks are also heap memory leaks. In addition, memory can be used directly through technologies such as VirtualAlloc and Memory Map.
This part also displays some basic information about loaded modules and threads.

Heap Analysis

A process can have multiple heaps. We use VS2015 to compile, and the malloc application memory in the CRT library uses the system default heap (Default Process Heap). Note that it has committed 197.81M of memory.

Leak Analysis

This part is the key part of the memory leak, and will list the location and size of the detailed memory application. The first thing to check is that the Leak Probability is displayed as 100%, which is very suspicious. It lists the function call stack with an application memory of 4M. You can use the function call stack (d:\test\test\memoryleak\source.cpp @ 24 + a) Find where the memory leak is.