WinDbg 加载符号需要很长时间；正在搜索大型网络 UNC 符号存储中的每个目录

Posted 2023-02-24

【中文标题】WinDbg 加载符号需要很长时间；正在搜索大型网络 UNC 符号存储中的每个目录

【英文标题】：WinDbg takes extremely long time to loading symbols; is searching every directory in large network UNC symbol store

【发布时间】：2015-08-20 12:45:32

【问题描述】：

在使用WinDbg 调试故障转储时，我花了几天时间尝试加快符号加载，但我无法解决某个特定问题。

问题在于，当转储中的模块符号不存在于任何可访问的符号存储或符号服务器位置（例如，它是没有可用符号的第三方模块）时，WinDbg 将花费数小时寻找它们。

我已正确设置符号路径以正确设置搜索顺序和缓存目录：

.sympath cache*C:\SymbolCache1;\\our.corp\SymbolStore;SRV*C:\SymbolCache2*http://msdl.microsoft.com/download/symbols

与!sym noisy 和.reload /f 一起运行我可以看到：

SYMSRV:  Notifies the client application that a proxy has been detected. 
SYMSRV:  Connecting to the Server: http://msdl.microsoft.com/download/symbols. 
SYMSRV:  Successfully connected to the Server. 
SYMSRV:  Sending the information request to the server. 
SYMSRV:  Successfully sent the information request to the server. 
SYMSRV:  Waiting for the server to respond to a request. 
SYMSRV:  Successfully received a response from the server. 
SYMSRV:  Closing the connection to the Server. 
SYMSRV:  Successfully closed the connection to the Server. 
SYMSRV:  c:\SymbolCache1\Some3rdParty.dll\0060D200cd1000\Some3rdParty.dll not found 
SYMSRV:  c:\SymbolCache2\Some3rdParty.dll\0060D200cd1000\Some3rdParty.dll not found 
SYMSRV:  http://msdl.microsoft.com/download/symbols/Some3rdParty.dll/0060D200cd1000/Some3rdParty.dll not found 
<---- !!!! hanging here with *BUSY* showing in WinDbg

通过在挂起的位置运行 Process Monitor，我可以看到 WinDbg 正在搜索我们巨大的网络符号存储中的每个目录（ \our.corp\SymbolStore) 寻找符号，即使是在明显不相关的模块的目录中。

奇怪的是，在 WinDbg 中，您可以看到它提取了模块的时间戳 (0060D200cd1000)，并使用它来查看本地目录和 MS 符号服务器中的预期位置。我不明白为什么它要对我们的（大量）网络符号存储进行全面扫描。也许它处理 UNC 路径的方式有什么独特之处？

每个符号的搜索可能需要 15 分钟或更长时间，如果转储中缺少许多符号，这可能会导致 !analyze -v 花费数小时（如果您使用 WinDbg 的 Visual Studio 集成，则会导致挂起加载故障转储时立即发生，因为出于某种原因，尽管有 .symopt 设置，但集成会尝试立即加载所有符号）。

如果您尝试为不存在的虚构模块名称加载符号，则此问题也很容易重现，例如.reload /f bogus.dll。

这是我的 WinDbg .symopt 设置：

0:000> .symopt
Symbol options are 0x30337:
  0x00000001 - SYMOPT_CASE_INSENSITIVE
  0x00000002 - SYMOPT_UNDNAME
  0x00000004 - SYMOPT_DEFERRED_LOADS
  0x00000010 - SYMOPT_LOAD_LINES
  0x00000020 - SYMOPT_OMAP_FIND_NEAREST
  0x00000100 - SYMOPT_NO_UNQUALIFIED_LOADS
  0x00000200 - SYMOPT_FAIL_CRITICAL_ERRORS
  0x00010000 - SYMOPT_AUTO_PUBLICS
  0x00020000 - SYMOPT_NO_IMAGE_SEARCH

我看了一遍，认为必须有一些标志来控制它，但我似乎找不到它。

几件事：

这不是网络速度或缺少本地符号缓存的问题。该问题仅出现在无法找到的符号上，并且仅出现在 UNC 符号存储中（例如，与 Microsoft 符号服务器无关） 我已经尝试过 SYMOPT_NO_PUBLICS 而不是 SYMOPT_AUTO_PUBLICS 我已经使用sympath 命令验证了我的符号路径是我所期望的。我也尝试过使用 _NT_SYMBOL_PATH 环境变量。 我知道我可以通过配置文件排除某些符号，但这不是一个可行的解决方案，因为有时预先不知道丢失的符号名称 我在 Internet 上看到其他人遇到了同样的问题，并在 Microsoft 论坛上以“Poor WinDbg 6.11.1.404 performance when it is pointed to a large symbol cache”为标题的帖子中提到了它，但没有得到任何帮助。

【参考方案1】：

不应该是这样的：

.sympath cache*C:\SymbolCache1;SRV*\\our.corp\SymbolStore;SRV*C:\SymbolCache2*http://msdl.microsoft.com/download/symbols  

也就是说，通过列出 \\our.corp\SymbolStore 而不列出 SRV*，您是在告诉 dbghelp 在这个非结构化目录中查找符号。如果您使用 SRV* 语法，那么您就是在告诉 dbghelp 让 symsrv 以一种非常具体和结构化的方式查看该目录。

symsrv.dll 可以有效地搜索 Microsoft 的符号服务器，如果您使用 SRV* 告诉它这样做，它也可以有效地搜索您的符号服务器。

【讨论】：

我已经尝试过这种方法，它也解决了问题——并且不需要设置 SymProxy，这是一个额外的好处。也许我错过了它，但据我所知Symbol path for Windows Debuggers 上的 MS 文档没有提供在非 http 符号服务器上使用 SRV* 的示例。如果他们可以改进文档以包含此内容，那就太好了。无论如何，感谢您的澄清！

我猜 SRV* 是部落知识。在我自己关于符号服务器的博客文章中，我使用 SRV*，但从未真正解释它的含义。我可能需要更新它。 randomascii.wordpress.com/2013/03/09/symbols-the-microsoft-way

只是为了结束循环，截至今天看来，布鲁斯确实已经用这些信息更新了他上述的博客文章。

【参考方案2】：

我终于找到了一个不满意但非常好的解决方案：设置SymProxy。

这让我可以从我的符号路径中删除 UNC 共享，并将其替换为对 SymProxy 作为我的 http 符号服务器的引用。

.sympath SRV*C:\SymbolCache*http://somemachine.our.corp/Symbols

代理本身仍然在 UNC 共享中搜索，但 WinDbg 不能再搜索网络目录——相反，它必须将有关它想要的符号的信息传递给 SymProxy，SymProxy 只查找 UNC 上的一个位置分享而不是进行详尽的搜索。

这并不能解释为什么 WinDbg 会搜索整个 UNC 共享，但它确实解决了 WinDbg 在搜索符号时挂起的问题。终于符号加载又快了！

安装 SymProxy 的另一个优点是您可以将其设置为从多个符号位置提取。例如，您可以让它连接到本地组织的符号存储以及 Microsoft 符号服务器。然后，您的开发人员可以将其符号路径设置为仅引用 SymProxy 而不是多个符号位置。