“Failed to load data access DLL, 0x80004005” – OR – What is mscordacwks.dll?_failed to load data access dll, 0x80004005 verify -优快云博客

译文

“无法加载数据访问 DLL，0x80004005” – OR – 什么是 mscordacwks.dll？|Microsoft 学习

是否在 WinDBG/CDB 调试会话中看到过此错误？

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.

此错误消息是尝试使用 SOS 调试器扩展使用 WinDBG/CDB 调试 .NET 2.0 应用程序转储的人经常面临的问题。我最近遇到了太多的问题，我认为这值得解释一下。

什么是 mscordacwks.dll？

公共语言运行时（CLR）是执行托管代码的 Microsoft .NET Framework 的核心引擎。简单来说，它通过在托管程序集中采用中间语言和元数据，按需对代码进行 JIT 编译，在内存中构建程序集定义和使用的类型的表示形式，并确保生成的代码是安全的、可靠的和可验证的，并在需要的时候执行。此引擎本身是用本机代码实现的。当我们想要使用本机调试器（如 CDB 或 WinDBG）调试 .NET 应用程序时（如果我们想使用事后内存转储文件对其进行调试，我们目前会做很多工作），我们必须在本机调试器和托管世界之间使用“桥梁”，因为本机调试器本身并不理解托管代码。它是一个本机调试器。

为了提供此桥接，CLR 附带了一个调试器扩展 – SOS.DLL。这理解了 CLR 的内部结构，因此允许我们执行输出托管调用堆栈、转储托管堆等作。

但是，这些内部数据结构和 CLR 的详细信息有时会发生变化，因此，从使 .NET 应用程序正常工作的 CLR 的实际内部实现中抽象出此调试器扩展所需的 CLR 接口非常有用。输入 mscordacwks.dll。这提供了数据访问组件（DAC），该组件允许 SOS.DLL 调试器扩展解释维护 .NET 应用程序状态的内存中数据结构。

如果您查看框架文件夹，您应该始终会看到这 3 个 DLL 的匹配集：

[image]

如果使用 64 位，则还应在 Framework64 文件夹中看到匹配的 DLL 集。

此错误消息是什么意思？

这意味着 SOS.DLL 调试器扩展无法找到所需的匹配mscordacwks.dll，以便能够调试您尝试调试的转储文件。

您如何知道我正在调试转储文件？

因为如果您正在调试实时应用程序，调试器扩展将自动从框架目录中查找并加载mscordacwks.dll。

我什么时候可能会收到此错误消息，什么时候不会收到它？

如果要调试应用程序中的转储文件，而该应用程序使用的 CLR 版本（例如，安装的 Service Pack 或修补程序与本地系统上安装的 CLR 版本不同），或者 .NET Framework 安装在与系统安装位置不同的位置，并且调试器无法通过其他方式发现正确的mscordacwks.dll。

“其他”是什么意思？

因为拥有匹配的mscordacwks.dll对于SOS.DLL正常工作非常重要，所以 SOS 有许多技巧来找到它。具体而言，如果已对符号服务器进行正确的索引，则调试器将从那里加载它。如果它已以特殊方式重命名，则 debugger 也会在 debuggers 目录中查找它（请参阅下文）。

那么我该如何解决呢？

大多数情况下，如果已正确设置符号路径（无论如何，您都需要在调试任何内容方面取得任何进展，更不用说托管应用程序了），则调试器应该能够自动从符号服务器获取正确的mscordacwks.dll：

!sym noisy
.symfix c:mylocalsymcache
.cordll -ve -u -l

如果这不起作用怎么办？

最简单的方法是让给你转储文件的人看一看，给你一份mscordacwks.dll的副本。拥有它后，检查其文件属性以获取版本号。它应该是类似于 2.0.50727.xxxx 的内容。然后将其重命名为

mscordacwks_AAA_AAA_2.0.50727.xxxx.dll

其中 xxxx 是版本号的适当位，AAA 是 x86 或 AMD64，具体取决于您处理的是 32 位还是 64 位应用程序转储。（AMD64 是我们提到 x64 之前的传统产品）。然后将此重命名的副本放入 debuggers 目录（安装 WinDBG 的目录）。然后，根据错误消息，告诉调试器重试：

.cordll -ve -u -l

尽管我们尝试确保发布的 CLR 的每个版本（作为 Service Pack、修补程序或其他内容）在公共符号服务器上为其mscordacwks.dll编制索引，但遗憾的是，有时它不会发生。但是，由于它始终作为 CLR 的一部分提供，因此您始终可以选择从转储的来源计算机中获取它。

我尝试了详细的日志记录选项，但它似乎对它想要 x86 还是 x64 感到困惑。现在怎么办？

所以你按照指示运行 .cordll –ve –u –l 并得到如下消息：

CLR DLL 状态：错误：无法加载 DLL mscordacwks_AMD64_x86_2.0.50727.3053.dll，Win32 错误 0n87

这意味着，您很可能使用 64 位调试器在 64 位系统上转储了 32 位进程（在 WoW64 下运行），并且您现在正在尝试使用 64 位调试器分析转储。这就是该消息引用 AMD64 和 x86 的原因。这是行不通的。因为 SOS.DLL 扩展实际上在调试时使用了框架，所以位需要匹配。我强烈建议始终使用与进程具有相同位数的调试器生成转储（因此，即使系统是 x64 系统，WoW64 进程的 x86 调试器）并使用生成转储的相同位数的调试器来分析转储。这意味着您当然不能在 32 位系统上调试 64 位转储。这也意味着您必须安装框架才能调试托管应用程序转储。

现在它告诉我它遭受了“init failure”？

您可能会看到以下内容：

0：018> .cordll -ve -u -l
CLRDLL：错误：DLL C:WindowsMicrosoft.NETFrameworkv2.0.50727mscordacwks.dll 初始化失败，Win32 错误 0n87
CLR DLL 状态：错误：DLL C:WindowsMicrosoft.NETFrameworkv2.0.50727mscordacwks.dll初始化失败，Win32 错误 0n87

这也表明了 bitness 混淆。我在使用 32 位调试器分析使用 64 位调试器生成的 WoW64 进程的转储时看到了这一点。