Windows高端调试（Advanced Windows Debugging）（前言 - 1）

译者：周林

时间：2008年4月4日

 

前言

      不久前，我们还在回忆工作中所遭遇的一个相当棘手的问题。质量保证团队对我们的产品进行了压力测试，每隔4到5天，就会出现崩溃问题。诚然，对于这个崩溃问题，我们在能力范围之内尝试了所有的调试方法，也做了相当程度的代码复查工作，但是很可惜还是未能找出问题发生的根本原因。几个星期之后，我们开始寻求其他的办法。在一次闲聊中，有人提到了一个名为gflags的工具。我们之前从未听说过这个工具，所以我们开始着手学习这个工具，以求利用它来找到那个崩溃问题的根本原因。很不幸，这个学习过程相当艰难。首先，找出对我们有用的信息就是一个巨大的挑战：该工具附带的参考文档实在太多，以致于我们很难找到着手之处。我们很快意识到，如果不找人帮忙，利用这个工具来解决那个崩溃问题对我们来说希望渺茫。很自然的，我们决定去问那个向我们提到该工具的人。他给我们简要介绍了这个工具，更重要的是，他还告诉了我们使用这个工具的资深人士。随后的交谈便是一系列冗长的指导性的说明了，该工具背后的基本思想也慢慢在我们的脑海中形成。

     我们最后找到崩溃的根本原因了吗？当然。借助于该工具，运行压力测试时，问题很快被精确定位。仅仅一个小时的代码复查便找到了引起崩溃的代码的位置并修正了它。如果我们之前便知道有这个工具，并且一开始就知道如何使用它的话，我们可以节省数个星期的时间。从那时起，我们便花大量的时间来加深对这些工具的理解，并且学习如何使用它们来帮我们排错。

    多年来，微软的调试器和工具已经慢慢成熟，变得强大起来。这些工具在节省排错时间方面的能力令人难以置信。之所以用“难以置信”这个词是因为，多年后的今天，这些本机调试器和工具还很大程度上不为开发人员所知。这些人还认为这些工具的学习过程还和多年前一样痛苦。能与微软公司的工程师（其中的一些人就是这些工具的发明者）一起共事，我们感到非常幸运。如果不是这样的话，很多有希望的开发人员将不能受益于这些工具而穷途末路。缺乏相应的学习资料，本来是件不幸的事情，但是客观上为本书的出现提供了机会。让开发人员获得所需的调试知识，关键在于全面解释调试工具的输入和输出以及调试过程。你手中的这本书便是这样的一把钥匙，它费时三年写作而成，浓缩了超过15年的调试经验。

    我们希望你能喜欢读这本书，就像我们喜欢写这本书一样。这本书将打开通往一个高效排错与调试的神奇世界之门。知道如何使用这本书中讲到的工具和技术，是一个计算机科学家工作中的关键一环，它们将帮助你非常高效地排除一些相当棘手的软件问题。

 

这本书适合那些人阅读？

   对于这个问题最简单的回答是：对Windows内部运作有强烈兴趣的，与软件开发有关系的任何人。本书的谈及的技术层面也许会让你认为本书是写给高级系统工程师看的，这种想法其实是错误的。本书的目标之一就是“消除迷信”。出于很多原因，许多软件工程师认为他们所开发的软件和操作系统之间有种神奇的纽带。当问题出现，要求对操作系统的组件（例如RPC/COM或者Windows堆管理器）进行分析的时候，这种迷信的先入为主的观点会阻碍他们对Windows的深入剖析以获得更多的信息来帮助他们解决问题。为了有效地使用本书，你必须学会破除这种迷信观点。Windows的核心组件应该视为你所开发的产品的一部分。毕竟，这些组件也是代码——只不过这些代码是别人写的而已。如果你矫正了观点，你将踏出精通Windows调试之旅的第一步。

 

软件开发工程师

   从底层的系统工程师到上层的快速应用程序开发工程师，都可以从本书受益。无论你是喜欢用汇编语言还是.NET框架编写基于Windows的软件，都有很多关于Windows调试的工具和技术的资料需要学习。多年来，我们与上层的快速应用程序开发工程师交流过，他们声称他们没有必要学习这些底层的知识。毕竟，上层的编码之美在于将底层的复杂性通过抽象的方式对快速应用开发工程师隐藏。排开这一点，我们不同意上面那些快速应用开发工程师的说法。虽然抽象编程使得开发者不用再专注于底层细节，但这并不表示没有必要去了解抽象层的工作方式。理由很简单：你打交道的就是这个抽象层。在不该使用抽象的设计中使用抽象会导致你的软件发生一系列的问题；在这种情况下，对抽象层的深刻理解与否将决定你的产品能按时交付还是得延期好几个月。

   另一个需要精通Windows调试器和工具的关键因素是和已经交付用户使用的产品的调试有关的。虽然在产品发布之前，我们会尽所有的力量消除bug，但是我们都知道总有bug会是漏网之鱼。当这些漏网的bug在产品已交付用户使用的时候暴露出来，这时来修正它们是件相当头痛的事情。遭遇这些bug的用户对于停机和配置更改是很敏感的，这使得我们不可能在用户的机器上安装复杂的调试器包。另一方面，Windows的调试工具可以在不安装任何调试器包，不进行任何配置更改的情况下，对用户的机器进行在线调试。简言之，用户的机器在调试的过程中可以不受影响地正常工作。

 

质量保证工程师

  和软件开发工程师一样，质量保证工程师在日常的工作中也可以从这本书受益。质量保证工程师的典型测试就是给待测组件进行电池测试。在测试的过程中，会有一定数目的bug暴露出来。无论这些bug是关于内存损坏，资源泄露还是异常终止的，了解在测试过程中可以利用什么工具可以大大减少我们对错误源的分析时间。例如，假设质量保证工程师进行一个信用卡认证服务的压力测试。该服务的目标之一是能承受一个星期持续不断的并发的用户请求的访问。第六天的时候，对于所有的用户请求服务都报告错误。这时，负责开发该服务的所有的软件开发工程师都被召集起来分析该问题产生的原因。他们不用多久就可以断定该服务是由于微小的内存泄露经过长时间的积累而耗尽了内存。但是经过了六天的内存泄露的积累，要找出泄露源是一个相当大的挑战，这会耗费他们数日来调试和代码复查。如果在测试中使用了正确的工具，他们分析泄露的时间将大大缩减。

 

产品支持工程师

  与质量保证工程师使用Windows调试器和工具来有效分析错误源类似，产品支持工程师也可以从中受益。产品支持工程师在日常的工作中也会面临和质量保证工程师和软件开发工程师同样的问题。但是最关键的不同在于，产品支持工程师会受工作环境的限制。这些限制包括：没有足够的权限访问出现问题的服务器，只有有限的时间来排错，有限的权限来访问客户的源代码等等。

   本书将提供大量的信息来帮助质量保证工程师来对付这些棘手的问题。懂得如何在尽可能不停机和尽可能少的系统配置更改的情况下，来调试客户的问题，将有助于产品支持工程师高效而不干扰客户地收集所需的数据来定位错误源。

 

有志者事竟成

  毋庸置疑，本书的内容有相当程度的技术高度。阅读本书你需要一些关于Windows内部运行机理的知识背景。对于任何一本技术书籍，一定程度的知识背景是必需的。

 

好奇心和求知欲

  当写这本书的时候，我们意识到我们在书中所深入阐述的Windows的某些部分的工作方式被很多人认为是理所当然的。诚然，我们知道这些部分以特定的某种方式工作，但是我们的确不知道是什么驱使它们这样工作的。我们可以简单接受它们就是这样工作的事实，但是好奇心总会驱使我们寻根究底。我们花了大量的时间去研究这些部分，并尝试将这些研究结果串接起来。最终我们更加深刻地理解了Windows，这样的结果反过来可以使我们更加有效地调试问题。

  学习任何东西必须有求知欲。基于你的知识背景，本书的某些高级主题对你可能有些困难。如果你克服了这些困难，你将完全掌握和理解本书的内容。

  如果你具备了好奇心和求知欲这两个条件，你将可以开始你的Windows调试专家成长之路了。