"Failure loading DAC: CreateDacInstance failed" when loading dump file with ClrMD

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.