我试图弄清楚 Microsoft 符号本地缓存目录使用什么散列算法。

例如，本地缓存可以如下所示

文件与其调试数据库之间似乎存在某种对应关系。除此之外，我无法弄清楚这些（大概）十六进制字符串文件夹的名称是如何生成的。

其中一些是 9 位数字，一些是 13 位数字，还有一些是 33 位数字。它看起来像一个实际的活动文件（由于某种原因存储在符号缓存中）具有 13 位哈希，而其（几乎相似）调试数据库获得 9 位哈希。一些调试数据库得到一个 13 位的哈希值；无法弄清楚是什么让这些特别，尽管它们没有相应的实时文件。

我已经尝试使用我所知道的每种散列算法（其中 39 个）对文件进行散列，并且没有以任何方式匹配（直接向上、反向、交替 endian'd 等）

有任何想法吗？

更新 我想我终于找到了。从符号存储格式：

SymStore 使用文件系统本身作为数据库。它创建了一个大型目录树，目录名称基于符号文件时间戳、签名、年龄和其他数据等内容。

编辑 当，不幸的是它只提到目录名称是从各个方面派生的（我猜不是一个哈希），但没有确切说明如何。搜索仍在继续…… :-(

我有一个 AssemblyVersion 为 1.0.0.0 的类库，即使它更新（SharePoint ...）也必须保留它。

所以我使用 AssemblyFileVersion 作为“真实”版本。

现在，我想设置一个符号服务器，我想知道是否真的可以为同一个 AssemblyVersion 拥有多个 PDB 并让它自动工作？

PublicKeyToken 也始终相同，因此无法区分。

我有一个解决方案，它是从命令行使用 Visual Studio 2010 构建的。构建后，将 symstore调用 Debugging Tools for Windows 将 PDB 和二进制文件发布到网络文件夹，然后将其用作符号存储。

我知道还有一个源服务器，我可以将它与符号存储一起使用来保存源文件。如何将源文件添加到该符号存储中？我看到调试工具中有一个srcsrv目录，但我找不到使用这些工具在现有源代码控制系统之外创建源服务器系统的方法

我正在尝试为我的组织及其各种产品设置一个中央符号服务器。每个产品都有一个夜间版本，以及“一次性”测试版、RC 和发布版本。

我的目标是保留大约一个月的夜间构建符号，因为我们在这里做了很多“dogfooding”，所以人们使用内部构建，我们希望尽可能轻松地调试从内部 winqual 获得的文件。

我还需要能够永久保留所有 beta、RC 和发布版本符号。

经过大量研究，我认为这里最好的方法是拥有两个符号服务器：一个用于夜间构建（已注册之前的约 30 个构建），另一个用于永久存储 beta、RC 和发布符号。我会使用产品和版本标签将构建脚本添加到符号存储中，以记录产品和构建号。成功构建后，脚本将使用符号服务器中的 history.txt 来识别未删除的最旧构建，然后将其从 symstore 中删除。

对于 beta、RC 和发布版本的“一次性”构建，一旦它们被创建，它们将由构建和安装人员识别，并添加到第二个符号服务器（用于永久存储）。

所以我有几个问题：这看起来是否合理？必须有一种更简单的方法来做到这一点，大多数拥有符号服务器的组织不需要解决这个问题吗？

其次，如果我要继续使用这种方法，是否有一种万无一失的方法来识别在服务器上注册的最古老的已知符号集？我曾考虑过使用上次修改日期，但 history.txt 似乎最合适，但脚本解析可能容易出错。我希望可以只添加一个带有产品和版本信息的符号，以及删除一个带有产品和版本信息的符号。

提前感谢您的帮助。我很乐意回答任何人可能有的任何问题，或提供任何澄清。

我正在寻找 symstore 用于创建目录名称的哈希算法。我发现这个链接Microsoft Symbol Server / Local Cache Hash Algorithm描述了用于生成散列的数据元素，但它没有详细说明如何计算散列值。我很想看看 symstore 如何生成哈希目录，如果有人有任何可以展示的示例代码，那就太好了！

symstore.exe 工具的删除功能的使用方法如下：

我有很久以前存储的符号，我想删除它们。D:\Symbols\[productname]是保存符号的根。我使用以下行调用该工具：

它给出了以下错误：

该错误表明它将路径识别为有效的符号服务器。我已经仔细检查了 000Admin 文件夹D:\Symbols\[productname]\000Admin\，它确实有从 0000000001 到 0000001261 的事务。我也尝试过删除其他事务，但最终出现相同的错误。history.txt、lastid.txt 和 server.txt 也在那里。我错过了什么？

背景：我有几个通过 TFS2010 在 Windows Server 2003 R2 机器上运行的构建。所有这些构建定义都将发布符号的路径设置为“\\server\SymbolStore”，并且构建运行良好。

（注意——我从一位前雇员那里继承了这个设置，我还有其他构建在单独的 2K8 机器上运行，它们也可以正常运行）

我现在正在使用相同的设置将这些构建迁移到新的 Windows 2008 R2 构建服务器。

问题：在新的构建机器上运行构建时，一切正常，直到构建尝试在工作流中运行“发布符号”活动，此时我收到错误

SYMSTORE 错误：类：服务器。描述：无法连接到服务器。错误 5：访问被拒绝。TF270015：“symstore.exe”返回了意外的退出代码。预期为“0”；实际的“5”。

这还将构建状态设置为部分成功。

到目前为止，我已经在网上搜索了这些错误消息，但无济于事，所以有人知道可能导致此问题的原因以及如何使其再次工作吗？

一如既往，提前感谢

我浏览了这些文章，但找不到我的问题的答案-

我们已将 pdb 发布到服务器，但空间不足......我们希望使用 symstore 正确取消发布/移动/归档等，因此我们不会影响事务 ID 和它们的存储方式。

如何指定移动/删除所有早于 X 个月的 pdb

我在这里查看了命令列表：http: //msdn.microsoft.com/en-us/library/windows/desktop/ms681378 (v=vs.85).aspx

最近我注意到，当使用 SymChk 从 Microsoft 符号存储下载符号时，它会带来 DLL 和 PDB。我想知道是否可以使用标准的微软工具（如 SymChk/SymStore）来存储二进制文件和符号？

问题

有很多手动方法可以让 WinDBG 在没有符号存储的情况下找到 mscordacwks.dll（将文件放在路径中的某个位置，将其放在与 windbg.exe 相同的文件夹中，将其放在我的 Framework\v 文件夹中，指定路径WinDBG 使用.cordll -lp c:\dacFolder等），但他们都只为我修复它。我需要为使用我的符号存储的每个人更普遍地修复它。

我能想象的可能的解决方案是：

• WinDBG 使用 mscordacwks.dll 的子文件夹名称而不是 mscorwks.dll 的文件夹名称来检查符号存储。
• SymStore.exe 被添加到 mscorwks.dll 的子文件夹名称下的 mscordacwks.dll，以便 WinDBG 找到它。

问：这些事情中的任何一个都是可能的，还是有其他我没有想到的解决问题的方法？

的背景

在分析 .NET 进程时，我遇到了 psscor2（和 sosex）无法在我的机器上找到合适的 mscordacwks.dll 的（显然很常见的）问题。WinDBG 中的错误是：

有很多关于这个的问题和很多好的答案，实际上所有这些最终都参考了 Doug Stewart 的优秀博客文章，什么是 mscordacwks.dll？.

多亏了这一点，我通过获取正确的 mscordacwks.dll 并将其放置在此处来解决所有问题：

我知道 WinDBG 会出现在哪里，因为我之前用!sym noisy.

所以我现在已经准备好了，但是我必须将它物理地放在那个路径中，而不是通过正常symstore.exe机制将它添加到我的符号服务器中。由于我的符号存储不仅仅是我自己使用的，因此我需要以正确的方式为使用该存储的其他人做这件事。

这就是问题所在。当我添加使用symstore.exe而不是进入上述路径时，它进入：

唯一的区别是子文件夹名称在4E1545CB1bd000这里而不是4E1545829a3000WinDBG 正在寻找的名称。

这样做的原因是，在将二进制文件添加到符号存储时，symstore.exe使用二进制文件的 PE 来获取图像时间戳和图像大小。在这个特定的 .dll 的情况下，dumpbin.exe /headers mscordacwks.dll显示这些是：

• 图片时间戳：0x4E1545CB（2011 年 7 月 7 日星期四 01:36:11）
• 图片尺寸：0x1BD000

因此，子文件夹名称4E1545CB1BD000。

另一方面，WinDBG 正在寻找的是基于图像时间戳和图像大小的子文件夹mscorwks.dll，而不是mscordacwks.dll，因为前者被加载到进程中，而不是后者。WinDBG 无法知道 DAC 模块的时间戳和大小，因为该模块不在进程转储中。

作为对这一解释的进一步验证，dumpbin.exe /headers mscorwks.dll揭示：

• 图片时间戳：0x4E154582（2011 年 7 月 7 日星期四 01:34:58）
• 图片尺寸：0x9A3000

您可以看到添加到子文件夹名称4E1545829A3000。

知道了这一点，现在人们就更明白为什么人们经常遇到的所有这些 mscordacwks.dll 版本似乎都从 Microsoft 的符号服务器中丢失了。我确定它们在那里，只是 WinDBG 和 psscor2 找不到它们，因为它们选择了错误的子文件夹名称。为什么它甚至会费心搜索符号路径，这超出了我的理解，因为它保证永远找不到它！

所以这就是我的挑战。我可以symstore.exe使用 mscorwks.dll 的 PE 信息以某种方式强制添加 mscordacwks.dll 吗？如果没有，我是否遗漏了有关 WinDBG 和 psscor2 的信息，是否有办法让他们知道 mscordacwks.dll 的正确时间戳和大小，即使它没有加载（以及让他们实际使用这些而不是 mscorwks.dll 的方法)?