To debug a bug: Collect log by WinDbg conditional breakpoint [reprint]

Reprint Link: http://blog.csdn.net/atfield/article/details/4037248

It took a few days to debug a tricky bug with WinDbg for a while ago. This bug was discovered by C # team, and their testcase run will have an assert inside the CLR for about 10 minutes. The main reason for the difficulty of debugging is that the assert indicates that there is a problem with the global data structure, but the array that should not have been used is exhausted (because by design, this array is used by edges to clean up, it will not run out). The following scenarios are initially thought to debug:

1. Set Data breakpoints

2. Step-by-step debugging

3. Add a log code

The main problem with setting a data breakpoint is that it is not very good to determine exactly what caused the data structure problem, and because the array is exhausted, it is difficult to know exactly which element of the array is being joined, causing the array to be fully occupied, and therefore cannot be debugged by setting a data breakpoint. Step-by-step debugging obviously doesn't solve the problem because the testcase itself runs for 10 minutes and can imagine how long it will take to run a 10-minute program at a single pace. So I vetoed all two of the options. Adding the log code is actually possible, just need to modify the code, after each modification need to recompile the code, and then need to install on the target machine, and C # Use of the CLR branch is not the branch we are developing, need to re-download the source code, relatively troublesome. Finally, in order to solve this problem, I took the approach of using WinDbg conditional breakpoint +log. The approximate method is as follows:

First step: Set breakpoints in one or more suspicious places

Bu[id] [Options] [Address [Passes]] ["CommandString"]

Bu is WinDbg in the setting unresolved breakpoints command, it is more convenient to use, I prefer to use. Address is the code you want to break, either the start of the function or a line. command is very important, it represents the WinDbg to execute every time the address is broken, different commands are separated by semicolons, such as:

. Echo [Function A]; DV this; kb G

These commands mean: print [Function A], print the value of the this pointer, print the current call stack, and then continue execution. You can add some other commands according to the actual situation to print some of the information you need. The above command prints something like this:

[Functiona]

this = 0xABCDEFG

module! Funca

module! Funcb

module! Funcc

...

As can be seen, if this breakpoint is broken repeatedly, then in the WinDbg Command window, each breakpoint will be hit the relevant information through the command just defined to print out. If you define a lot of these breakpoints, then in the command window will be the entire program execution of the situation to print out, play the role of log, and can display the call stack and other information, more powerful than the general log.

Step Two: Set up Log

By default, the buffer size of the WinDbg is limited, and if the program runs longer, then buffer may not be enough, and the information we are typing through the conditional breakpoint will be truncated. Fortunately, WinDbg provides the ability to output the contents of a command window to log. Select the Edit->open/close Log File menu item, WinDbg will display the following dialog box:

Enter the log file name you want to save in this dialog box. If you are adding new content instead of overwriting the original, tick the append.

Step Three: Analysis Log

When the log information is obtained, the next step is to analyze the contents of the log, a matter of patience, sensitivity to data, and a little bit of luck. The analysis may find that the log information is insufficient, then you need to add a new breakpoint or modify the printed information, re-collect the log, and then analyze it until the log information is sufficient. At this point WinDbg the advantage of setting a conditional breakpoint, because there is no need to modify the code, compile the code, deploy the code such a process, but only need to type a different command. After adjusting the breakpoint position and printing the information several times and re-collecting the log, I finally found out through the analysis that the bug is only possible in certain cases when the RCW is not being GC, and the creation thread exits, because there is not much to say about the new features that are not yet released in. NET 4.0. As you can see, it is difficult to find a problem that will reproduce under certain conditions if you adopt a conventional approach.

In summary, using WinDbg to set conditional breakpoints, print related information, and output to the log file is a very powerful debugging method, you can debug some very complex bugs, but with no need to modify the code flexibility, you can freely define the information you want to print and the location of the breakpoint settings, The main drawback is that the method is slightly more complicated, but it is convenient if it is adapted. I strongly recommend that when you encounter more complex bugs, you can try this method, which may have unexpected effects.