这真让我疯狂。我使用WinDbg作为我的主要调试器。 它用于调试本地服务（WinDbg在本地运行，在同一台机器上调试服务）。 PDB文件存储在本地硬盘驱动器上。 源代码可通过SMB共享访问。
调试以突发方式工作，有时它流畅，大多数时候我一直看到令人难以置信的恼人的“*忙碌*”消息，这几乎每次我执行“跳过”时都会发生。
我有什么想法可以加快速度？
由于
答案 0 :(得分：1)
如果您有许多不合格的断点来跟踪工作区中保存的模块加载事件（通过bu创建），则可能会发生这种情况。
还值得检查网络连接和本地符号缓存大小
答案 1 :(得分：1)
我遇到了完全相同的问题，并且通过调整符号选项可以看到很大的改进。具体来说，SYMOPT_NO_PUBLICS选项似乎是最重要的，但我调整了一些其他相关选项。我做了以下......
.symopt-为0x4 .symopt + 0x100的 .symopt +为0x8000 .symopt-0x10000的
......这是：
-SYMOPT_DEFERRED_LOADS + SYMOPT_NO_UNQUALIFIED_LOADS + SYMOPT_NO_PUBLICS -SYMOPT_AUTO_PUBLICS
毕竟，我的symopt位掩码值为0x80028333，我现在将其用作WinDbg命令行选项，如：
windbg.exe -sflags 0x80028333
我还没有发现这种方法是否有任何缺点。也许在某些情况下使用SYMOPT_NO_PUBLICS导致缺少信息，但到目前为止它对我来说效果很好，而且它肯定更快。
答案 2 :(得分：0)
当打开多个工具窗口（本地人，手表，调用堆栈）时，通常会发生这种情况。如果打开这些窗口，WinDbg将花费周期来使用每个“step-over”命令上的慢符号查找来更新所有窗口。
在这方面，仅使用命令行（ntsd）调试器要快得多。
答案 3 :(得分：0)
如果它正在慢慢从互联网上提取Windows符号文件，请考虑将所有这些文件下载到硬盘驱动器并将WinDbg指向其上的位置。最好将服务的符号文件和源文件放在本地驱动器上。
答案 4 :(得分：0)
要尝试的几件事情：
答案 5 :(得分：0)
而不是使用'step-over'，在下一个命令或甚至硬件断点（使用ba）上设置断点
答案 6 :(得分：0)
当您的符号路径包含大型文件存储时，WinDbg可能需要很长时间才能搜索不存在的符号。您可以通过运行Process Monitor并观察WinDbg正在进行的文件操作，通过用户 eran 建议来诊断此行为。
这对我们的组织来说是一个极端的痛点，但我在这个问题中找到了详细的解决方法：“WinDbg takes extremely long time to loading symbols; is searching every directory in large network UNC symbol store”