可以使WinDBG在符号存储中找到mscordacwks.dll吗？ [英] Can WinDBG be made to find mscordacwks.dll in the symbol store?

问题描述

问题

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

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

• 使WinDBG使用mscordacwks.dll的子文件夹名称代替mscorwks.dll的文件夹名称来检查符号存储。


• 可以使SymStore.exe在mscorwks.dll的子文件夹名称下添加mscordacwks.dll，以便WinDBG在出现时在其中找到它。

问： 这一切是否有可能，或者还有我不打算解决该问题的另一种方式？

背景

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

 无法加载数据访问DLL，0x80004005 
验证1）您拥有最新的调试器的版本（6.2.14或更高版本）
 2）与您的mscorwks.dll版本匹配的文件mscordacwks.dll在版本目录
 3中为
），或者，如果调试转储文件时，请验证文件
 mscordacwks_< arch> __< arch> _< version> .dll位于符号路径中。 
 4）您正在调试与转储文件相同的体系结构。 
例如，必须在IA64 
机器上调试IA64转储文件。 
 
您还可以运行调试器命令.cordll来控制调试器的mscordacwks.dll 
负载。 .cordll -ve -u -l将进行详细的重新加载。 
如果成功，则SOS命令应该可以重试。 
 
如果要调试小型转储，则需要确保可执行文件
路径也指向mscorwks.dll。 
  

有很多这样的问题和很多好的答案，实际上所有这些最终都引用了道格斯图尔特的杰出博客文章什么是mscordacwks.dll？。

感谢，我的情况得到了解决通过获取正确的mscordacwks.dll并将其放置在此处：

  C：\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216 .dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll 
  

我知道WinDBG在哪里因为我以前曾尝试过！symnoisy 。

所以我已经全部准备好了，但是我已经将其物理地放置在该路径中，而不是通过常规的 symstore.exe 机制将其添加到我的符号服务器中。由于我的符号存储不仅被我自己使用，因此我需要对使用该存储的其他人进行正确的操作。

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

  C：\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545CB1bd000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll 
  

唯一的区别是子文件夹名称为 4E1545CB1bd000 ，而不是 4E1545829a3000 就是WinDBG正在寻找的。

原因是在向其中添加二进制文件时符号存储 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的一种方法） ）？

解决方案

由于没有其他解决方案出现，而且我的解决方法似乎可以很好地处理所有问题，因此我将继续这样做，我会建议其他人谁也不想看到讨厌的无法加载数据访问DLL，再次出现0x80004005 错误。

因此，为了让您（以及使用符号存储的每个人都可以使用），只需放置压缩的DAC文件（mscordacwks），我真的希望Microsoft这样做可以为我们节省很多麻烦。 dl_）手动输入本地SYM商店中的正确路径。

以下是我要完成此操作的步骤：

1. 在WinDBG中执行！sym嘈杂


2. 在WinDBG中执行一个 .cordll -ve -u -l <​​/ code>


3. 在WinDBG中再执行一个！CLRStack 或其他必要的psscor2命令，以强制其再次加载符号


4. 符号搜索日志记录将通过显示如下所示的行来显示其正在查找的dll及其在符号存储中的位置： C：\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll 表示两件事：
   
   
   
   
   • 您需要版本2.0.50727.4216的64位mscordacwks.dll；请参阅 https://stackoverflow.com/a/12024171/1910619 了解获取方法
   
   
   • 它需要进入符号存储区中名为mscordacwks_AMD64_AMD64_2.0.50727.4216.dll的文件夹下的子文件夹4E1545829a3000
   
   


5. 一旦获得文件，就根据WinDBG所寻找的名称对其进行重命名，例如 mscordacwks_AMD64_AMD64_2.0.50727.4216.dll


6. 使用makecab.exe手动压缩该文件，如下所示： makecab / D CompressionType = LZX / D CompressionMemory = 21 mscordacwks_AMD64_AMD64_2。 0.50727.4216.dll mscordacwks_AMD64_AMD64_2.0.50727.4216.dl _


7. 将该压缩文件复制到符号存储中的预期位置。 （您在上面的步骤4中找到了，所以C：CSymbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dl_在我们此处运行的示例中。）




The Question

There are plenty of manual ways to make WinDBG find mscordacwks.dll without a symbol store (putting the file in the path somewhere, putting it in the same folder as windbg.exe, putting it in my Framework\v folder, specifying the path in WinDBG using .cordll -lp c:\dacFolder, etc.), but they all only fix it for me. I need to fix it more generally for everyone who uses my symbol store.

The possible solutions I can imagine are:

• WinDBG be made to check the symbol store using mscordacwks.dll's subfolder name instead of mscorwks.dll's folder name.
• SymStore.exe be made to add mscordacwks.dll under mscorwks.dll's subfolder name so WinDBG finds it when it looks there.

Q: Are either of these things possible, or is there another way that I'm not thinking of to solve the problem?

The Background

When analyzing a .NET process, I encountered the (apparently common) problem that psscor2 (and sosex) could not find the appropriate mscordacwks.dll on my machine. The error in WinDBG is:

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.

There are plenty of SO questions on this and plenty of good answers, practically all of which ultimately reference Doug Stewart's outstanding blog post, What is mscordacwks.dll?.

Thanks to that, I got my situation all straightened out by obtaining the correct mscordacwks.dll and placing it here:

"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"

where I knew WinDBG would look because I had previously tried it with !sym noisy.

So I'm all set now, but I had to put it in that path physically rather than adding it to my symbol server through the normal symstore.exe mechanism. Since my symbol store is used by more than just me, I need to do it the right way for everyone else using the store.

And that's the problem. When I add using symstore.exe instead of going into the above path, it goes into:

"C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545CB1bd000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"

The only difference being that the subfolder name is 4E1545CB1bd000 here instead of the 4E1545829a3000 that WinDBG is looking for.

The reason for this is that when adding a binary to the symbol store, symstore.exe uses the PE of the binary to get the image timestamp and the image size. In the case of this particular .dll, dumpbin.exe /headers mscordacwks.dll reveals these to be:

• image timestamp: 0x4E1545CB (Thu Jul 07 01:36:11 2011)
• image size: 0x1BD000

Hence, the subfolder name 4E1545CB1BD000.

What WinDBG is looking for, on the other hand, is a subfolder based on the image timestamp and image size of mscorwks.dll, not mscordacwks.dll, because the former is loaded into the process, not the latter. WinDBG can't know the timestamp and size of the DAC module because that module is not in the process dump.

As further verification of this explanation, dumpbin.exe /headers mscorwks.dll reveals:

• image timestamp: 0x4E154582 (Thu Jul 07 01:34:58 2011)
• image size: 0x9A3000

which you can see add up to subfolder name 4E1545829A3000.

Knowing this, now it makes a lot more sense why all these many versions of the mscordacwks.dll that people keep running into seem to be missing from Microsoft's symbol servers. I'm sure they're there, it's just that WinDBG and psscor2 can't find them because they're picking the wrong subfolder name. Why it even bothers searching the symbols path is beyond me since it's guaranteed never to find it!

So that's my challenge. Can I somehow force symstore.exe to add mscordacwks.dll using the PE info of mscorwks.dll? If not, am I missing something about WinDBG and psscor2, might there be a way for them to know the correct timestamp and size of mscordacwks.dll even though it's not loaded (and a way for them to actually use those instead of mscorwks.dll)?

解决方案

Since no other solution has appeared and my workaround seems to handle everything nicely, I'm just going to keep on with that, and I would recommend anyone else who never wants to see the annoying Failed to load data access DLL, 0x80004005 error again do the same.

So to make this work for you (and everyone who uses your symbol store, so I really wish Microsoft would do this to save us all a lot of trouble) simply place the compressed DAC file (mscordacwks.dl_) by hand into the correct path within your local SYM store.

Here are the steps I follow to accomplish this:

1. In WinDBG do a !sym noisy
2. In WinDBG do a .cordll -ve -u -l
3. In WinDBG do another !CLRStack or other psscor2 command if necessary to force it to load symbols again
4. The symbol search logging will reveal the dll it’s looking for and where it’s looking in your symbol store by showing lines like this: C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll which indicates two things:
   • you need the 64-bit mscordacwks.dll of version 2.0.50727.4216; see https://stackoverflow.com/a/12024171/1910619 for ways to get it
   • it needs to go in a subfolder called 4E1545829a3000 under a folder called mscordacwks_AMD64_AMD64_2.0.50727.4216.dll in your symbol store
5. Once you obtain the file, rename it according to the name WinDBG is looking for, e.g. "mscordacwks_AMD64_AMD64_2.0.50727.4216.dll"
6. Manually compress this file using makecab.exe like this: makecab /D CompressionType=LZX /D CompressionMemory=21 mscordacwks_AMD64_AMD64_2.0.50727.4216.dll mscordacwks_AMD64_AMD64_2.0.50727.4216.dl_
7. Copy that compressed file to the expected place in the symbol store. (That you found in step 4 above, so C:\Symbols\mscordacwks_AMD64_AMD64_2.0.50727.4216.dll\4E1545829a3000\mscordacwks_AMD64_AMD64_2.0.50727.4216.dl_ in our running example here.)

这篇关于可以使WinDBG在符号存储中找到mscordacwks.dll吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！