WinDbg应该这么慢吗？

Question

我在试着分析一些小型的撞车事故。我使用的是Windows10Pro Build 1607和WinDbg 10.0.14321.1024。我的符号文件路径设置为

SRV*C:\SymCache*https://msdl.microsoft.com/download/symbols

基本上，每当我加载一个小型.dmp文件(全部都是<1MB的WinDbg文件)时，就需要WinDbg来实际分析它们。我知道第一次跑步可能需要很长时间，但我花了将近12个小时才允许我输入命令。我认为，由于符号是缓存的，重新打开同一个.dmp不会花很长时间。事实并非如此。它加载，几乎立即进入“加载内核符号”，然后再花30分钟打印"BugCheck“行。又过了30分钟了，我还是不能在里面输入命令。

我的电脑有512 GB的SSD，8GB的RAM和一个i5-4590.我觉得不应该这么慢。

我做错了什么？

Answer 1

这是符号服务器非常慢。其他人也注意到了：https://twitter.com/BruceDawson0xB/status/772586358556667904

您的符号路径包含一个本地缓存，因此下次加载的速度应该更快，但是缓存似乎不太有效，我真的不知道为什么(我怀疑下载的符号不是完美匹配的，而且每次都会再次下载)。

我建议将_NT_SYMBOL_PATH (或者任何初始化您的符号路径的方式)修改为SRV*C:\SymCache，即。不要尝试自动下载，只需使用本地缓存的符号即可。图像应该会很快打开。只有在发现缺少符号时才启用符号服务器。

Answer 2

最近，这种抱怨似乎越来越多，我可以在我的电脑上复制它。这不是您的错，而是Internet或Microsoft端的符号服务器的一些问题。

使用Wireshark监视通信量，查看我的磁盘如何填充符号缓存，我可以这样说：

• 一次只下载一个文件。
• 老版本的WinDbg (6.2.9200)也会出现这个问题。
• 这个问题发生在HTTP和HTTPS
• 当发现符号时，传输速度很慢，然后增加。有效传输速率为11 kb/s至20 kb/s (在一条可处理6500 kb/s的线路上)。
• 有相当多的数据包无序，重复的数据包等等，特别是在“查找阶段”，其中还没有下载文件。这样的查找阶段可以轻松地花费8分钟。
• 即使文件已经存在于磁盘上，也会执行“查找阶段”。
• HTTP往返时间(请求响应)为8至9秒

​

​

​

​

​

​

Answer 3

我遇到了同样的问题(非常慢的windbg)，但是加载/重新加载/修复/缓存符号没有帮助。偶然地，我发现当我试图用从寄存器获取的地址打印内存时，这个问题仍然存在，例如

db rax 

经验法则是始终在注册名中使用@。

db @rax 

如果没有此符号，调试器将rax视为符号名，并在某个时候查找它(取决于您加载的符号数量)，最终无法找到它，因此返回到将其视为寄存器名。使用@符号从寄存器中打印内存可以立即工作，即使在内存中加载了大量符号。正如你所看到的，这个问题也是符号相关的，但以另一种方式。