＆QUOT;故障装载DAC：CreateDacInstance失败＆QUOT;与ClrMD加载转储文件时， [英] "Failure loading DAC: CreateDacInstance failed" when loading dump file with ClrMD

问题描述

我是从微软， ClrMD ，尝试新的库来分析崩溃转储和现场处理。

I'm trying the new library from microsoft, ClrMD, to analyze crash-dumps and live process.

我已经跟随样品中的.NET框架<一href="http://blogs.msdn.com/b/dotnet/archive/2013/05/01/net-crash-dump-and-live-process-inspection.aspx">blog帖子（使用<一个href="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-10-41-54-93/ClrMDSample_2E00_cs">attached cs文件）。

I've follow the sample in the .NET framework blog post (using the attached .cs file).

我试图运行样品分析哪些是从作为样品在同一台机器上运行的程序采取.dmp文件。

I tried to run the sample to analyze .dmp file which was taken from a program running on the same machine as the sample.

尝试创建运行时对象时，使用下面的code：

when trying to create the run-time object, using the following code:

ClrRuntime runtime = target.CreateRuntime(dacLocation);

这抛出异常：

消息：未能装载DAC：CreateDacInstance失败0x80131c30

Message: Failure loading DAC: CreateDacInstance failed 0x80131c30

在Microsoft.Diagnostics.Runtime.Desktop.DacLibrary.Init（字符串DLL）

at Microsoft.Diagnostics.Runtime.Desktop.DacLibrary.Init(String dll)

在Microsoft.Diagnostics.Runtime.Desktop.DacLibrary..ctor（DbgEngTarget   dataTarget，串DLL）

at Microsoft.Diagnostics.Runtime.Desktop.DacLibrary..ctor(DbgEngTarget dataTarget, String dll)

在Microsoft.Diagnostics.Runtime.DbgEngTarget.CreateRuntime（字符串   dacFilename）

at Microsoft.Diagnostics.Runtime.DbgEngTarget.CreateRuntime(String dacFilename)

在DumpFetch.App..ctor（）

at DumpFetch.App..ctor()

任何想法？

推荐答案

我有类似的问题，ClrMD的初始版本。这是无法成功加载的WinDbg乐呵呵地接受了MSCORDACWKS，是我提供给ClrMD路径，并与WinDbg中对同一转储可以成功地使用。同样的事情发生在DebugDiag资料V2这，我的理解，是基于ClrMD的初始版本。我犯了同样的改名DAC通过WinDbg的接受可以在DebugDiag资料的符号路径和中止DebugDiag资料分析;话说，[条件]mscordacwk.dlls'时间戳和大小没有一个在转储匹配;尽管下面通过将procmon负载尝试清楚地表明它是通过在WinDbg接受的名字来访问正确的DLL。

I had similar problems with the initial release of ClrMD. It was unable to successfully load an MSCORDACWKS that WinDbg cheerfully accepted, was in the path I made available to ClrMD, and could successfully use with WinDbg against the same dump. The same thing happened with the initial release of DebugDiag v2 which, I understand, is based on ClrMD. I made the same renamed DAC accepted by WinDbg available on DebugDiag's symbol path and DebugDiag aborted the analysis; saying that the [provided] "mscordacwk.dlls’ timestamp and size do not match the one in the dump"; even though following the load attempt via ProcMon clearly showed it was accessing the correct DLL via the WinDbg-accepted name.

不过，虽然与上DebugDiag资料V2无法载入DAC我们的微软团队的工作，我能得到我们的TAM还提供了一个固定ClrMD早期副本命名为ClrMD 0.8.5的解决这些问题对我来说。这是一个alpha版本，我没有被授权重新分发，但至少你可能会寻找那些版本或者一个新的比0.8.5在野外。

However, while working with our Microsoft team on the DebugDiag v2 inability to load the DAC, I was able to get our TAM to also provide an early copy of a "fixed" ClrMD which was named as ClrMD 0.8.5 that resolved such issues for me. It's an alpha build and I am not authorized to re-distribute it, but at least you might look for that version or one newer than 0.8.5 in the wild.

另外一件事情：当使用合适的32位或64位的WinDbg，你通常可以逃脱只有两个名为MSCORDACWKS的变体：一个用于64位，另一个用于32位。因此，对于装载MSCORDACWKS对于.NET 4.0.0319.1008从另一台机器，例如，您可以重命名转储目标主机的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位应用程序和pretty的多是成功的

One other thing: When using the appropriate 32-bit or 64-bit WinDbg, you can generally get away with just two named variants of MSCORDACWKS: one for 64-bit and one for 32-bit. So for loading MSCORDACWKS for .Net 4.0.0319.1008 from another machine, for example, you can rename the dump target host's 64-bit version out of C:\Windows\Microsoft.NET\Framework64 to mscordacwks_AMD64_AMD64_4.0.31319.1008.dll for a 64-bit app and rename the 32-bit version out of C:\Windows\Microsoft.NET\Framework64 to mscordacwks_x86_x86_4.0.30319.1008.dll for a 32-bit app and pretty much be successful.

有一个附加的皱纹，但是，相机连ClrMD。您可以最终获得ClrMD库试图为的DAC取决于附加命名版本的位岬你使用的构建目标，你的应用程序中使用ClrMD在Visual Studio编译。

There is one additional wrinkle, though, wth ClrMD. You can end up with the ClrMD library trying for additional named versions of the DAC depending upon the bit-ness you're using as the Build target for the Visual Studio compile of your app using ClrMD.

当我建立我的第一个ClrMd测试工具为64位目标平台是出于习惯，ClrMd一直在寻找的lib命名mscordacwks_x86_amd64_4.0.30319.1008.dll而不是... x86_x86 ......的名字。尽管如此，我跑我的测试工具对32位应用程序，只需重命名DAC无论从上述两个重命名的似乎没有工作的事实。 （我不是说我没有什么不对;只是它并没有为我工作，你的情况可能会有所不同）

When I built my first ClrMd test harness for a 64-bit target platform out of habit, ClrMd was looking for lib named mscordacwks_x86_amd64_4.0.30319.1008.dll instead of the "...x86_x86..." name. In spite of the fact that I was running my test harness against a 32-bit app, simply renaming the DAC from either of the two renames mentioned above did not seem to work. (I'm not saying that I didn't have something wrong; just that it didn't work for me. Your mileage may vary.)

但是，一旦我改变了构建目标在VS2010为32位，在0.8.5固定版本立即装入正确改名mscordacwks_x86_x86_4.0.30319.1008 DLL没有进一步的问题。

However, once I changed the build target in VS2010 to be 32-bit, the 0.8.5 "fixed" version immediately loaded the properly renamed mscordacwks_x86_x86_4.0.30319.1008 DLL without further issues.

这篇关于＆QUOT;故障装载DAC：CreateDacInstance失败＆QUOT;与ClrMD加载转储文件时，的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！