软件调试
点此进入淘宝搜索页搜索分類: 图书,计算机/网络,软件工程/开发项目管理,
作者： 张银奎著
出 版 社： 电子工业出版社
出版时间： 2008-6-1字数： 1200000版次： 1页数： 1006印刷时间： 2008/06/01开本： 16开印次： 1纸张： 胶版纸I S B N ： 9787121064074包装： 平装编辑推荐
ACM院士和调试技术先驱Jack B.Dennis教授做历史回顾计算机和操作系统领域资深专家David A.Solomon撰写序言。调试高手笔耕三载集十余年经验成百万言篇，业内专家鼎力相助，汇五十年精华补软件界空白。
您将学习到：
CPU的调试支持，包括异常、断点、单步执行、分支监视、JTAG、MCE等。
Windows操作系统中的调试设施，包括内核调试引擎、用户态调试予系统、验证器、Dr.Watson、WER、ETW、故障转储、WHEA等。
Visual C／C++编译器的调试支持，包括编译期检查、运行期检查，以及调试符号。
WinDBG调试器的发展历史、模块结构、工作模型、使用方法、主要调试功能的实现细节，以及遍布全书的应用实例。
内核调试、用户态调试、JIT调试、远程调试的原理、实现和用法。异常的概念、分发方法、处理方法（SEH、VEH、CppEH），未处理异常，以及编译器编译异常处理代码的方法。
调试符号的作用、产生过程、存储格式和使用方法。栈和堆的结构布局、工作原理和有关的软件问题，包括栈的自动增长和溢出，缓；中区溢出，溢出攻击，内存泄漏，堆崩溃等。
软件的可调试性和提高可调试性的方法。
此外，书中还诠释了很多较难理解的概念，思考了一系列耐人深思和具有普遍意义的问题。本书是对软件调试技术在过去50年中所取得成就的全面展示，也是笔者本人在软件设计和系统开发第一线奋战10多年的经验总结。本书适合每一位希望深刻理解软件和自由驾驭软件的人阅读，不论您是否直接参与软件开发和测试；不论您是热爱软件，还是憎恨软件；不论您是想发现软件中的瑕疵，还是想领略其中蕴含的智慧！
本书直面软件工程中的最困难任务——侦错
围绕软件世界中的最强大工具——调试器
全方位展示了软件调试技术的无比威力和无穷魅力
80个示例程序的源程序文件和项目文件
浏览符号文件的SymView工具
与内核调试引擎对话的KdTalker工具
直接浏览用户态转储文件的UdmpView工具
显示CPU执行轨迹（分支）的Cpuwhere工具
观察IDT、GDT和系统对象的SOZOOmer工具
本书是对软件调试技术在过去50年中所取得成就的全面展示，也是对作者本人在软件设计和系统开发第一线奋战10多年的经验总结。全书共分6篇30章，选取了大量具有代表性和普遍意义的技术细节进行讨论，包括CPU的调试支持、操作系统的调试支持、编译器的调试支持、WinDBG及其实现等，是学习软件调试技术的宝贵资料。该书可供各大专院校作为教材使用，也可供从事相关工作的人员作为参考用书使用。
内容简介
围绕如何实现高效调试这一主题，本书深入系统地介绍了以调试器为核心的各种软件调试技术。本书共30章，分为6篇。第1篇介绍了软件调试的概况和简要历史。第2篇以英特尔架构(IA)的CPU为例，介绍了计算机系统的硬件核心所提供的调试支持，包括异常、断点指令、单步执行标志、分支监视、JTAG和MCE等。第3篇以Windows操作系统为例，介绍了计算机系统的软件核心中的调试设施，包括内核调试引擎、用户态调试子系统、异常处理、验证器、错误报告、事件追踪、故障转储、硬件错误处理等。第4篇以Visual C/C++编译器为例，介绍了生产软件的主要工具的调试支持，重点讨论了编译期检查、运行期检查及调试符号。第5篇讨论了软件的可调试性，探讨了如何在软件架构设计和软件开发过程中加入调试支持，使软件更容易被调试。在前5篇内容的基础上，第6篇首先介绍了调试器的发展历史、典型功能和实现方法，然后全面介绍了WinDBG调试器，包括它的模块结构、工作模型、使用方法和主要调试功能的实现细节。
本书是对软件调试技术在过去50年中所取得成就的全面展示，也是对作者本人在软件设计和系统开发第一线奋战10多年的经验总结。本书理论与实践紧密结合，选取了大量具有代表性和普遍意义的技术细节进行讨论，是学习软件调试技术的宝贵资料，适合每一位希望深刻理解软件和自由驾驭软件的人阅读，特别是从事软件开发、测试、支持的技术人员和有关的研究人员。
目录
第1篇 绪论
第1章 软件调试基础
1.1 简介
1.2 基本特征
1.3 简要历史
1.4 分类
1.5 调试技术概览
1.6 错误与缺欠
1.7 与软件工程的关系
1.8 本章总结
第2篇 CPU的调试支持
第2章 CPU基础
2.1 指令和指令集
2.2 IA-32处理器
2.3 CPU的操作模式
2.4 寄存器
2.5 理解保护模式
2.6 段机制
2.7 分页机制（Paging）
2.8 系统概貌
2.9 本章总结
第3章 中断和异常
3.1 概念和差异
3.2 异常的分类
3.3 异常例析
3.4 中断/异常优先级
3.5 中断/异常处理
3.6 本章总结
第4章 断点和单步执行
4.1 软件断点
4.2 硬件断点
4.3 陷阱标志
4.4 实模式调试器例析
4.5 本章总结
第5章 分支记录和性能监视
5.1 分支监视概览
5.2 使用寄存器的分支记录
5.3 使用内存的分支记录
5.4 DS示例：CpuWhere
5.5 性能监视
5.6 本章总结
第6章 机器检查架构（MCA）
6.1 奔腾处理器的机器检查机制
6.2 MCA
6.3 编写MCA软件
6.4 本章总结
第7章 JTAG调试
7.1 简介
7.2 JTAG原理
7.3 JTAG应用
7.4 IA-32处理器的JTAG支持
7.5 本章总结
第3篇 操作系统的调试支持
第8章 Windows概要
8.1 简介
8.2 进程和进程空间
8.3 内核模式和用户模式
8.4 架构和系统部件
8.5 本章总结
第9章 用户态调试模型
9.1 概览
9.2 采集调试消息
9.3 发送调试消息
9.4 调试子系统服务器（XP之后）
9.5 调试子系统服务器（XP之前）
9.6 比较两种模型
9.7 NTDLL中的调试支持例程
9.8 调试API 224
9.9 本章总结
第10章 用户态调试过程
10.1 调试器进程
10.2 被调试进程
10.3 从调试器中启动被调试程序
10.4 附加到已经启动的进程
10.5 处理调试事件
10.6 中断到调试器
10.7 输出调试字符串
10.8 终止调试会话
10.9 本章总结
第11章 中断和异常管理
11.1 中断描述符表
11.2 异常的描述和登记
11.3 异常分发过程
11.4 结构化异常处理（SEH）
11.5 向量化异常处理（VEH）
11.6 本章总结
第12章 未处理异常和JIT调试
12.1 简介
12.2 默认的异常处理器
12.3 未处理异常过滤函数
12.4 应用程序错误对话框
12.5 JIT调试和Dr. Watson
12.6 顶层异常过滤函数
12.7 Dr. Watson
12.8 DRWTSN32的日志文件
12.9 用户态转储文件
12.10 本章总结
第13章 硬错误和蓝屏
13.1 硬错误提示
13.2 蓝屏终止（BSOD）
13.3 系统转储文件
13.4 分析系统转储文件
13.5 辅助的错误提示方法
13.6 配置错误提示机制
13.7 防止滥用错误提示机制
13.8 本章总结
第14章 错误报告
14.1 WER 1.0
14.2 系统错误报告
14.3 WER服务器端
14.4 WER 2.0
14.5 CER
14.6 本章总结
第15章 日志
15.1 日志简介
15.2 ELF的架构
15.3 ELF的数据组织
15.4 察看和使用ELF日志
15.5 CLFS的组成和原理
15.6 CLFS的使用方法
15.7 本章总结
第16章 事件追踪
16.1 简介
16.2 ETW的架构
16.3 提供ETW消息
16.4 控制ETW会话
16.5 消耗ETW消息
16.6 格式描述
16.7 NT Kernel Logger
16.8 Global Logger Session
16.9 Crimson API
16.10 本章总结
第17章 WHEA
17.1 目标和架构
17.2 错误源
17.3 错误处理过程
17.4 错误持久化
17.5 注入错误
17.6 本章总结
第18章 内核调试引擎
18.1 概览
18.2 连接
18.3 启用
18.4 初始化
18.5 内核调试协议
18.6 与内核交互
18.7 建立和维持连接
18.8 本地内核调试
18.9 本章总结
第19章 Windows的验证机制
19.1 简介
19.2 驱动验证器的工作原理
19.3 使用驱动验证器
19.4 应用程序验证器的工作原理
19.5 使用应用程序验证器
19.6 本章总结
第4篇 编译器的调试支持
第20章 编译和编译期检查
20.1 程序的构建过程
20.2 编译
20.3 Visual C++编译器
20.4 编译错误和警告
20.5 编译期检查
20.6 标准标注语言
20.7 本章总结
第21章 运行库和运行期检查
21.1 C/C++运行库
21.2 链接运行库
21.3 运行库的初始化和清理
21.4 运行期检查
21.5 报告运行期检查错误
21.6 本章总结
第22章 栈和函数调用
22.1 简介
22.2 栈的创建过程
22.3 CALL和RET指令
22.4 局部变量和栈帧
22.5 帧指针省略（FPO）
22.6 栈指针检查
22.7 调用协定
22.8 栈空间的增长和溢出
22.9 栈下溢
22.10 缓冲区溢出
22.11 变量检查
22.12 基于Cookie的安全检查
22.13 本章总结
第23章 堆和堆检查
23.1 理解堆
23.2 堆的创建和销毁
23.3 分配和释放堆块
23.4 堆的内部结构
23.5 低碎片堆（LFH）
23.6 堆的调试支持
23.7 栈回溯数据库
23.8 堆溢出和检测
23.9 页堆
23.10 准页堆
23.11 CRT堆
23.12 CRT堆的调试堆块
23.13 CRT堆的调试功能
23.14 堆块转储
23.15 泄漏转储
23.16 本章总结
第24章 异常处理代码的编译
24.1 概览
24.2 FS:[0]链条
24.3 遍历FS:[0]链条
24.4 执行异常处理函数
24.5 __try{}__except()结构
24.6 安全问题
24.7 本章总结
第25章 调试符号
25.1 名称修饰
25.2 调试信息的存储格式
25.3 目标文件中的调试信息
25.4 PE文件中的调试信息
25.5 DBG文件
25.6 PDB文件
25.7 有关的编译和链接选项
25.8 PDB文件中的数据表
25.9 本章总结
第5篇 可调试性
第26章 可调试性概览
26.1 简介
26.2 Showstopper和未雨绸缪
26.3 基本原则
26.4 不可调试代码
26.5 可调试性例析
26.6 与安全、性能和商业秘密的关系
26.7 本章总结
第27章 可调试性的实现
27.1 角色和职责
27.2 可调试架构
27.3 通过栈回溯实现可追溯性
27.4 数据的可追溯性
27.5 可观察性的实现
27.6 自检和自动报告
27.7 本章总结
第6篇 调试器
第28章 调试器概览
28.1 TX-0计算机和FLIT调试器
28.2 小型机和DDT调试器
28.3 个人计算机和它的调试器
28.4 调试器的功能
28.5 分类标准
28.6 实现模型
28.7 经典架构
28.8 HPD标准
28.9 本章总结
第29章 WinDBG及其实现
29.1 WinDBG溯源
29.2 C阶段的架构
29.3 重构
29.4 调试器引擎的架构
29.5 调试目标
29.6 调试会话
29.7 接收和处理命令
29.8 本章总结
第30章 WinDBG用法详解
30.1 工作空间
30.2 命令概览
30.3 用户界面
30.4 输入和执行命令
30.5 建立调试会话
30.6 终止调试会话
30.7 理解上下文
30.8 调试符号
30.9 事件处理
30.10 控制调试目标
30.11 单步执行
30.12 使用断点
30.13 控制进程和线程
30.14 观察栈
30.15 分析内存
30.16 遍历链表
30.17 调用目标程序的函数
30.18 命令程序
30.19 本章总结
附录A 示例程序列表
附录B WinDBG标准命令列表
索引
书摘插图
第1篇 绪论
第1章 软件调试基础
1955年，一个名叫Computer Usage Corporation（CUC）的公司诞生了，它是世界上第一个专门从事软件开发和服务的公司。CUC公司的创始人是Elmer Kubie和John w Sheldon，他们都在IBM工作过。从当时计算机硬件的迅速发展中，他们看到了软件方面所潜在的机遇。CUC的诞生标志着一个新兴的产业正式起步了。
与其他产业相比，软件产业的发展速度是惊人的。短短50几年后，我们已经难以统计世界上共有多少个软件公司，只知道一定是一个很庞大的数字，而且这个数量还在不断增大。同时，软件产品的数量也达到了难以统计的程度，各种各样的软件已经渗透到人类生产和生活的各个领域，越来越多的人开始依赖软件工作和生活。
与传统的产品相比，软件产品具有根本的不同，其生产过程也有着根本的差异。在开发软件的整个过程中，存在非常多的不确定性因素。在一个软件真正完成之前，很难预计它的完成日期。很多软件项目都经历了多次的延期，还有很多中途夭折。直到今天，人们还没有找到一种有效的方法来控制软件的生产过程。导致软件生产难以控制的根本原因是来源于软件本身的复杂性。一个软件的规模越大，它的复杂度也越高。
简单来说，软件是程序（program）和文档（document）的集合，程序的核心内容便是按一定顺序排列的一系列指令（instruction）。如果把每个指令看作一块积木，那么软件开发就是使用这些积木修建一个让CPU（中央处理器）在其中运行的交通系统。这个系统中有很多条不同特征的道路（函数）。有些道路只允许一辆车在上面行驶，一辆车驶出后另一辆才能进入，有些道路可以让无数辆车同时在上面飞奔。这些道路都是单行道，只可以沿一个方向行驶。在这些道路之间，除了明确的入口（entry）和出口（exit）之外，还可以通过中断和异常等机制从一条路飞越到另一条，另一条又可以飞转到第三条或直接飞回到第一条。在这个系统中行驶的车辆也很特殊，它们速度很快，而且“无人驾驶”，完全不知道会跑到哪里，唯一的原则就是上了一条路便沿着它向前跑……
如果说软件的执行过程就好像是CPU在无数条道路（指令流）间飞奔，那么开发软件的过程就是设计和构建这个交通网络的过程。其基本目标是要让CPU在这个网络中奔跑时可以完成需求（requirement）中所定义的功能。对这个网络的其他要求通常还有可靠（reliable）、灵活（flexible）、健壮（robust）、易于维护（maintainable），可以简单地改造就能让其他类型的车辆（CPU）在上面行驶（portable）……
开发一个满足以上要求的软件系统不是一件简单的事，通常需要经历分析（analysis）、设计（design）、编码（code）和测试（test）等多个环节。通过测试并发布（release）后，还需要维护（maintain）和支持（support）工作。在以上环节中，每一步都可能遇到这样那样的技术难题。
在软件世界中，螺丝刀、万用表等传统的探测和修理工具都不再适用了，取而代之的是以调试器为核心的各种软件调试（Software Debugging）工具。
软件调试的基本手段有断点、单步执行、栈回溯等，其初衷就是跟踪和记录CPU执行软件的过程，把动态的瞬间凝固下来供检查和分析。
软件调试的基本目标是定位软件中存在的设计错误（bug）。但除此之外，软件调试技术和工具还有很多其他用途。比如，分析软件的工作原理，分析系统崩溃，辅助解决系统和硬件问题等。
概而言之，软件是通过指令的组合来指挥硬件，既简单，又复杂，充满神秘与挑战。而软件调试是帮助人们探索和征服这个神秘世界的有力工具。
第1章软件调试基础
著名的计算机科学家Brian Kernighan曾经说过，软件调试要比编写代码困难一倍，如果你发挥出了最佳才智编写代码，那么你的智商便不足以调试这个代码。
另一方面，软件调试是软件开发和维护中非常频繁的一项任务，几乎在软件生命周期的每个阶段，都有很多这样那样的问题需要进行调试。
一方面是难度很高，另一方面是任务很多。因此，在一个典型的软件团队中，花费在软件调试上的人力和时间通常是很可观的。据不完全统计，一半以上的软件工程师把一半以上的时间用在软件调试上。很多时候，调试一个软件问题可能就需要几天乃至几周的时间。从这个角度来看，提高软件工程师的调试效率对于提高软件团队的工作效率有着重要意义。
本书旨在从多个角度和多个层次解析软件调试的原理、方法和技巧。在分别深入介绍这些内容之前，本章将做一个概括性的介绍，使读者了解一个简单的全貌，为阅读后面的章节做准备。
1.1 简介
这一节我们首先给出软件调试的解释性定义，而后介绍软件调试的基本过程。
1.1.1 定义
首先，什么是软件调试?我们不妨从英文的原词software debug说起，debug是在bug一词前面加上词头de，意思是分离和去除bug。
Bug的本意就是昆虫，但至少早在19世纪时，人们就开始使用这个词来描述电子设备中的设计缺欠，著名发明家托马斯阿尔瓦爱迪生（1847—2—11—1931—10－18）就使用这个词来描述电路方面的设计错误。
关于Bug一词在计算机方面的应用流传着一个有趣的故事。时间是在20世纪40年代，当时的电子计算机都还非常庞大，数量也非常少，主要用在军事方面。1944年制造完成的Mark 1，1946年2月开始运行的ENIAC（Electronic Numerical Integrator AndComputer）和1947年完成的Mark Ⅱ是其中赫赫有名的几台。Mark 1是由哈佛大学的HowardAiken教授设计，IBM公司制造的，Mark Ⅱ是由美国海军出资制造的。与使用电子管制造的ENIAC不同，Markl和MarkⅡ主要是使用开关和继电器制造的。另外，Mark l和Mark Ⅱ都是从纸带或磁带上读取指令并执行的，因此，它们不属于从内存读取和执行指令的存储程序计算机（stored—program computer）。
1947年9月9日，当人们测试Mark Ⅱ计算机时，它突然发生了故障。经过几个小时的检查后，工作人员发现一只飞蛾被打死在面板F的第70号继电器中。当把这个飞蛾取出后，机器便恢复了正常。当时为Mark Ⅱ计算机工作的著名女科学家GraceHopper将这只飞蛾粘贴到当天的工作手册中（见图1.1），并在上面加了一行注释，“Firstactual case ofbug being found”，当时的时间是15：45。随着这个故事的广为流传，越来越多的人开始使用Bug一词来指代计算机中的设计错误，并把Grace Hopper上登记的那只飞蛾看作是计算机历史上第一个被记录在文档（documented）中的Bug。图1—1 计算机历史上第一个被记录在文档中的Bug在Bug一词广泛使用后，人们自然地开始使用debug这个词来泛指排除错误的过程。关于谁最先创造和使用了这个词，目前还没有公认的说法，但是可以肯定的是，Grace Hopper在20世纪50年代发表的很多论文中就已频繁使用这个词了。因此可以肯定地说，在20世纪50年代人们已经开始使用这个词来表达软件调试这一含义，而且一直延续到今天。
尽管从字面上看，debug的直接意思就是去除Bug，但它实际上包含了寻找和定位Bug。因为去除Bug的前提是要找到Bug，如何找到Bug大都比发现后去除它要难得多。而且，随着计算机系统的发展，软件调试已经变得越来越不像在继电器间“捉虫”那样轻而易举了。因此，在台湾，人们把software debug翻译为软件侦错。这个翻译没有按照英文原词的字面含义直译，超越了原本的单指“去除”的境界，融入了侦查的含义，是个很不错的意译。
在大陆，通常将software debug翻译为软件调试，泛指重现软件故障（failure）、定位故障根源，并最终解决软件问题的过程。这种理解与英语文献中对software debug的深层解释也是一致的。如微软的计算机词典（Microsoft Computer Dictionary,FifthEdition）对debug一词的解释是：
debug vb.To detect,locate，and correct logical or syntactical errors in a program ormalfunctions in hardware.
对软件调试的另一种更通俗的解释是指使用调试工具求解各种软件问题的过程，例如跟踪软件的执行过程，探索软件本身或与其配套的其他软件，或者硬件系统的工作原理等，这些过程有可能是为了去除软件缺欠，也可能不是。
1.1.2 基本过程
尽管取出那只飞虫非常轻松，但是找到它还是耗费了几个小时的时间。因此，软件调试从一开始实际上就包含了定位错误和去除错误这两个基本步骤。进一步讲，一个完整的软件调试过程是图1—2所示的循环过程，它由以下几个步骤组成。
第一，重现故障，通常是在用于调试的系统上重复导致故障的步骤，使要解决的问题出现在被调试的系统中。
第二，定位根源，即综合利用各种调试工具，使用各种调试手段寻找导致软件故障的根源（root cause）。通常测试人员报告和描述的是软件故障所表现出的外在症状，比如界面或执行结果中所表现出的异常；或者是与软件需求（requirement）和功能规约（function specification）不符的地方，即所谓的软件缺欠（defect）。而这些表面的缺欠总是由于一个或多个内在因素所导致的，这些内因要么是代码的行为错误，要么是不行为错误（该做而未做）。定位根源就是要找到导致外在缺欠的内因。
第三，探索和实现解决方案，即根据寻找到的故障根源、资源情况、紧迫程度等设计和实现解决方案。
第四，验证方案，在目标环境中测试方案的有效性，又称为回归（regress）测试。如果问题已经解决，那么就可以关闭问题。如果没有解决，则回到第3步调整和修改解决方案。
图1—2软件调试过程
在以上各步骤中，定位根源常常是最困难也是最关键的步骤，它是软件调试过程的核心和灵魂。如果没有找到故障根源，那么解决方案便很可能是隔靴搔痒，或者头痛医脚，有时似乎缓解了问题，但事实上没有彻底解决问题，甚至是白白浪费时间。
1.2 基本特征
上一节介绍了软件调试的定义和基本过程。本节将进一步介绍它的基本特征，我们将分3个方面来讨论。
1.2.1 难度大
诚如Brian Kernighan先生所说的，软件调试是一项复杂度高、难度大的任务。以下是导致这种复杂性的几个主要因素。
第一，如果把定位软件错误看作是一种特别的搜索问题，那么它通常是个很复杂的搜索问题。首先，被搜索的目标空间是软件问题所发生的系统，从所包含的信息量来看，这个空间通常是很庞大的，因为一个典型的计算机系统中包含着几十个硬件部件、数千个软件模块，每个模块又包含着以KB或MB为单位的大量指令（代码）。另一方面，这个搜索问题并没有明确的目标和关键字，通常只知道不是非常明确的外在症状，必须通过大量的分析，才能逐步接近真正的内在原因。
第二，为了探寻问题的根源，很多时候必须深入到被调试模块或系统的底层，研究内部的数据和代码。与顶层不同，底层的数据大多是以原始形态存在的，理解和分析的难度比顶层要大。举例来说，对于顶层看到的文字信息，在底层看到的可能只是这些文字的某种编码（ANSl或UNICODE等）。对于代码而言，底层意味着低级语言或汇编语言，甚至机器码，因为当无法进行源代码级的调试时，我们不得不进行汇编一级的跟踪和分析。对于通信有关的问题，底层意味着需要观察原始的通信数据包和检查包的各个部分。另外，很多底层的数据和行为是没有文档的，不得不做大量的跟踪和分析才能摸索出一些线索和规律。从APl的角度来看，底层意味着不仅要理解API的原型和使用方法，有时还必须知道它内部是如何实现的，执行了哪些操作，这一点也论证了Brian Kernighan所说的调试要比编写代码困难。
……
