最近由于工作关系接触了一些系统调试和Bug定位方面的知识，也查看了微软官方网站上的一些资料，现在将一些心得体会归纳总结下，作为一个阶段学习的汇总（大部份内容源引了微软官方博客http://blogs.msdn.com/ntdebugging/archive/2008/08/28/basics-of-debugging-windows.aspx）。
今天主要谈谈调试环境的搭建以及各种调试工具的选择。对于Windows系统而言，由于有专门的开发团队来进行维护所以有非常多的工作用于系统调试和异常问题定位分析，这些工具都可以在微软官方网站或者微软发布的resource kit上获取。
微软目前提供4种类型的调试工具。有了这些工具，您可以远程调试另一台计算机的火线或串行电缆（USB接口） ，以及调试用户态的进程和内核转储文件。
第一种工具：命令行调试器
- kd.exe，这个是内核调试器主要用于分析由于系统崩溃所产生的内核转储文件。命令行参数是：kd –z <location of dump> –y <location of symbols>)
- cdb.exe，用户态下的调试器，主要用于分析用户态程序的转储文件。命令行参数：cdb –z <location of dump> –y <location of symbols>
- ntsd.exe，几乎和cdb是相同的，不通之处在于ntsd将会生成一个新的窗口进程用于接受参数
第二种工具：图形界面的调试器
- Windbg.exe ，此工具应该是上面两个工具的集大成者，它提供了更为人性化和更易操作的界面用户进行可视化调试。关于如何使用Windbg可以参考其对应的帮助文件，里面详尽的介绍了它的各种用法
在上面的介绍中多次提到了转储文件即：dump file。
在Windows系统中转储文件分为三类：
第一类:Mini dump ，一搬是由应用程序创建的转储文件，其位置缺省是存放在%SystemRoot%/Minidump/Memory.dmp，由于是最小转储文件其大小一搬是小于1M的
第二类：内核转储文件，一搬用于查看系统崩溃时当前系统的内核的内存情况
第三类：完全转储文件，最大的内核模式的转储文件，包括内核空间和用户态空间的所有信息。
为了分析转储文件我们一搬要借助于第三方的工具，比如之前提到了windbg。下面是我摘抄了一些关于分析转储文件的信息：
In order to make fast progress with a memory dump file, it is best to load symbol files. Symbol files contains data that the debugger uses to interpret the application or driver code. They may contain:
- Global variable names
- Function names
Private Symbols would contain the above information and:
- Local variable names
- Source-line numbers
- Type information for variables, structures, etc.
Microsoft currently has two ways you can access symbols for the Operating System:
Service pack download site – You will need to create:
- Separate directories for Windows 2000 RTM, Windows 2000 SP1, Windows 2000 SP2, Windows XP RTM, etc.
- Separate directories for all of the above for free vs. checked build
- Separate directories for hotfix symbols
Public symbol server – uses a symbol store, which is a collection of symbol files. The symbol server uses the time stamp & file size to match up symbols to the active binary.After getting your symbol files together, you will need a way to tell the debugger where they are located and set up some other options.
To set the symbol path do one of the following:
- _NT_SYMBOL_PATH environment variable
- -y command line option
- .sympath (Set Symbol Path) debugger command
- WinDbg: File | Symbol File Path dialog, or CTRL+S
To set the executable Image Path (needed for minidumps only), do one of the foolowing:
- -i command line option
- .exepath debugger command
- WinDbg: File | Image File Path dialog, or CTRL+i
- Source Path
- .srcpath WinDbg: File | Source File Path dialog, or CTRL+P
If symbol errors appear when you begin, you can try the below commands to help narrow down some problems;
!sym noisy — gives verbose symbol information
AND
.reload — to reload all symbols
Also using the srv* in your symbol path tells the debugger to load and save symbols being used out to a specific directory:
srv*DownstreamStore*<symbol locations>
NOTE: You must always use .reload after you change the symbol path or fix a symbol error — the debugger doesn’t automatically reload your symbols!
Now that we are done with the overview, let’s configure our machine as a host computer to open memory a dump. I will be using Microsoft Public Symbol servers and I want to store current symbols locally to my host machine.
Using windbg I will set my current workspace symbols to: srv*c:/pubsymbols*http://msdl.microsoft.com/download/symbols
Click the menu option File ->Symbol File Path or Ctrl + S. This will bring up an empty box that will allow you to enter or browse to your symbol path.
If using kd you want to set an environment variable (_NT_SYMBOL_PATH) under “my computer properties -> advanced tab” to always start with your symbols set to: “srv*c:/pubsymbols*http://msdl.microsoft.com/download/symbols” or use this same path in your command line:
Kd –z <path to dump.file> -y srv*c:/pubsymbols*http://msdl.microsoft.com/download/symbols
NOTE: Windbg will append any workspace symbol path with the one set by the _NT_SYMBOL_PATH environment variable during loading of a memory dump.
Ok, now we know what debugger we want to use and we know our symbol locations. Let’s open our first kernel memory dump , located on <drive letter> <path to dump file>
Using windbg, I will load a dump file using menu options File ->Open crash Dump (ctrl + D) or drag the the dump file into the debugger; you can even start windbg at the command prompt. My command would look like this:
Windbg –z C:/training/case 7f/MEMORY051308.22.DMP
I did not use the –y for symbol path, as it is set already in my default workspace or in my environment variable.
When the debugger first loads a dump file it displays several lines of information before giving you a prompt to get started with your commands (by default):
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86 ß debugger version
Copyright (c) Microsoft Corporation. All rights reserved. ß Copyright of the debugger creator
Loading Dump File [C:/training/case 7f/MEMORY051308.22.DMP] ß location of the dump file loading
Kernel Summary Dump File: Only kernel address space is available ß type of memory dump (mini, kernel, or full)
Symbol search path is: srv*c:/pubsymbols*http://msdl.microsoft.com/download/symbols ß Symbol path for this debug session
Executable search path is: ß points to the directory the executable files are located. For most situations this is not needed. For other situations please check the debugger help file.
The next 4 lines talk about The OS version, service packs and how many processors are on the box
1 -Windows Server 2003 Kernel Version 3790 (Service Pack 2) MP (8 procs) Free x86 compatible
2 - Product: Server, suite: Enterprise TerminalServer SingleUserTS
3 - Built by: 3790.srv03_sp2_gdr.070304-2240
4 - Kernel base = 0x80800000 PsLoadedModuleList = 0x808a6ea8
Next we would see when the machine crashed and how long it was up prior to this crash:
Debug session time: Wed May 14 01:27:36.768 2008 (GMT-4)
System Uptime: 0 days 16:32:51.921
After completing the above process, the debugger starts loading the dump file and parsing through the loaded symbols. Here you may notice some warnings for some user space processes which are not included in the kernel dump. This is ok.
WARNING: Process directory table base BFF0A080 doesn't match CR3 007AF000
WARNING: Process directory table base BFF0A080 doesn't match CR3 007AF000
Loading Kernel Symbols
...........................................................................................................................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 7ffdf00c). Type ".hh dbgerr001" for details
Loading unloaded module list
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
1- Use !analyze -v to get detailed debugging information.
2 - BugCheck 7F, {8, f773ffe0, 0, 0}
3 - *** ERROR: Module load completed but symbols could not be loaded for ql2300.sy
The three things I want to point out from above are:
1 - !analyze –v: This is the debugger command used to help analyze a dump file by reviewing information passed to KeBugCheck including specific parameters of that crash. It will analyze this information and provide a definition of the bugcheck, a stack showing all current function calls, and, when possible, the name of an offending driver or process that the debugger thinks is at fault. Please review the debugger help file for additional information in this area.
2 – The type of bugcheck that occurred on the machine.
3 – An error telling you about symbols missing or not available to help diagnose a particular driver or application. This can lead to a misdiagnostis if you’re not careful.
Once loading is completed you should be at a kd> prompt. This prompt shows you the current processor you are using (if the machine has more than one).
For this dump we are at processor 3 on an 8 proc machine:
3: kd>
To view the current crash stack location you can use the "K" command. There are multiple forms of this command, each one dumping the basic plus additional information. As functions are executed and call other functions, a call stack is created in stack memory. Here are two common commands to view the stack:
3: kd> k
ChildEBP RetAddr
00000000 baebf0ce nt!KiTrap08+0x75
b3a4bffc baebf737 storport!RaCallMiniportInterrupt+0x2
b3a4c008 8088d889 storport!RaidpAdapterInterruptRoutine+0x1d
b3a4c008 80a59d8e nt!KiInterruptDispatch+0x49
b3a4c09c 80a5c2fc hal!HalpGenerateInterrupt+0x1d2
b3a4c0c0 80a5c44d hal!HalpLowerIrqlHardwareInterrupts+0x108
b3a4c0d0 808256ed hal!KfLowerIrql+0x59
<snippet>
3: kd> kb
ChildEBP RetAddr Args to Child
00000000 baebf0ce 00000000 00000000 00000000 nt!KiTrap08+0x75
b3a4bffc baebf737 97bedb88 b3a4c02c 8088d889 storport!RaCallMiniportInterrupt+0x2
b3a4c008 8088d889 977b9e18 97bedad0 03010006 storport!RaidpAdapterInterruptRoutine+0x1d
b3a4c008 80a59d8e 977b9e18 97bedad0 03010006 nt!KiInterruptDispatch+0x49
b3a4c09c 80a5c2fc 97797004 97bedad0 00000102 hal!HalpGenerateInterrupt+0x1d2
b3a4c0c0 80a5c44d 00000101 977b9e02 b3a4c0d8 hal!HalpLowerIrqlHardwareInterrupts+0x108
b3a4c0d0 808256ed b3a4c0e8 baebf1c6 977b9bb0 hal!KfLowerIrql+0x59
<snippet>
Either one can be used depending on how much information you want to see and can use.
This completes the Basic of Debugging Windows, Part I. I will create a Part II using specific questions gathered from our readers.
Miscellaneous information:
To go further with this topic I would suggest starting with the debugger help file included with the Microsoft Debugging Tools.
ADPlus – An automated way to use the cdb.exe to capture/create a usermode dump when a process hangs or crashes. (more info - http://msdn.microsoft.com/en-us/library/cc265629.aspx or kb286350)
Public Symbols for Microsoft Operating Systems:
Microsoft Public Symbol server : srv * DownstreamStore * http://msdl.microsoft.com/download/symbols
example: srv*c:/mysyms*http://msdl.microsoft.com/download/symbols
Microsoft Symbol packages http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx#d
Use !Analyze-v to gather additional information about the bugcheck and a bucket-id for your dump file. The bucket-id can be submitted to Microsoft for review for similar crashes and resolutions. Try using the Microsoft Online Crash Analysis to submit your crash dump bucket-id for possible follow up from Microsoft or for Microsoft to look for trends: http://oca.microsoft.com/en/Welcome.aspx
For concepts, tools and information about the system architecture:
http://msdn.microsoft.com/en-us/default.aspx
Windows Internal 4th edition (by Mark E. Russinovich & David A. Solomon) the whole book or Chapter 14 - Crash Dump Analysis
Advanced Windows Debugging (by Mario Hewardt & Daniel Pravat )
http://technet.microsoft.com/en-us/default.aspx
1293
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
