“Failure loading DAC: CreateDacInstance failed” wh

Question

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

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

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

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

ClrRuntime runtime = target.CreateRuntime(dacLocation);

This exception is thrown:

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()

Any ideas?

Answer 1

There is another method on ClrVersion called TryDownloadDac(); which will download the correct one, but you do need to be running a process on the same architecture as the one you're debugging (64 bit app to debug 64bit, 32bit app to debug 32). This is because it needs to load the DAC library into memory.

Answer 2

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.

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.

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.

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.

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.)

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.