WinDbg需要很长时间才能加载符号;正在搜索大型网络UNC符号存储中的每个目录 [英] WinDbg takes extremely long time to loading symbols; is searching every directory in large network UNC symbol store

问题描述

在使用 WinDbg ，我无法逾越一个特定的问题。

I've spent several days trying to speed up loading of symbols when debugging crash dumps using WinDbg, and I'm unable to get past a particular problem.

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

The issue is that when symbols for a module in the dump doesn't exist in any accessible symbol store or symbol server location (e.g. it's a third-party modules without available symbols), WinDbg will spend literally hours looking for them.

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

I've set up my symbol path correctly to properly set the search order and the cache directories:

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

运行与！sym嘈杂和 .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）中寻找符号，甚至在明确无关的模块的目录中。

By running Process Monitor at the point in which it's hanging, I can see that WinDbg is searching what appears to be every directory in our giant network symbol store (\our.corp\SymbolStore) looking for symbols, even in directories for modules that are clearly unrelated.

有趣的是，在WinDbg中，您可以看到它提取了模块的时间戳（0060D200cd1000），并且正在使用它来查看本地目录中的预期位置， MS符号服务器。我不知道为什么它正在对我们的（大规模）网络符号商店进行全面扫描。也许有什么独特的关于它如何对待UNC路径？

What's weird is that in WinDbg you can see that it's extracted the timestamp of the module (0060D200cd1000) and is using that to look in the expected location in local directories and the MS symbol server. I can't figure out why it's doing a full scan of our (massive) network symbol store. Perhaps there's something unique about how it treats UNC paths?

此搜索可能需要15分钟或更多的每个符号，如果转储有许多缺失的符号，这可能会导致一个！analyze -v 需要几个小时（如果您使用的是WinDbg的Visual Studio集成，则会在加载崩溃转储时立即发生挂起，因为某些尽管 .symopt 设置），集成尝试加载所有符号的原因。

This search can take 15 minutes or more per symbol, and if the dump has many missing symbols this can cause a !analyze -v to take hours (if you're using the Visual Studio integration of WinDbg, it causes the hang to occur as soon as you load a crash dump, since for some reason that integration tries to load all symbols immediately despite .symopt settings).

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

This problem is also easily reproducible if you try to load symbols for a non-existent made-up module name, e.g. .reload /f bogus.dll.

以下是我的WinDbg .symopt设置：

Here's my WinDbg .symopt settings:

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

我一直在想，必须有一些标志来控制，但我似乎找不到。

I've looked all over thinking that there must be some flag to control this, but I can't seem to find it.

几件事：

• 这不是网络速度或缺少本地符号缓存。只有使用UNC符号存储（例如不与Microsoft符号服务器）相符的符号才会出现此问题。


• 我已经尝试过SYMOPT_NO_PUBLICS而不是SYMOPT_AUTO_PUBLICS


• 我已经使用 sympath 命令验证了我的符号路径是我期望的。我也尝试使用 _NT_SYMBOL_PATH 环境变量。


• 我知道我可以通过配置文件排除某些符号，但是这不是一个可行的解决方案，因为有时丢失的符号名称不是提前知道


• 我已经看到互联网上的其他人有同样的问题，并在Microsoft论坛上提到一篇标题为当WinDbg 6.11.1.404的性能指向一个大的符号高速缓存但是没有收到

• This is not an issue with network speed or lack of local symbol cache. The issue only occurs with symbols that cannot be found, and only with the UNC symbol store (e.g. not with the Microsoft symbol server)
• I've already tried SYMOPT_NO_PUBLICS instead of SYMOPT_AUTO_PUBLICS
• I've verified that my symbol path is what I expect it to be, using the sympath command. I've also tried using the _NT_SYMBOL_PATH environment variable instead.
• I know that I can exclude certain symbols via a configuration file, but this isn't a workable solution because sometimes the missing symbol name is not known in advance
• I've seen someone else on the internet had this same issue and mentioned it on a Microsoft forum in a post titled "Poor WinDbg 6.11.1.404 performance when it is pointed to a large symbol cache" but received no help.

推荐答案

不应该是：

.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，以非常具体和结构化的方式查看该目录。

That is, by listing \\our.corp\SymbolStore without SRV* you are telling dbghelp to look in this unstructured directory for symbols. If you use the SRV* syntax then you are telling dbghelp to get symsrv to look in that directory in a very specific and structured way.

symsrv.dll可以搜索Microsoft的符号服务器有效，并且可以有效地搜索您的服务，如果您通过 SRV * 来表示这一点。

symsrv.dll can search Microsoft's symbol server efficiently, and it can search yours efficiently, if you tell it to do so with SRV*.

这篇关于WinDbg需要很长时间才能加载符号;正在搜索大型网络UNC符号存储中的每个目录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！