常见WinDbg问题及解决方案

Posted 2021-03-18 活着的虫子

当你调试一个程序时，你最不想处理的是调试器不能正常工作。当你试图集中精力跟踪一个bug时，总是会因为次要的问题而被忽略，尤其是当调试器的问题导致你失去一个重新编程或者浪费了大量的时间等待调试器完成它，而调试器知道这需要永远做些什么的时候。

这是我时常会遇到的大量问题，所以我整理了一些常见问题的简短列表，人们很容易就会被这些问题绊倒（以及如何避免或解决它们）。

1. 我正在使用ntsd，无法加载符号或大多数调试器扩展命令（!Command）不工作。
   这通常意味着您启动了操作系统附带的ntsd（在Windows Vista之前），这比调试器包附带的ntsd要老得多。因为它在系统目录中，所以它将在您的可执行搜索路径中。
   要解决此问题，请使用调试器安装目录中的ntsd可执行文件。
2. WinDbg处理模块加载事件需要很长的时间，它在一个CPU上使用最大处理器时间（旋转）。
   如果工作区中保存了许多跟踪模块加载事件（通过bu创建）的非限定断点，则通常会发生这种情况。当您处理的程序中有大量的修饰C++符号时，这个问题尤其明显，例如大量使用STL或其他模板类的程序的调试构建。由于强制立即加载所有模块的符号，非限定断点通常很昂贵，但它们还强制调试器对正在加载的模块中的每个符号（对于每个未解析的断点）取消修饰并执行模式匹配。
   如果允许在默认工作区中保存大量不合格的断点，则无论调试的是哪个程序，都可能使调试器看起来非常慢。
   为了避免被这个问题困扰，不要使用不合格的断点（没有modulename的断点！除非绝对必要。此外，如果您不需要在下次与调试器工作区的调试会话中保存所有断点（默认情况下，bu断点将保留在调试器工作区中，而bp断点在每次调试会话后都会消失），则在保存工作区之前清除所有断点通常是一个好主意。如果您习惯于每次附加到正在运行的进程时都保存工作区，并且您经常使用bu断点，则这会使用户默认工作区变得杂乱无章，如果不小心，可能会很快导致调试器性能非常差。
   您可以使用bc命令删除断点（bc*删除所有断点），但您需要保存工作区以保留更改。如果问题已经到了甚至无法在合理的时间内完成模块加载，以便使用bc*清除保存的断点的程度，则可以删除HKCUSoftwareMicrosoftWindbgWorkspaces注册表项和子项的内容，以使Windbg返回原始状态。这将清除已保存的调试器窗口位置和其他已保存的调试器设置，因此请将其作为最后手段使用。
3. WinDbg处理模块加载事件需要很长的时间，但它不占用很多处理器时间。
   这通常意味着符号路径包括断开的HTTP符号存储链接或断开的UNC符号存储路径。符号路径中的非响应路径将导致任何尝试加载模块符号的操作需要很长时间才能完成，因为网络超时将反复发生。
   使用！sym noise，后跟.reload/f以确定符号路径的哪个部分工作不正常。然后，修复或移除符号路径的冲突部分。
   当调试位于数据包路径中的程序时，也可能会出现此问题，这些程序将数据包发送到符号路径上的某个位置。在这种情况下，我建议的典型解决方法是设置一个空符号路径，附加到有问题的进程，编写一个转储文件，然后从进程分离。然后，恢复正常符号路径并在调试器中打开转储文件，并发出.reload/f命令以强制提前预缓存所有符号。在下游存储缓存中预缓存所有符号后，将符号路径更改为仅引用下游存储缓存位置，而不引用任何UNC或HTTP符号服务器路径，并将调试器附加到包路径中的进程以进行符号服务器访问。
4. WinDbg拒绝为我知道符号服务器有符号的模块加载符号。
   如果WinDbg以前尝试（但失败）下载模块的符号，则可能会出现此问题。dbghelp的symbol服务器支持中似乎存在一个bug，有时会导致部分下载的PDB文件留在下游存储缓存中。如果发生这种情况，以后访问模块符号的尝试将失败，并出现错误，说明找不到模块符号。
   如果打开嘈杂符号加载（！sym noise），通常会给出一个更具描述性的错误。如果您看到有关E_PDB_CORRUPT的投诉，那么您可能是此问题的受害者。指示此问题的调试器输出如下所示：
   

   DBGHELP: c:symbols­
   tdll.pdb­2744327E50A64B24A87BDDCFC7D435A02­
   tdll.pdb – E_PDB_CORRUPT

   如果遇到此问题，只需删除错误消息中命名的.pdb，然后通过.reload/f<modulename>命令重试加载符号。

5. 当我附加到特定进程（如svchost实例）时，WinDbg将挂起并且永远不会返回。
   如果确信工作区中保存的符号路径已断开或模块加载跟踪断点不合格，并且调试器在附加到某个进程时从未返回（或附加到该进程时几乎总是在第一个命令之后挂起），则调试可能位于负责符号加载的代码路径中。
   在调试svchost实例时，此问题尤其常见，因为在各种svchost实例中运行了许多重要但不相关的代码片段，其中一些代码对于网络符号服务器支持的工作至关重要。如果正在调试网络符号服务器支持的关键路径中的进程，并且有一个设置了网络组件的符号路径，则可能导致调试器在第一次尝试加载符号时死锁（永久挂起）。
   一个可能导致这种情况的例子是，如果您正在调试与DNS缓存服务位于同一svchost实例中的代码。在这种情况下，当您尝试加载符号并且符号路径中有HTTP符号服务器链接时，调试器将死锁，因为当它尝试解析符号路径中引用的服务器的主机名时，它将尝试对DNS缓存服务进行RPC调用。因为在调试器恢复进程之前，DNS缓存服务不会响应，并且调试器在从RPC请求获得对DNS缓存服务的响应之前，也不会恢复进程，所以调试会话将无限期挂起。
   请注意，如果只是调试符号服务器存储区的数据包路径中的某些内容，则通常会看到调试器在很长一段时间内变得无响应，但不会完全挂起。这是因为调试器可以处理网络超时（如果有点慢的话）并最终使对网络符号路径的请求失败。但是，如果调试器试图向正在调试的进程发出某种IPC请求，并且IPC请求没有任何内置超时（大多数本地IPC机制没有），那么调试器会话将永远丢失。
   这个问题的解决方法类似于我通常建议用户如何处理模块加载缓慢或符号服务器访问失败的问题，该问题是使用符号路径中引用的符号服务器的数据包路径中的程序解决的。具体来说，可以通过从具有空符号路径的调试器实例中创建进程转储，然后分离并打开具有完整符号路径的转储，并强制下载所有符号，来预缓存进程的所有符号。然后，使用符号路径在实时进程上启动调试会话，该符号路径仅引用符号下载到的本地下游存储，以防止发生任何危险的网络访问。
   另一个让你陷入这种调试器死锁问题的常见方法是，当你调试一个已经将某些东西放入剪贴板的程序时，使用剪贴板粘贴到WinDbg中。这会导致类似的死锁，因为WinDbg可能会在对剪贴板所有者的DDE请求中被阻止，而剪贴板所有者将永远不会由于被调试而响应。在这种情况下，解决方法只是在将文本复制或粘贴到WinDbg中或从WinDbg中复制或粘贴文本时要小心。
6. 使用-Remote或.server进行的远程调试不稳定，或在一段时间后停止正常工作。
   如果会话中的所有调试器运行的调试器版本不同，则可能会发生这种情况。
   确保远程调试方案中的所有对等方都使用（相同的）最新调试器版本。如果将调试器版本与-remote混合并匹配，在我的经验中，事情往往会以奇怪且难以诊断的方式出现（对于调试器远程处理协议的向后或向前兼容性，似乎没有太多得体的支持）。
   另外，在Windows2000上，调试器包的几个最新版本在远程调试模式下根本不起作用。据我所知，这是在最新版本中修复的。

一旦你知道要寻找什么，这些问题中的大多数都很容易解决或避免（尽管如果你被发现不知道的话，这些问题肯定会耗费很多时间，因为我自己在学习这些“陷阱”的过程中也做了这些事情）。

如果您遇到一个奇怪的WinDbg问题，您也不应该羞于调试出现故障的调试器实例本身。通常，对有问题的调试器实例中的所有线程进行堆栈跟踪就足以让您了解什么样的问题阻碍了工作（请记住，Microsoft公共符号服务器有调试器二进制文件和操作系统二进制文件的符号）。