"विफलता लोडिंग डीएसी: CreateDacInstance विफल" ClrMD

Question

के साथ डंप फ़ाइल लोड करते समय मैं क्रैश-डंप और लाइव प्रक्रिया का विश्लेषण करने के लिए माइक्रोसॉफ्ट, ClrMD से नई लाइब्रेरी का प्रयास कर रहा हूं।

मैंने .NET Framework blog post (attached .cs file का उपयोग करके) में नमूना का पालन किया है।

मैंने नमूना चलाने के लिए नमूना चलाने के लिए नमूना चलाने की कोशिश की। नमूना के समान मशीन पर चल रहे प्रोग्राम से लिया गया था।

जब निम्न कोड का उपयोग कर चलाते समय वस्तु बनाने के लिए कोशिश कर रहा है,:

ClrRuntime runtime = target.CreateRuntime(dacLocation); 

यह अपवाद फेंक दिया जाता है:

संदेश: लोड करना विफल डीएसी: CreateDacInstance में विफल रहा है 0x80131c30

Microsoft.Diagnostics.Runtime.Desktop.DacLibrary.Init (स्ट्रिंग डीएल)

माइक्रो पर soft.Diagnostics.Runtime.Desktop.DacLibrary..ctor (DbgEngTarget dataTarget, स्ट्रिंग dll)

Microsoft.Diagnostics.Runtime.DbgEngTarget.CreateRuntime पर

(स्ट्रिंग dacFilename)

DumpFetch.App..ctor पर()

कोई विचार?

Answer 1

मुझे क्लैएमडी की प्रारंभिक रिलीज के साथ समान समस्याएं थीं। यह सफलतापूर्वक एक MSCORDACWKS लोड करने में असमर्थ था जो WinDbg को खुशी से स्वीकार किया गया था, जिस तरह से मैंने क्ल्रेम के लिए उपलब्ध कराया था, और उसी डंप के खिलाफ WinDbg के साथ सफलतापूर्वक उपयोग कर सकता था। डीबगडिआग v2 की प्रारंभिक रिलीज के साथ भी यही बात हुई, जिसे मैं समझता हूं, क्ल्रेमएम पर आधारित है। मैंने डीबगडिआग के प्रतीक पथ पर उपलब्ध WinDbg द्वारा स्वीकार किए गए समान नामित डीएसी को बनाया और डीबगडिआग ने विश्लेषण को निरस्त कर दिया; कह रही है कि [प्रदान किया गया] "mscordacwk.dlls" टाइमस्टैम्प और आकार डंप में से किसी से मेल नहीं खाता है "; हालांकि प्रोमॉन के माध्यम से लोड प्रयास के बाद स्पष्ट रूप से पता चला कि यह WinDbg- स्वीकृत नाम के माध्यम से सही DLL तक पहुंच रहा था।

हालांकि, डीएसी लोड करने में डीबगडिएग v2 अक्षमता पर हमारी माइक्रोसॉफ्ट टीम के साथ काम करते समय, मैं अपने टीएएम को "निश्चित" क्लर्मएम की प्रारंभिक प्रति प्रदान करने में सक्षम था जिसे क्ल्रेमएम 0.8.5 के रूप में नामित किया गया था मेरे लिए ऐसे मुद्दों का समाधान किया। यह अल्फा बिल्ड है और मैं इसे फिर से वितरित करने के लिए अधिकृत नहीं हूं, लेकिन कम से कम आप जंगली में उस संस्करण या 0.8.5 से एक नया देख सकते हैं।

एक और बात: उपयुक्त 32-बिट या 64-बिट WinDbg का उपयोग करते समय, आप आमतौर पर MSCORDACWKS के केवल दो नामित संस्करणों से दूर हो सकते हैं: एक 64-बिट के लिए और 32-बिट के लिए एक। इसलिए किसी अन्य मशीन से .NET 4.0.0319.1008 के लिए MSCORDACWKS लोड करने के लिए, उदाहरण के लिए, आप डंप लक्ष्य होस्ट का 64-बिट संस्करण C: \ Windows \ Microsoft.NET \ Framework64 से mscordacwks_AMD64_AMD64_4.0.31319.1008.dll के लिए नाम बदल सकते हैं 64-बिट ऐप और 32-बिट ऐप के लिए 32: बिट संस्करण का नाम बदलें: \ Windows \ Microsoft.NET \ Framework64 को 32-बिट ऐप के लिए mscordacwks_x86_x86_4.0.30319.1008.dll पर और बहुत अधिक सफल हो।

एक अतिरिक्त शिकन है, हालांकि, WTH ClrMD। आप ClrMD का उपयोग कर अपने ऐप के विजुअल स्टूडियो संकलन के लिए बिल्ड लक्ष्य के रूप में उपयोग कर रहे बिट-नेस के आधार पर डीएसी के अतिरिक्त नामित संस्करणों के लिए प्रयास कर रहे क्लैएमडी लाइब्रेरी के साथ समाप्त कर सकते हैं।

जब मैं आदत से बाहर एक 64-बिट लक्ष्य मंच के लिए मेरी पहली ClrMd परीक्षण दोहन बनाया, ClrMd mscordacwks_x86_amd64_4.0.30319.1008.dll "... x86_x86 ..." नाम के बजाय नामित lib लिए देख रहा था। इस तथ्य के बावजूद कि मैं 32-बिट ऐप के खिलाफ अपना परीक्षण दोहन चला रहा था, ऊपर वर्णित दो नामों में से किसी एक से डीएसी का नाम बदलना प्रतीत नहीं होता था। (मैं यह नहीं कह रहा हूं कि मेरे पास कुछ गलत नहीं था, बस यह मेरे लिए काम नहीं करता था। आपका माइलेज भिन्न हो सकता है।)

हालांकि, एक बार मैंने VS2010 में बिल्ड लक्ष्य को 32-बिट होने के बाद बदल दिया , 0.8.5 "फिक्स्ड" संस्करण ने तुरंत बिना किसी समस्या के ठीक से नामित mscordacwks_x86_x86_4.0.30319.1008 DLL लोड किया।

Answer 2

TryDownloadDac() नामक ClrVersion पर एक और तरीका है; जो सही डाउनलोड करेगा, लेकिन आपको उसी आर्किटेक्चर पर एक प्रक्रिया चलाने की आवश्यकता है, जिसे आप डिबगिंग कर रहे हैं (64 बिट एप 64 बिट डीबग करने के लिए, 32 बिट एप 32 डीब करने के लिए)। ऐसा इसलिए है क्योंकि इसे स्मृति में DAC लाइब्रेरी को लोड करने की आवश्यकता है।