SymbolSource服务器问题

时间:2014-04-15 23:03:17

标签: .net debugging windbg symbol-server

我们正在为我们的开发团队设置一个本地SymbolSource服务器。我们遵循了a nice article written on SymbolSource server。我们使用TeamCity进行构建。对于每个构建,使用.symbols.nupkg命令将nuget push推送到本地SymbolSource,并将nuget包推送到本地NuGet服务器。

我们遇到的问题:

对于nuget包MyPackage.1.1.0,如果我们将它推送到符号服务器,它会创建哈希,这就是它如何关联每个版本文件夹以加载.pdb文件和.cs文件。 (这是我的理解。如果我错了,请纠正我)。

在Visual Studio中设置符号服务器配置后,我们尝试调试项目。我们所经历的是,Visual Studio生成的用于加载符号的哈希与在符号服务器上使用nuget push注册时生成的哈希完全不同,该哈希在404中结束。(请参阅带有fiddler状态代码的附件。 )如果我们在Symbol服务器上使用相同的哈希手动创建一个文件夹,我们会得到所需的结果,即步入代码。

为什么同一版本的dll / nuget文件有两个不同的哈希值?

Two different guid's generated Fiddler output

1 个答案:

答案 0 :(得分:2)

您获得的值不是哈希值(因为它们不是文件内容哈希值),它们是GUIDs。每个DLL - PDB对在构建时都会分配GUID。 DLL的每个构建都有一个不同的 GUID,即使它们是使用完全相同的源代码构建的!这意味着从符号服务器获取PDB的唯一方法是使用完全相同的DLL。您获得完全不同的GUID这一事实向我表明您没有使用相同的DLL。因此,我在这种情况下可以提出的情况是:

  • 您的符号nuget包与您的普通nuget包具有不同的dll。如果同时生成两者,这似乎不太可能,但是如果你不止一次地构建包和二进制文件,这是可能的。
  • 您没有使用已将符号包注册到您的符号服务器的nuget包中的dll
  • 您没有使用nuget包中的dll

“修复”的工作原因是因为Visual Studio显然只使用GUID创建符号搜索路径,但在加载时不检查PDB GUID。换句话说,它(假设)假设符号服务器将符号放在正确的位置。

解决问题的最佳方法是找出从哪里获取不同的DLL。您可以使用dumpbin实用程序通过

找出哪个PDB链接到哪个DLL
dumpbin.exe /headers mypackage.dll

这应该产生一个输出,其中包含PDB文件的路径和(!)链接DLL和PDB的GUID。如果将计算机上的DLL的GUID和时间戳与符号服务器上的DLL / PDB中的时间戳进行比较,您应该能够找出出错的地方。

相关问题