Ich hatte ähnliche Probleme mit der ersten Veröffentlichung von ClrMD. Es konnte keine MSCORDACWKS erfolgreich geladen werden, die WinDbg fröhlich akzeptiert hat, war in dem Pfad, den ich ClrMD zur Verfügung gestellt hatte, und konnte erfolgreich mit WinDbg für denselben Dump verwenden. Das gleiche passierte mit der ersten Veröffentlichung von DebugDiag v2, die, wie ich verstehe, auf ClrMD basiert. Ich machte den gleichen umbenannten DAC, der von WinDbg akzeptiert wurde, verfügbar auf dem Symbolpfad von DebugDiag und DebugDiag unterbrach die Analyse; zu sagen, dass der Zeitstempel und die Größe von "mscordacwk.dlls [bereitgestellt] nicht mit dem im Speicherauszug übereinstimmen"; obwohl es nach dem Ladeversuch über ProcMon deutlich zeigte, dass es über den von WinDbg akzeptierten Namen auf die richtige DLL zugreift.
Während der Arbeit mit unserem Microsoft-Team auf der DebugDiag v2 Unfähigkeit, den DAC zu laden, war ich in der Lage, unsere TAM auch eine frühe Kopie einer "festen" ClrMD, die als ClrMD 0.8.5 benannt wurde löste solche Probleme für mich. Es ist ein Alpha-Build und ich bin nicht autorisiert, es neu zu verteilen, aber zumindest könnten Sie nach dieser Version oder einem neueren als 0.8.5 in freier Wildbahn suchen.
Eine andere Sache: Wenn Sie die entsprechende 32-Bit- oder 64-Bit-WinDbg verwenden, können Sie in der Regel mit nur zwei benannten Varianten von MSCORDACWKS kommen: eine für 64-Bit und eine für 32-Bit. Um beispielsweise MSCORDACWKS für .Net 4.0.0319.1008 von einem anderen Computer zu laden, können Sie die 64-Bit-Version des Dump-Zielhosts aus C: \ Windows \ Microsoft.NET \ Framework64 in mscordacwks_AMD64_AMD64_4.0.31319.1008.dll umbenennen 64-Bit-App und benennen Sie die 32-Bit-Version von C: \ Windows \ Microsoft.NET \ Framework64 um mscordacwks_x86_x86_4.0.30319.1008.dll für eine 32-Bit-App und ziemlich erfolgreich sein.
Es gibt jedoch eine zusätzliche Falte mit ClrMD. Sie können damit enden, dass die ClrMD-Bibliothek nach weiteren benannten Versionen des DAC sucht, abhängig von der Bit-Anzahl, die Sie als Build-Ziel für die Visual Studio-Kompilierung Ihrer App mit ClrMD verwenden.
Als ich aus Gewohnheit meine erste ClrMd-Testumgebung für eine 64-Bit-Zielplattform erstellte, suchte ClrMd nach lib namens mscordacwks_x86_amd64_4.0.30319.1008.dll anstelle des Namens "... x86_x86 ...". Trotz der Tatsache, dass ich meine Testumgebung gegen eine 32-Bit-App lief, schien das Umbenennen des DAC aus einem der beiden oben genannten Umbenennungen nicht zu funktionieren. (Ich sage nicht, dass ich nicht etwas falsch gemacht habe; nur dass es für mich nicht funktionierte. Ihre Laufleistung kann variieren.)
Allerdings habe ich einmal das Build-Ziel in VS2010 auf 32-Bit geändert , die 0.8.5 "fixed" -Version geladen sofort die ordnungsgemäß umbenannte mscordacwks_x86_x86_4.0.30319.1008 DLL ohne weitere Probleme.
Ich denke, es versucht, X86_Amd64 DAC zu laden, wenn 32-Bit-Prozess-Dump von 64-Bit-Tool erstellt wurde. https://blogs.msdn.microsoft.com/tess/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine/ –