使用ClrMD加载转储文件时出现“加载DAC失败: CreateDacInstance失败”

Question

我正在尝试微软的新库ClrMD来分析崩溃转储和实时进程。

我遵循了.NET框架blog post中的示例(使用attached .cs file)。

我尝试运行该示例来分析一个.dmp文件，该文件取自与该示例运行在同一台机器上的程序。

尝试创建运行时对象时，使用以下代码：

ClrRuntime runtime = target.CreateRuntime(dacLocation);

抛出此异常：

Message: Failure loading DAC: CreateDacInstance failed 0x80131c30
 
  at Microsoft.Diagnostics.Runtime.Desktop.DacLibrary.Init(String dll)
  at Microsoft.Diagnostics.Runtime.Desktop.DacLibrary..ctor(DbgEngTarget dataTarget, String dll)
  at Microsoft.Diagnostics.Runtime.DbgEngTarget.CreateRuntime(String dacFilename)
  at DumpFetch.App..ctor()

有什么想法吗？

Answer 1

在最初的ClrMD版本中，我也遇到过类似的问题。它无法成功加载WinDbg欣然接受的MSCORDACWKS，它位于我提供给ClrMD的路径中，并且可以在同一转储上成功地与WinDbg一起使用。据我所知，最初发布的DebugDiag v2基于ClrMD，也发生了同样的事情。我在DebugDiag的符号路径上提供了WinDbg接受的相同重命名的DAC，DebugDiag中止了分析；说提供的“mscordacwk.dlls的时间戳和大小与转储中的不匹配”；即使通过ProcMon进行的加载尝试清楚地表明它正在通过WinDbg接受的名称访问正确的DLL。

然而，在与我们的微软团队合作解决DebugDiag v2无法加载数据访问控制的问题时，我能够让我们的技术经理也提供一个名为ClrMD 0.8.5的“修复”ClrMD的早期副本，它为我解决了这些问题。这是一个alpha版本，我没有被授权重新发布它，但至少你可以在野外寻找那个版本或比0.8.5更新的版本。

还有一件事:当使用适当的32位或64位WinDbg时，通常只需使用两个命名的MSCORDACWKS变体:一个用于64位，另一个用于32位。例如，要从另一台计算机加载用于.Net 4.0.0319.1008的MSCORDACWKS，对于64位应用程序，您可以将转储目标主机的64位版本从C:\Windows\Microsoft.NET\Framework64重命名为mscordacwks_AMD64_AMD64_4.0.31319.1008.dll，对于32位应用程序，您可以将C:\Windows\Microsoft.NET\Framework64的32位版本重命名为mscordacwks_x86_x86_4.0.30319.1008.dll，这几乎是成功的。

不过，ClrMD还有一个额外的问题。根据您使用ClrMD作为应用程序Visual Studio编译的构建目标的位数，您可能最终会使用ClrMD库尝试其他命名版本的DAC。

当我出于习惯为64位目标平台构建我的第一个ClrMd测试工具时，ClrMd寻找的是名为mscordacwks_x86_amd64_4.0.30319.1008.dll的库，而不是"...x86_x86...“名字。尽管我是在32位应用程序上运行我的测试工具，但简单地从上面提到的两个重命名中的任何一个重命名DAC似乎都不起作用。(我并不是说我没有做错什么，只是它对我不起作用。您的里程可能会有所不同。)

但是，一旦我将VS2010中的构建目标更改为32位，0.8.5“修复”版本立即加载正确重命名的mscordacwks_x86_x86_4.0.30319.1008 DLL，没有进一步的问题。

Answer 2

在ClrVersion上还有另一个名为TryDownloadDac()的方法，它将下载正确的方法，但您确实需要在与正在调试的进程相同的体系结构上运行一个进程(64位应用程序用于调试64位，32位应用程序用于调试32位)。这是因为它需要将DAC库加载到内存中。