Miałem podobne problemy z początkową wersją ClrMD. Nie udało się pomyślnie załadować MSCORDACWKS akceptowanego przez WinDbg, znajdował się w ścieżce udostępnionej ClrMD i mógł z powodzeniem używać z WinDbg na tym samym dump. To samo stało się z początkową wersją DebugDiag v2, która, jak rozumiem, opiera się na ClrMD. Zrobiłem ten sam przemianowany DAC zaakceptowany przez WinDbg dostępny na ścieżce symbolu DebugDiag, a DebugDiag przerwał analizę; mówiąc, że "dostarczony" znacznik czasu i rozmiar mscordacwk.dll nie pasują do tego w zrzucie "; mimo że próba obciążenia za pośrednictwem ProcMon wyraźnie pokazała, że uzyskiwał dostęp do poprawnej biblioteki DLL za pośrednictwem nazwy zaakceptowanej przez WinDbg.
Jednak podczas pracy z naszym zespołem Microsoft w sprawie braku możliwości wczytania DAC przez DebugDiag v2, udało mi się uzyskać nasz TAM, aby zapewnić również wczesną kopię "ustalonego" ClrMD, który został nazwany ClrMD 0.8.5, który rozwiązał takie problemy dla mnie. Jest to kompilacja alfa i nie mam uprawnień do jej ponownego rozpowszechniania, ale przynajmniej możesz szukać tej wersji lub nowszej niż 0.8.5 na wolności.
Jeszcze jedna rzecz: podczas korzystania z odpowiedniego 32-bitowego lub 64-bitowego WinDbg, można na ogół uciec z dwoma nazwanymi wariantami MSCORDACWKS: jeden dla wersji 64-bitowej i jeden dla wersji 32-bitowej. W celu załadowania MSCORDACWKS dla .Net 4.0.0319.1008 z innego komputera można na przykład zmienić nazwę 64-bitowej wersji dump hosta docelowego z C: \ Windows \ Microsoft.NET \ Framework64 na mscordacwks_AMD64_AMD64_4.0.31319.1008.dll 64-bitowa aplikacja i zmień nazwę wersji 32-bitowej z C: \ Windows \ Microsoft.NET \ Framework64 na mscordacwks_x86_x86_4.0.30319.1008.dll dla aplikacji 32-bitowej i odnosi wiele sukcesów.
Istnieje jedna dodatkowa zmarszczka, chociaż wth ClrMD. Możesz skończyć z biblioteką ClrMD, próbując uzyskać dodatkowe nazwane wersje DAC, w zależności od bit-ności, której używasz jako celu kompilacji dla kompilacji Visual Studio za pomocą ClrMD.
Kiedy zbudowałem swoją pierwszą testową wiązkę ClrMd na 64-bitową platformę docelową, ClrMd szukał biblioteki o nazwie mscordacwks_x86_amd64_4.0.30319.1008.dll zamiast nazwy "... x86_x86 ...". Pomimo tego, że uruchamiałem moją uprząż testową przeciwko aplikacji 32-bitowej, zmiana nazwy DAC z jednej z dwóch wymienionych wyżej nazw nie sprawdziła się. (Nie mówię, że nie miałem nic złego, tylko, że to nie działało dla mnie, twój przebieg może się różnić.)
Jednak, gdy zmieniłem cel kompilacji w VS2010 na 32-bitowy , wersja 0.8.5 "fixed" natychmiast załadowała poprawnie przemianowaną bibliotekę mscordacwks_x86_x86_4.0.30319.1008 bez dalszych problemów.
Chyba próbuje załadować DAC X86_Amd64, gdy 32-bitowy zrzut procesu został utworzony przez narzędzie 64-bitowe. https://blogs.msdn.microsoft.com/tess/2010/09/29/capturing-memory-dumps-for-32-bit-processes-on-an-x64-machine/ –