调试准则
更新：2007 年 11 月
下列准则提供几项调试代码的技术。
必需的操作
了解如何使用调试工具。
您必须了解和掌握调试工具。有关更多信息，请参见 使用 Visual Studio 进行调试。
了解在哪里存档您的符号。
必须在符号服务器上存档每个产品的符号。您只需知道在哪里可以找到这些服务器。有关更多信息，请参见 MSDN Library（MSDN 中文网站技术资源库） 中的“How to Use the Microsoft Symbol Server”（如何使用 Microsoft Symbol Server）。
研究并解决使进程挂起的 bug。
对于用户，停止响应（挂起）的应用程序就像崩溃那样糟糕。无论是停止响应还是崩溃，用户都会丢失已做的工作而必须从头开始。但是，大家一直认为研究和解决挂起要困难的多。而现在，对于大多数进程挂起，情况已经不再像原先那样了。使用最新的工具和技术可以解决这些问题。有关更多信息，请参见 MSDN Library（MSDN 中文网站技术资源库） 中的“How to Troubleshoot Program Faults with Dr. Watson”（如何使用 Dr. Watson 对程序错误进行疑难解答）。
了解如何调试小型转储。
如果不利用附带的调试器，大多数测试人员和客户将会使您的代码崩溃。如果您无法容易地再现问题，则您所能做的就是使用一个小型转储。了解通过使用小型转储进行调试非常重要。有关更多信息，请参见 MSDN Library（MSDN 中文网站技术资源库） 中的“Minidump Files”（小型转储文件）。
了解如何恢复损坏的堆栈。
恢复损坏的堆栈很复杂，但恢复它非常重要，因为有许多实际故障都具有看起来无法理解的堆栈。有关更多信息，请参见 MSDN Library（MSDN 中文网站技术资源库） 中的“Troubleshooting Common Problems with Applications: Debugging in the Real World”（对应用程序的常见问题进行疑难解答：实际调试）。
应避免的行为
假设测试会找到所有 bug。
测试将永远无法找到所有 bug。这是不可能的。代码很复杂。即使测试可以找到所有 bug，您也不可能有时间修复所有这些 bug。正确的做法是对您的产品进行设计，使得 bug 不会从一开始就存在于产品中。这样可以避免以后修复问题的麻烦。您必须对您代码的质量负责。测试小组只是验证您代码的质量。不要依赖测试人员来清除您的错误。
建议
了解如何调试多线程应用程序。
向程序引入线程会导致程序以新的形式失败。随着线程数目的增加，您在单线程环境中所做的帮助调试应用程序的任何工作都变得更加重要。例如，您可能无法始终在错误发生时就捕获错误。您通常会稍后捕获错误，也许是在另一个线程中。在这些情况下，您甚至不能重新回到调用堆栈以查找问题；该错误在具有另一个堆栈的另一个线程中。尽可能地具有前瞻性在总体上有助于调试进程。
了解如何执行远程调试。
当您想要调试在另一个计算机上发生的问题，同时要继续使用您自己的计算机时，可以进行远程调试。当代码段在自己的计算机上运行良好，而在另一个系统中崩溃时，开发人员通常会进行远程调试。他们可能希望无需坐到其他计算机前，即可在其他系统中对其进行远程调试。有关更多信息，请参见安装远程调试。
了解如何在处于活动状态的服务器上进行调试。
当您尝试在客户正在访问的处于活动状态的服务器上调试代码时，调试过程会有所不同。随着针对 Web 编写的代码越来越多，这种现象会变得越来越普遍。有关更多信息，请参见 MSDN Library（MSDN 中文网站技术资源库） 中的“Troubleshooting Common Problems with Applications: Debugging in the Real World”（对应用程序的常见问题进行疑难解答：实际调试）。
对所有 bug 修复做出注释。
修复 bug 时，在代码中包括版本号、bug ID 和您的别名。某个用户在以后查看该代码时，如果有关于修复的问题，可以与您联系以获取相关信息。
检查所有 bug 修复。
您应该检查所有代码修复。至少让另一个人来检查您的代码 - 让其他同事检查。
在签入之前验证细微的 bug 修复。
避免重复修复同一个 bug。使用生成来验证修复（尤其是细微 bug 的修复）是否正确。
使用测试发布文档来报告所有 bug 修复。
通过将您的所有 bug 修复记录在测试发布文档 (TRD) 中并将其通过电子邮件发送给测试小组，与测试小组协同工作。
使用符号服务器来索引和存档您的产品符号。
通过允许符号服务器索引和存档您的产品符号，您可以快速而轻松地从任何系统（包括客户系统）进行调试。
不建议采取的行为
在不通知他人的情况下修复他们的 bug。
研究并尝试修复他人的 bug 是很好的做法。您可以更好地了解代码，并且您在为他人提供支持工作。您唯一不该做的是在不通知代码所有者的情况下签入代码修复。
在没有在同一环境中的相同版本中进行尝试的情况下，就将 bug 解析为“不会再重现”。
您必须回滚到发现 bug 的产品版本。不要进行这样的假设：如果 bug 没有在产品的当前版本上引发，则表示该 bug 一定已经修复。事实可能并非如此。代码可能已经改变，因此目前只是隐藏了 bug。如果您持续研究某个 bug，直到它引发，您实际可能会发现问题的根本原因并修复该问题，使得该 bug 不会在任何计算机上再次发生。