WinDbg common method "Memorial client Test"

Immersion in Windows Client testing for several years, although used, but a summary of the article.

Foreword: WinDbg Everyone is very familiar with, it is to do the Windows system client test QA personnel should have mastered the location program crashes the cause of the tool,

There is a lot of information on the Internet, but really suitable for QA reading and practical information is not much, I think the most important thing I should master the combination of previous experience to share:

Basic article

1, open WinDbg, open dmp file, File--〉open crash dump (in fact there is a more convenient way, will say later)

2, set the symbol download path and load path, File--〉symbol File path, input srv*d:\symbolslocal*http://msdl.microsoft.com/download/symbols, The middle of this path can be arbitrarily set, if there are other symbolic path, such as the product's module PDB, separated by semicolons.

A symbol is a line of code that can be anchored to a specific function, or even to a specific error. In the analysis process, the PDB that is involved in the relevant Microsoft module will be downloaded and loaded as long as the DMP. There is also a "collection" of the PDB, you can search by themselves, but the symbol corresponding module version is not necessarily suitable.

3, Pop Up a workspace dialog box, choose what does not matter, yes, no are the same, do not need to pay attention to

4, open dump can see the command line window, such as open an IE dump file:

5, the bottom of the input window is used to enter the debug command

6, the first command:!analyze–v, enter, this command is the Tiger Balm, can automatically analyze who is probably the cause of the crash, then it to follow what content? See

7. What should I think? Look up from the bottom! This is the process of executing the module inside the memory when it crashes. Pay attention to "following xxx", literally means that the next paragraph can be wrong, the program here to collapse the meaning, because it is from the bottom to go up, so "following XXX" above the content is the collapse of things, and "following XXX" The content below is the "cause" of the crash, the closer the "following XXX" is, the more likely it will be the direct module that causes the crash, but that's not necessarily. If the catch of the DMP time is too late, there will be stack destruction scenarios, then the "following XXX" get the content may be wrong, then this dmp meaning is not big, of course, QA can not pay attention to this, to pay attention to how to let oneself grasp the timing of DMP more timely.

8, the second command: KB, carriage return, this command is the above supplement, used to display the current thread call stack (called stack) of the content, it can see more detailed memory information, better locate the cause of the crash, such as the content of the 360 related to see things, is not that the crash and 360 does not matter? Not necessarily! Look at the contents of KB

9, remember to look up from the bottom! You can see that IE called the Safemon.dll function before starting to create DMP, is there any reason to suspect this crash and network shield related? Raise the Bug!

10, unfortunately we only see and net shield related, but specific is the net shield what function, what parameters cause can not see, how to see? Then you can see the importance of the symbol file!

Ps: Another command is ~*KB, which is used to display the call stack for all threads in the dump, which is generally used to indicate that the dump is already ugly and can search for keywords such as kiuserexceptiondispatcher from the command results. A thread that can generally be thought of as having Kiuserexceptiondispatcher is the thread that caused the crash.

Advanced article

1. Setting the DMP Type file association Open with WinDbg

A) cmd to WinDbg directory run Windbg–ia

2, manually grasp the method of DMP:

A) If the program crashes after no DMP file generation can take the following method to dump Dum.

b) When the program crashes and does not exit, open the Windebugger program and select the crash process in file--execution attach to a process--.

c) Execute again. Dump/ma C:\testdump.dmp (if no/ma,dump size is smaller)

3, the method of automatic scratching DMP:

A) cmd to WinDbg directory run Windbg-is

b) Perform the operation that caused the crash

c) can catch DMP, execute. Dump/ma C:\testdump.dmp

4, using WinDbg to adjust the process of debugging

A) Open the Windebugger program and execute the open executable--in file--to select the process file to be debugged

b) When the process is not self-protected or has no anti-debugging, enter G in the input box, return, you can open the process, at this time if the process crashes, will be immediately captured. This method gets the DMP better than the second one.

5, set the global Flags, automatic attach process. Global Flags (gflags), after setting it up, the target process will be attach immediately when it is started, mainly for debugging some system processes, or "dependent" processes, which cannot be opened directly by Method 4, can only be called by other processes, and called with an immediate crash, So you can't use method 2. This method can set up many checks at the same time.

This digest from: http://www.cnblogs.com/idbeta/p/4992128.html

WinDbg common method "Memorial client Test"