如果您调试了一段时间的崩溃转储，那么您可能遇到了这样的情况：调试器提供的初始转储上下文对应于在处理初始异常时发生的第二个异常，该异常可能更接近您正在调查的问题中的原始基础问题。
这可能很烦人，因为“.ecxr”命令将指向次要故障异常的位置，而不是原始异常上下文本身。然而，在大多数情况下，原始的、主要的异常上下文仍然在堆栈上；人们只需要知道如何找到它。

有两种方法可以解决这个问题：

当你调试一个程序时，你最不想处理的是调试器不能正常工作。当你试图集中精力跟踪一个bug时，总是会因为次要的问题而被忽略，尤其是当调试器的问题导致你失去一个重新编程或者浪费了大量的时间等待调试器完成它，而调试器知道这需要永远做些什么的时候。
这是我时常会遇到的大量问题，所以我整理了一些常见问题的简短列表，人们很容易就会被这些问题绊倒（以及如何避免或解决它们）。

1. 我正在使用ntsd，无法加载符号或大多数调试器扩展命令(!command）不工作。这通常意味着您启动了操作系统附带的ntsd（在Windows Vista之前），这比调试器包附带的ntsd要老得多。因为它在系统目录中，所以它将在您的可执行搜索路径中。要解决此问题，请使用调试器安装目录中的ntsd可执行文件。
2. WinDbg处理模块加载事件需要很长的时间，它在一个CPU上使用最大处理器时间（旋转）。如果工作区中保存了许多跟踪模块加载事件（通过bu创建）的非限定断点，则通常会发生这种情况。当您处理的程序中有大量的修饰C++符号时，这个问题尤其明显，例如大量使用STL或其他模板类的程序的调试构建。由于强制立即加载所有模块的符号，非限定断点通常很昂贵，但它们还强制调试器对正在加载的模块中的每个符号（对于每个未解析的断点）取消修饰并执行模式匹配。
   如果允许在默认工作区中保存大量不合格的断点，则无论调试的是哪个程序，都可能使调试器看起来非常慢。
   为了避免被这个问题困扰，不要使用不合格的断点（没有modulename的断点！除非绝对必要。此外，如果您不需要在下次与调试器工作区的调试会话中保存所有断点（默认情况下，bu断点将保留在调试器工作区中，而bp断点在每次调试会话后都会消失），则在保存工作区之前清除所有断点通常是一个好主意。如果您习惯于每次附加到正在运行的进程时都保存工作区，并且您经常使用bu断点，则这会使用户默认工作区变得杂乱无章，如果不小心，可能会很快导致调试器性能非常差。
   您可以使用bc命令删除断点（bc*删除所有断点），但您需要保存工作区以保留更改。如果问题已经到了甚至无法在合理的时间内完成模块加载，以便使用bc*清除保存的断点的程度，则可以删除HKCU\Software\Microsoft\Windbg\Workspaces注册表项和子项的内容，以使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­\ntdll.pdb­\2744327E50A64B24A87BDDCFC7D435A02­\ntdll.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、ntsd、cdb、kd和其他任何使用DbgEng打开转储文件的工具都有一个鲜为人知的特性。
事实证明，使用DbgEng提供的任何功能，在任何可以打开转储文件（用户转储、内核转储等）的地方，都可以打开PE映像（.exe/.dll/.sys/etc），并让调试器将其视为只包含所选PE映像内容的转储。
这实际上是一个相对有用的特性。当您将PE映像作为转储文件打开时，调试器将其映射为映像，就好像它是作为可执行代码加载到内存中一样（尽管它实际上不运行任何代码，但只是将其映射为可执行文件而不是数据文件）。这将获得exe/dll/sys/other PE文件的内存表示形式，就好像您正在调试加载有问题图像的实时进程（或转储）。
与转储调试会话一样，这本质上是一个只读会话；您不能真正修改任何内容，因为没有要控制的目标。此外，也没有真正的寄存器上下文（或堆栈或堆），尽管初始化和零填充的全局变量以及属于该模块的可执行代码将在内存中。（在这种情况下，模块的首选映像库用于将请求的PE模块建立在为调试会话构造的虚拟地址空间中。）
加载完目标后，您可以执行通常对转储执行的大部分操作，只要检查符号并分解目标即可。如果您需要一个具有符号支持的反汇编程序，并且不能启动一个进程或什么不包含PE映像，那么这个特殊的技巧是一个功能更全面的反汇编程序的quick-n-dirty替换。
注意，在转储模式下打开PE映像的一个副作用是符号服务器用于检索二进制文件（这可能看起来有点奇怪，直到您考虑到对于转储文件，通常情况是您没有将整个二进制文件保存在内存中；只有足够的头信息从符号服务器检索二进制文件）。因此，在尝试此特殊技巧之前，请确保您的符号路径设置正确。

这是一个很常见的问题，我们几乎总是遇到。想象一下这样一种情况，我们从某个地方得到一个内存转储，想看看在那里运行的是什么操作系统，安装了什么SP。。为此，有一个非常简单的命令。

0:000>vertarget
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 6.1.7601.24475 (win7sp1_ldr.190516-0600)
Machine Name:
Debug session time: Fri Dec  6 09:36:00.000 2019 (UTC + 8:00)
System Uptime: 0 days 0:51:15.649
Process Uptime: 0 days 0:00:41.000
  Kernel time: 0 days 0:00:05.000
  User time: 0 days 0:00:13.000

我发现在代码中使用win32api时，需要多次监视最后一个win32错误！（在每次使用API后调用GetLastError（）是不可行的解决方案！）.. 在Visual Studio中，它们提供了一个非常好的小特性。你可以在“监视”窗口中写入@err,hr

同样，您可以使用另一个伪寄存器@eax来监视函数返回值！（如果您正在查看某些Win32 API的返回值，也可以执行@eax，hr来查找整数后面的文本消息。）