软件调试

出版时间：2008-6  出版社：电子工业出版社  作者：张银奎  页数：1006  
Tag标签：无  

内容概要

围绕如何实现高效调试这一主题，本书深入系统地介绍了以调试器为核心的各种软件调试技术。本书共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所说的调试要比编写代码困难。

编辑推荐

　　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及其实现等，是学习软件调试技术的宝贵资料。该书可供各大专院校作为教材使用，也可供从事相关工作的人员作为参考用书使用。

用户评论 (总计17条)

•   软件调试
•   好书,码农必备
•   经典名著，值得收藏，书架收藏
•   很好的调试软件书籍
•   很好5颗星，给力书
•   刚开始看，非常不错
•   总体很满意，但是有遗憾
•   　　2月18号14:30，下周六，上海浦东，张银奎老师《软件调试》书友会。张老师将与大家一起品味书中的精彩情节，感受软件瑕疵的无情和人性的光辉，思考对抗软件瑕疵的战略战术，探讨有关的技术和技术之外的问题。
  　　报名地址：http://event.boolan.com/10002
•   　　我像个无头苍蝇编了几年代码，编的乱七八糟的，但是只知其然，不知其所以然。张老师这本书讲了很多底层的东西，从硬件到操作系统支持，到应用软件下函数传参，返回值。我是从后往前看的，比较适合我这种菜鸟，感觉能把自己这几年学的东西串起来，而且对底层也开始了解，相信会对我以后编写程序有很大帮助。
  　　
  　　推荐大家看！
•   　　本书刚出版时我就买了一本，可惜当时自身水平不够，看了不到一半就放下了。现在再来看本书，已经能比较流畅的理解内容，也越发感觉本书的珍贵。
  　　
  　　本书从调试的角度串起了X86 CPU / Windows操作系统的方方面面。之前几年我的兴趣更多的集中在对OS内核的学习，看到本书才意识到自己忽略了如此重要的一个领域。虽然一直在用VC6开发程序，但之前从来没想过它是怎么实现调试的。
  　　
  　　本书不只教授调试的方法，还讲述了CPU和操作系统为调试所构建的基础，及在此基础上建立起来的内核和应用态调试器的实现原理。这在我看过的书中是只此一本。
  　　
  　　我不知道David Solomon是凭的什么说“I only wish it was in English!”，但在中文原创的计算机技术书籍中，本书是颇让我为母语是中文而庆幸的。
  　　
  　　有的网友可能看此书感觉不知所云，此种情况有时是因为书写/译得不好，但对本书应该是读者的知识积累没有达到。给我两本德语书，我是判断不出哪本是庸俗小说，哪本是文学巨著。驱网上有人发帖说对不懂的人《天书夜读》是一本天书，对懂得的人也是天书，好到天上的书。不过，相对《软件调试》，《天书夜读》只能说是初级读本。本书适合结合《深入解析Windows操作系统》、《Windows内核情景分析》一起读，这样能获得更全面的知识。
•   　　网名：woodhead001
  　　
  　　链接：http://www.china-pub.com/member/bookpinglun/viewpinglun.asp?id=39884
  　　
  　　绝对的一本好书，看了之后对应用程序的运行机理以及其与操作系统的交互都有一个深入的理解，除此之外，还有很多很多平时你的模糊或者灰色地带都会被清除，读过此书你的技术能力会到达一个新的高度，相信看过这本书和正在看这本书的人都会有这样子的感觉，本书的作者是我认为华人圈里最牛B的少数几个人之一，如果非要排名的话应该是执牛耳了。作者对于系统有深入的了解，有深厚的调试功底，但是书的厚度太厚，很难有耐心全部读完，只能便用边看吧。
•   　　献给所有不及格的程序员们
  　　
  　　对于刚刚进入此行业的程序员来说,软件调试是一个熟悉又陌生的领域,熟悉是因为经常会听到人说"你调一下程序,看看变量值对不对?"，陌生是因为大部分程序员不知道在IDE开发环境中按F5键跟踪程序运行到底发生了什么事儿。
  　　
  　　通过阅读<<软件调试>>这本书,你将了解到什么是软件调试.
  　　代码为什么可以跟踪(trace)、调试(debug),
  　　什么是ring0（内核级）ring3（用户级）调试，在书中你都将找到答案.
  　　
  　　如果你是新手，本书将带你走入神密的计算机内部世界，了解关于最早的计算机以及调试工具的历史。
  　　如果你是老手，你也许会找到共鸣，回想到以前被软件的bug折磨的日日夜夜，就连做梦都在想究竟哪有问题。
  　　
  　　如果你是桌面程序编写者，该书可以成为你的调试参考书。
  　　当Windows发生该死的蓝屏时，当Office程序突然停止响应,你能用本书中学到的知识恢复还没有存盘的文件或者寻找问题的跟源。
  　　
  　　
  　　如果你是一个Web前端程序员,写javascript代码，会用firebug调试js，你真不想知道背后都有哪些事情发生吗？
  　　通过软件调试技术来跟踪它吧，ie我说不好(没源码)，火狐（Firefox）你的却可以。
  　　
  　　一本书的内容不能囊获所有，虽然它很厚，但它是国内目前最好的关于软件调试书籍，感谢作者的辛劳与奉献。
  　　想知道的更多，就快找找相关的书吧！
  　　
  　　不及格的程序员-八神
  　　blog:http://ioriwellings.spaces.live.com
  　　本人买了两本此书，一本给公司里的同事们看，一本放在家里，以便随时拿来参考。
  　　
  　　
  　　
  　　
  　　
•   　　从CPU到操作系统再到编译器讲述调试功能，结构清晰。不过读此书的目的是什么呢，写一个调试器？如果仅仅是为了提高自己的调试能力，本书作用很小。但是另一方面，如果在本方面的知识比较丰富，也能写出更便于调试的程序，呃，我把刚才自己说的言论推翻了。
  　　总之，强烈推荐。
•   　　首先要肯定张老师写了一本非常好的书，从您的书中学到了不少东西，尤其是一些调试机理的东西对自己收获很大。曾经的曾经对调试器很感兴趣，觉得他是个很神秘的东西就象以前对操作系统内核的感觉似的。国内TRW的作者刘涛涛先生，Syser的作者吴岩峰先生都做出过自己的debugger，当年特好奇刘涛涛是怎么在以前资料那么匮乏，网络又不发达的时候怎么把TR做出来的。如今许多东西都明白了，又用他来分析问题，深入理解内核，探索一些未知的东西不得不感慨一下：调试器真是个好东西！
  　　 国人写的涉及系统底层的好书真的很少，以前就觉得毛德操老师的书很值得一读（据说毛德操老师七八十年代就开始钻研unix操作系统，研究操作系统二三十年了）。张老师的文笔很不错，国内书籍的作者中技术又好文笔又不错的真的不多见。
  　　
  　　http://advdbg.org/forums/1718/ShowPost.aspx
•   　　书很厚，但是确实非常不错
  　　
  　　以debug为主线又把整个操作系统（这里特指windows）串了一遍
•   　　这本书我是在看了作者博客上的一些文章以后才去看的,也看到一些骂人的帖子,本来我对国内的技术作者是不抱太大希望的,首先是因为很少有人能钻研进去,其次是缺乏原创精神,再次是写的题材都是国外嚼烂了的东西.站在书店大概看了一下,感觉不错,于是买回来看.优缺点都说说.
  　　
  　　优点是:
  　　1.关于调试方面的专著很少,更谈不上全面,想把这个主题讲清楚本身要涉及太多技术范畴了,很不容易,这也是我对国内技术人员感到明显进步的地方.
  　　2.洋洋洒洒1000余页,基本上对windows下的调试问题已经是巨细靡遗了.字里行间还是很见功力的,足见作者的技术素养非常的好,至少在windows和x86体系内是专家了.
  　　
  　　缺点是
  　　1.太厚了,这是个矛盾,想把一个问题讲全面讲清楚就难免需要篇幅,但是技术人员的时间还蛮紧张的,短时间内通读不是很现实,况且现在所谓的技术人员大多浮在一堆高级语言和框架上,对这个课题深入的部分缺乏兴趣,建议作者出一本精简版的.
  　　2.太专了,调试这个课题在很多平台上都是非常重要的,即便是同样的x86体系也有很多种不同的操作系统,本书用1000多页的篇幅却只是把主题集中在windows上,对于调试这个共性的课题没有扩展开来,抽象出来.这可能和作者的研究领域有关系,如果能有诸如linux.solaris或者mac os这些平台上类似的专著,那么受惠的人群将大大增加.
•   还没看过这本书，求张银奎老师的博客地址