【发布时间】：2013-10-17 14:55:23
【问题描述】：
问题
有很多手动方法可以让 WinDBG 在没有符号存储的情况下找到 mscordacwks.dll（将文件放在路径中的某个位置，将其放在与 windbg.exe 相同的文件夹中，将其放在我的 Framework\v 文件夹中，指定WinDBG 中使用.cordll -lp c:\dacFolder 等的路径），但它们都只为me 修复它。我需要为使用我的符号存储的每个人更普遍地修复它。
我能想到的可能解决方案是：
- WinDBG 使用 mscordacwks.dll 的子文件夹名称而不是 mscorwks.dll 的文件夹名称检查符号存储。
- SymStore.exe 应添加到 mscorwks.dll 的子文件夹名称下的 mscordacwks.dll，以便 WinDBG 找到它。
问：这两种方法都可能吗，还是有其他我没有想到的解决问题的方法？
背景
在分析 .NET 进程时，我遇到了（显然很常见的）问题，即 psscor2（和 sosex）在我的机器上找不到合适的 mscordacwks.dll。 WinDBG中的错误是：
Failed to load data access DLL, 0x80004005
Verify that 1) you have a recent build of the debugger (6.2.14 or newer)
2) the file mscordacwks.dll that matches your version of mscorwks.dll is
in the version directory
3) or, if you are debugging a dump file, verify that the file
mscordacwks_<arch>_<arch>_<version>.dll is on your symbol path.
4) you are debugging on the same architecture as the dump file.
For example, an IA64 dump file must be debugged on an IA64
machine.
You can also run the debugger command .cordll to control the debugger's
load of mscordacwks.dll. .cordll -ve -u -l will do a verbose reload.
If that succeeds, the SOS command should work on retry.
If you are debugging a minidump, you need to make sure that your executable
path is pointing to mscorwks.dll as well.
这方面有很多 SO 问题和很多好的答案，几乎所有这些最终都参考了 Doug Stewart 的出色博客文章 What is mscordacwks.dll?。
多亏了这一点，我得到了正确的 mscordacwks.dll 并将其放置在此处，从而解决了所有问题：
"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"
我知道 WinDBG 的外观，因为我之前用 !sym noisy 尝试过。
所以我现在已经准备好了，但是我必须将它物理地放在那个路径中，而不是通过正常的 symstore.exe 机制将它添加到我的符号服务器中。由于我的符号库不仅仅是我自己使用的，因此我需要以正确的方式为使用该商店的其他人做这件事。
这就是问题所在。当我添加使用symstore.exe 而不是进入上述路径时，它进入：
"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545CB1bd000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"
唯一的区别是这里的子文件夹名称是 4E1545CB1bd000 而不是 WinDBG 正在寻找的 4E1545829a3000。
这样做的原因是，在将二进制文件添加到符号存储时，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 的方法)?
【问题讨论】：
-
我无法将 mscordacwks.dll 添加到您自己的商店，但我知道调试器确实知道如何正确搜索商店。它是调试器而不是加载 DAC 的扩展。较新的 DAC 应该在公共符号存储中，但较旧的 DAC 不会。我的理解是微软现在正在向商店添加新的，但我可能弄错了。
-
WinDBG 知道如何在存储中正确地找到加载的模块及其符号，但这里它试图使用相同的逻辑来查找帮助文件，而不是加载的模块。它没有找到它，因为它使用了错误的图像时间戳和图像大小。 （每个 procmon WinDBG 正在调用 symsrv.dll!SymFindFileInPath()，并且显然为
in和two参数传递了错误的值。）我的解决方法是将压缩的 DAC (mscordacwks.dl_) 放在我的商店中 WinDBG 所在的路径中看起来不正确。我想知道微软是否也这样做。
标签： clr windbg sos symstore sosex