6

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

我遵循 .NET Framework博客文章中的示例（使用附加的 .cs 文件）。

我尝试运行该示例来分析一个 .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()

有任何想法吗？

4

2 回答 2

7

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

但是，在与我们的 Microsoft 团队合作解决 DebugDiag v2 无法加载 DAC 问题时，我能够让我们的 TAM 还提供一个名为 ClrMD 0.8.5 的“固定”ClrMD 的早期副本，该副本解决了此类问题我。这是一个 alpha 版本，我无权重新分发它，但至少你可能会在野外寻找那个版本或比 0.8.5 更新的版本。

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

但是，使用 ClrMD 时还有一个额外的问题。您最终可以使用 ClrMD 库尝试其他命名版本的 DAC，具体取决于您用作使用 ClrMD 编译应用程序的 Visual Studio 编译目标的位数。

当我出于习惯为 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，而不会出现其他问题。

于 2014-01-08T18:43:20.387 回答
1

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

于 2014-02-28T18:37:11.057 回答