Windbg User Guide

The project is coming to an end, but there will be a memory leak bug during runtime. one day after the product was running, the memory increased to 1.4 GB, and the initial memory of our product was 70 mb. The problem was very serious, we decided to use the windbg tool to analyze the cause of the code problem.

Windbg is a source-level debugging tool released by Microsoft. It can be used for kernel mode debugging and user mode debugging, as well as dump file debugging.

Download windbg:

Install debugging tools for Windows 32-bit version
Http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

Install debugging tools for Windows 64-bit versions
Http://www.microsoft.com/whdc/devtools/debugging/install64bit.mspx

 

Configuration

After installing windbg, We need to configure two environment variable values on our development computer, _ nt_alt_symbol_path (debug bin directory) and _ nt_symbol_path (symcache directory), as shown in

_ Nt_alt_symbol_path (debug bin directory ):

_ Nt_symbol_path (symcache directory)

 

Configure the following again:

Next, run windbg.

 

Load the process to be debugged

 

At this time, it is best to load well when the memory overflow is obvious, and the debugging is obvious.

The following code is suitable for debugging C ++ Code (the product is useful to the C ++ library, the code written by C ++ and C # together, and C # Calls the C ++ Library)

Run commands

! Heap-S

The result is as follows:

0: 035>! Heap-S

Heap flags reserv commit virt Free List UCR virt lock fast

(K) length blocks Cont. Heap

-----------------------------------------------------------------------------

00250000 00000002 4096 3644 3672 1155 5 0 3 L

External fragmentation 31% (232 free blocks)

00360000 00001002 1088 72 72 1 0 1 0 l

00370000 00008000 64 12 12 10 1 1 0 0

016b0000 00001002 64 44 44 5 1 1 0 0 l

017d0000 00041002 256 12 12 4 1 1 0 0 l

01920000 00001002 64 44 44 5 1 0 0 l

01a30000 00041002 256 40 40 12 3 1 0 0 l

01c50000 00001002 64 32 32 24 1 1 0 0 l

01f00000 00001002 1088 452 456 22 2 0 0 l

02030000 00001002 7232 4828 5012 459 24 0 0 l

021c0000 00001002 64 20 5 2 1 0 0 l

04bb0000 00041002 1280 308 308 5 1 1 0 0 l

05360000 00001002 256 16 16 3 1 1 0 0 l

054a0000 00001002 256 12 12 4 1 1 0 0 l

055e0000 00001002 256 12 12 4 1 1 0 0 l

05720000 00001002 256 12 12 4 1 1 0 0 l

05860000 00001002 256 12 12 4 1 1 0 0 l

059c0000 00001002 3136 1772 1772 566 37 1 0 0

External fragmentation 31% (37 free blocks)

05ad0000 00001002 256 44 44 7 2 1 0 0 l

05c10000 00001002 256 36 16 4 1 0 0 l

080d0000 00001002 1088 56 84 47 4 3 0 0 l

08740000 00001002 1024 524 628 480 14 7 0 l

088b0000 00001002 256 160 200 25 5 2 0 0 l

08dc0000 00001002 64 12 12 4 1 1 0 0 l

09590000 00001002 1088 168 168 2 1 2 0 0 l

0ce90000 00001002 1088 84 61 3 1 0 0 l

-----------------------------------------------------------------------------

Run the command again! Heap-stat-H 059c0000 was found to have a large amount of memory in the heap.

The result is as follows:

 

 

Run again! Heap-flt s 64 631 to view heap memory allocation

The result is as follows:

 

 

There is a high similarity and address in the heap. For example, my similarity is very high.

Run again! Heap-p-A 0c903fe0

The result is as follows:

 

The method called to the DLL will be displayed, that is, the memory leak. Due to the confidentiality of the project, I have removed the information in the Code involved in the project.

 

 

This is only one of the many functions of windbg. I recorded it because it reduced the memory of our project from 1.4g to memory M.

 

Author: Spring Yang

Source: http://www.cnblogs.com/springyangwc/

The copyright of this article is shared by the author and the blog Park. You are welcome to repost this article. However, you must retain this statement without the author's consent and provide a clear link to the original article on the article page. Otherwise, you will be held legally liable.