Two typical windbg debugging cases are worth learning.

 

1.Powerful bug debugging tool: Collect logs through windbg breakpoint

Address: http://blogs.msdn.com/yizhang/archive/2009/03/30/bug-windbg-log.aspx

Powerful bug debugging tool: Collect logs through windbg breakpoint

It took several days to debug a tricky bug with windbg. This bug was found by C # team. Their testcase runs for about 10 minutes and an assert within CLR will appear. The main reason for the difficulty in debugging is that assert indicates that a global data structure has encountered a problem, but the arrays that should not have been used up (according to the design, this array is used for edge cleaning and will not be used up ). We initially thought of the following solutions for debugging:

1. Set Data breakpoints

2. Step by step debugging

3. Add logCode

The main problem with setting data breakpoints is that it is not very good to determine what causes the data structure problem, and because the array is used up, it is difficult to determine which array element is added to occupy all arrays. Therefore, debugging cannot be performed by setting data breakpoints. Step-by-Step debugging obviously cannot solve the problem, because the testcase itself needs to run for ten minutes, it can be imagined that the single-step trial run for ten minutesProgramHow long will it take. Therefore, I have rejected both solutions. You can add the log code. You only need to modify the code. After each modification, you need to re-compile the code and install it on the target machine, in addition, the CLR Branch used by C # is not the branch we are developing and needs to be downloaded again.Source code, Relatively troublesome. Finally, to solve this problem, I used the windbg conditional breakpoint + Log method. The general method is as follows:

Step 1: set breakpoints in one or more suspicious locations

Bu address "command"

Bu is the unresolved Breakpoints command in windbg. It is easy to use and I prefer it. Address is the address of the Code to be disconnected. It can be the start of a function or a line. Command is very important. It indicates the command that windbg will execute every time it breaks to address. Different commands are separated by semicolons, for example:

. Echo [function a]; DV this; KB; G

These commands mean: Print [function a], print the value of this pointer, print the current call stack, and then continue to execute. You can add other commands to print the information you need according to the actual situation. The content printed using the above command is roughly as follows:

[Functiona]

This = 0 xabcdefg

Module! Funca

Module! Funcb

Module! Funcc

...

It can be seen that if this breakpoint is broken repeatedly, the hit-related information of each breakpoint will be printed in the windbg command window through the command just defined. If a lot of such breakpoints are defined, the execution of the entire program will be printed in the Command window to act as a log, and information such as the call stack can be displayed, it is much more powerful than general logs.

Step 2: SetLog

By default, the buffer size of windbg is limited. If the program runs for a long time, the buffer may not be enough. The information we output through the conditional breakpoint will be truncated. Fortunately, windbg provides the function of outputting the contents of the command window to log. Select edit-> open/close log file. The following dialog box is displayed in windbg:

In this dialog box, enter the log file name you want to save. If you want to add new content rather than overwrite the original content, append is checked.

Step 3: AnalysisLog

After obtaining the log information, the next step is to analyze the log content. This requires patience, data sensitivity, and luck. During the analysis, we may find that the log information is insufficient. In this case, we need to add a new breakpoint or modify the printed information, re-collect the log, and analyze it until the log information is sufficient. In this case, the advantage of setting conditional breakpoints in windbg is that you do not need to modify the code, compile the code, and deploy the code. Instead, you only need to enter different commands. After adjusting the breakpoint position and printed information several times and collecting logs again, I finally found through analysis that this bug is only possible when RCW is not GC, this occurs only when the creation thread exits. The specific content is involved. net 4.0 has not released any new features. We can see that if the conventional method is used, it is difficult to find the problem that will be reproduced under specific conditions.

In short, using windbg to set conditional breakpoints, print relevant information, and output to log files is a very powerful debugging method that can debug complex bugs, in addition, it has the flexibility to modify the code. You can freely define the information you want to print and the position of the breakpoint settings. The main disadvantage is that the method is slightly complicated, however, it is very convenient to adapt. I strongly recommend that you try this method when encountering complicated bugs, which may have unexpected results.

 

 

If a program fails to run 10000 times, how can you debug it?

Site: http://blogs.msdn.com/yizhang/archive/2009/08/28/9887951.aspx

There are a large number of regression tests in the CLR group. These regression tests are regularly executed to find CLR bugs. Before checkin, the developer, you also need to execute some of these tests (about 10 hours, it may take several days if all of them run ). These tests are essential to ensure the quality of CLR. Sometimes, these tests may occasionally fail. For example, if you run 100 failures once or twice, in some extreme cases, or even 10000 failures, the test fails once. Such problems are usually difficult to debug. Powerful weapon for debugging bugs earlier: Collect logs using windbg conditional breakpoints.ArticleIn, I learned how to collect various information through the conditional breakpoint to determine where the bug actually exists. However, this method is not very useful because it cannot execute a program repeatedly. Next I want to talk about a technique that can be used to debug problems like this. This technique is mainly applicable to the following situations:

1. When a program error occurs, some information and status are lost, and the previous status cannot be inferred from the current error state. Specifically, for example, access violation is caused by a variable becoming null, but it is difficult to determine why the variable becomes null.
2. It takes a long time for the program to run, and it is difficult to directly debug the program in one step.
3. It is difficult for a program to modify and add printed code (for example, it takes a lot of time to add new code and compile it, or the program does not have source code
4. The problem can be found only when the program runs for a large number of times, that is, the problem does not occur every time.

#2 and #4 determine that step-by-step debugging is basically impossible. #1 and #3 mean that we must use conditional breakpoints to collect information to identify code errors, because the direct debugging error location is not feasible. Next I will explain how to use CDB (in fact, windbg's non-UI version, windbg = CDB + UI:

1. Repeated Program Execution
2. Automatically pause when a program fails.
3. Collect information by using the conditional breakpoint, and only keep the log at the time of the Error

Let's assume that the Program Calling hello.exe is called. every time something goes wrong, it calls a function hello! In func (), the ARG parameter is null. Arg is input by a global variable g_arg. We can use the data breakpoint of the hardware to view the situation where g_arg is assigned null each time (of course, null does not mean it is an error, only hello! It is an error if it is null in func ). Generally, a program runs 10000 times to detect problems. The following command line can be used to repeatedly collect the g_arg value of func1 (func2 and func3 are similar, and will not be listed here) during execution and put it into the log file. If you find that the hello! If the ARG parameter is null in func, stop the program:

For/L % I in (1, 1, 10000) Do cdb.exe-c "Bu hello! Func \ ". echo inside hello! Func; DV;. If (POI (ARG )! = 0) {g} \ "; BA W4 hello! G_arg \ ". If (POI (hello! G_arg) = 0) {. Echo g_arg changes to NULL; kb ;}\ "; G"-g-logo Debug. Log hello.exe

Let's take a simple analysis:

1. The starting phrase is used to execute the cdbcommand again, And hello.exe is also used for 10 thousand times.
2. -C command specifies that the CDB should execute the following command at the beginning of the program
   1. Bu hello! Func ". echo inside hello! Func; DV;. If (POI (ARG )! = 0) {g} means hello every time! When func is executed, print inside hello! Func, and then print all local variables and parameters (including Arg). If Arg is found! = NULL, continue. Note that the "\" in the above command is an escape character, which represents the true quotation marks and avoids conflict.
   2. Ba W4 hello! G_arg ". If (POI (hello! G_arg) = 0) {. Echo g_arg changes to NULL; KB;} "indicates that if g_arg is changed to null each time, the callstack
   3. G command to start the program
3. -G: indicates that the CDB ignores the breakpoint at the end of the program to prevent the CDB from stopping at the end of the operation. This ensures that the CDB can be continuously executed without manual intervention.
4. -Logo Debug. Log: indicates that CDB puts the output result into Debug. log and creates a new file each time. That is to say, it overwrites the previous file. This is exactly what we need, because we have set it to stop once a program error occurs, so this Debug. Log needs to be retained.

In addition to using-C to specify the initial command, you can also use-cf to specify that a file contains any CDB command. If there are many CDB commands, you can use this method.

The method mentioned in this article is relatively effective. I have used this method to solve many difficult problems. If you encounter a bug that requires 10000 running times to reproduce the problem, try this article.