我正在尝试微软的新库ClrMD，以分析崩溃转储和实时进程。
我已经按照.NETFramework博客文章中的示例进行了操作（使用附加的.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()
有什么想法吗？
我在ClrMD的最初发布时也遇到了类似的问题。它无法成功加载WinDbg欣然接受的MSCORDACWKS，它位于我为ClrMD提供的路径中，并且可以成功地与WinDbg一起使用同一转储。同样的事情也发生在最初发布的DebugDiag v2上，据我所知，它是基于ClrMD的。我在DebugDiag的符号路径上提供了WinDbg接受的相同的重命名DAC，DebugDiag中止了分析；表示[提供的]"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的64位版本重命名为mscordacwks_AMD64_AMD64_4.0.3319.1008.dll，对于32位应用程序则可以将C:\Windows\Microsoft.com/Framework64中的32位版本重名为mscordacwks_x86_x86_4.0.30319.1008..dll，并且非常成功。
不过，还有一个额外的褶皱，那就是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，没有出现进一步的问题。
ClrVersion上还有另一个方法，名为TryDownloadDac（）；它将下载正确的进程，但您确实需要在与正在调试的进程相同的架构上运行进程（64位应用程序到64位调试，32位应用程序从32位调试）。这是因为它需要将DAC库加载到内存中。