.NET अनुप्रयोग की निगरानी

.NET एक प्रबंधित रनटाइम है । इसका अर्थ है कि इसमें उच्च-स्तरीय फ़ंक्शंस हैं जो आपके प्रोग्राम को आपके लिए नियंत्रित करते हैं ( परिचय से लेकर सामान्य भाषा रनटाइम (सीएलआर), 2007 :

रनटाइम कई कार्य प्रदान करता है, इसलिए उन्हें निम्नलिखित श्रेणियों में विभाजित करना सुविधाजनक है:

1. मुख्य कार्य जो दूसरों के उपकरण को प्रभावित करते हैं। इनमें शामिल हैं:
   1. कचरा संग्रह;
   2. मेमोरी एक्सेस और टाइप सिस्टम सुरक्षा हासिल करना;
   3. प्रोग्रामिंग भाषाओं के लिए उच्च-स्तरीय समर्थन।
2. अतिरिक्त कार्य - मुख्य के आधार पर काम करते हैं। कई उपयोगी कार्यक्रम उनके बिना करते हैं। इन कार्यों में शामिल हैं:
   1. AppDomains का उपयोग कर अनुप्रयोगों को अलग करना
   2. आवेदन संरक्षण और सैंडबॉक्स अलगाव।
3. अन्य कार्यों की आवश्यकता सभी रनटाइम द्वारा होती है, लेकिन वे मूल सीएलआर कार्यों का उपयोग नहीं करते हैं। इस तरह की सुविधाएँ पूर्ण प्रोग्रामिंग वातावरण बनाने की इच्छा को दर्शाती हैं। इनमें शामिल हैं:
   
   1. संस्करण नियंत्रण;
   2. डिबगिंग / प्रोफाइलिंग;
   3. बातचीत सुनिश्चित करना।

यह देखा जा सकता है कि हालांकि डिबगिंग और प्रोफाइलिंग मुख्य या अतिरिक्त कार्य नहीं हैं, वे ' पूर्ण प्रोग्रामिंग वातावरण बनाने की इच्छा ' के कारण सूची में हैं।

बाकी पोस्ट में बताया गया है कि कोर सीएलआर में निगरानी , अवलोकन, और आत्मनिरीक्षण सुविधाएँ क्या मौजूद हैं, वे क्यों उपयोगी हैं, और पर्यावरण उन्हें कैसे प्रदान करता है।

निदान

सबसे पहले, नैदानिक ​​जानकारी पर ध्यान दें जो सीएलआर हमें प्रदान करता है। परंपरागत रूप से, विंडोज के लिए इवेंट ट्रैकिंग (ETW) का उपयोग इसके लिए किया गया है।
ऐसी कई घटनाएं हैं जिनके बारे में सीएलआर जानकारी प्रदान करता है। वे इसके साथ जुड़े हुए हैं:

• कचरा संग्रह (जीसी);
• जेआईटी संकलन;
• मॉड्यूल और अनुप्रयोग डोमेन;
• अवरुद्ध होने पर धागे और संघर्ष के साथ काम करते हैं;
• साथ ही कई अन्य।

उदाहरण के लिए, यहां AppDomain में लोड करने के दौरान एक घटना होती है, यहां घटना एक अपवाद को फेंकने के साथ जुड़ी हुई है , और यहां कचरा कलेक्टर के मेमोरी आवंटन चक्र के साथ है ।

पूर्ण दृश्य

यदि आप अपने .NET एप्लिकेशन से संबंधित ट्रेस सिस्टम (ETW) में घटनाओं को देखना चाहते हैं, तो मैं उत्कृष्ट PerfView टूल का उपयोग करने की सलाह देता हूं और इन प्रशिक्षण वीडियो या PerfView की इस प्रस्तुति के साथ शुरू करता हूं: अंतिम .NET प्रदर्शन टूल । PerfView को अमूल्य जानकारी प्रदान करने के लिए व्यापक रूप से मान्यता प्राप्त है। उदाहरण के लिए, Microsoft इंजीनियर नियमित रूप से प्रदर्शन का विश्लेषण करने के लिए इसका उपयोग करते हैं।

आम बुनियादी ढाँचा

यदि अचानक नाम स्पष्ट नहीं है, तो ईटीडब्ल्यू में ईवेंट ट्रैकिंग केवल विंडोज के तहत उपलब्ध है, जो .NET कोर के क्रॉस-प्लेटफॉर्म वर्ल्ड के साथ बहुत अच्छी तरह से फिट नहीं है। लिनक्स के तहत प्रदर्शन का विश्लेषण करने के लिए आप परफेक्ट व्यू का उपयोग कर सकते हैं (LTTng का उपयोग करके)। हालाँकि, यह कमांड लाइन टूल, जिसे परफॉक्लेक्ट कहा जाता है, केवल डेटा एकत्र करता है। विश्लेषण क्षमता और एक समृद्ध उपयोगकर्ता इंटरफ़ेस ( फ्लेमोग्राफ सहित) वर्तमान में केवल विंडोज समाधान में उपलब्ध हैं।

लेकिन अगर आप अभी भी लिनक्स के तहत .NET प्रदर्शन का विश्लेषण करना चाहते हैं, तो अन्य दृष्टिकोण हैं:

• लिनक्स पर .NET कोर के साथ LTTng घटनाक्रम के लिए ढेर हो रही है
• लिनक्स प्रदर्शन समस्या

ऊपर दिया गया दूसरा लिंक नए EventPipe बुनियादी ढांचे की चर्चा की ओर ले जाता है, जो .NET Core (EventSources & EventListeners के अतिरिक्त) पर काम किया जा रहा है। इसके विकास लक्ष्यों को क्रॉस-प्लेटफॉर्म प्रदर्शन निगरानी डिजाइन दस्तावेज़ में पाया जा सकता है। उच्च स्तर पर, यह बुनियादी ढांचा एकल स्थान बनाएगा जहां सीएलआर निदान और प्रदर्शन से संबंधित घटनाओं को भेजेगा। फिर इन घटनाओं को एक या एक से अधिक लॉगर पर पुनर्निर्देशित किया जाएगा, उदाहरण के लिए, इसमें ETW, LTTng और BPF शामिल हो सकते हैं। ओएस या प्लेटफॉर्म जिस पर सीएलआर चल रहा है, उसके आधार पर आवश्यक लकड़हारा निर्धारित किया जाएगा। विभिन्न लॉगिंग प्रौद्योगिकियों के पेशेवरों और विपक्षों के विस्तृत विवरण के लिए, .NET क्रॉस-प्लेट प्रदर्शन और ईवेंटिंग डिज़ाइन देखें ।

EventPipes प्रगति की निगरानी प्रदर्शन परियोजना और संबंधित 'EventPipe' मुद्दों के माध्यम से की जाती है।

भविष्य की योजना

अंत में, प्रदर्शन प्रोफ़ाइल नियंत्रक बनाने की योजना है, जिसमें निम्नलिखित कार्य हैं:

नियंत्रक को सरल और क्रॉस-प्लेटफ़ॉर्म तरीके से प्रदर्शन निदान के लिए जिम्मेदार .NET घटकों द्वारा उत्पन्न प्रोफाइलिंग अवसंरचना और वर्तमान प्रदर्शन डेटा का प्रबंधन करना चाहिए।

योजना के अनुसार, कंट्रोलर को HTTP सर्वर के माध्यम से निम्नलिखित कार्यक्षमता प्रदान करनी चाहिए, जो सभी आवश्यक डेटा को प्राप्त कर सकता है:

अन्य एपीआई

• सिद्धांत 1: सरल रूपरेखा: समय अवधि X के रनटाइम को प्रोफाइल करें और ट्रेस लौटाएं।
• सिद्धांत 1: उन्नत रूपरेखा: ट्रैकिंग शुरू करना (कॉन्फ़िगरेशन के साथ)
• सिद्धांत 1: उन्नत रूपरेखा: पूर्ण ट्रैकिंग (इस कॉल का उत्तर ट्रेस ही होगा)।
• सिद्धांत 2: सभी EventCounters या एक विशिष्ट EventCounter से जुड़े आंकड़े प्राप्त करें।

HTML ब्राउज़ करने योग्य पृष्ठ

• सिद्धांत 1: एक प्रक्रिया में प्रबंधित कोड के सभी ढेर का एक पाठीय प्रतिनिधित्व।
  
  • एक साधारण नैदानिक ​​रिपोर्ट के रूप में उपयोग के लिए चल रही प्रक्रियाओं का स्नैपशॉट बनाता है।
• सिद्धांत 2: EventCounters काउंटरों की वर्तमान स्थिति (संभवतः एक इतिहास के साथ) प्रदर्शित करना।
  
  • मौजूदा काउंटरों और उनके मूल्यों का अवलोकन प्रदान करता है।
  • UNSOLVED PROBLEM: मुझे नहीं लगता कि EventCounters को गिनने के लिए आवश्यक सार्वजनिक API हैं।

मैं वास्तव में यह देखना चाहता हूं कि प्रदर्शन रूपरेखा नियंत्रक (पीपीसी?) के साथ क्या होता है। मुझे लगता है कि अगर इसे सीएलआर में बनाया जाता है, तो यह .NET को कई लाभ देगा। ऐसी कार्यक्षमता अन्य रनटाइम में मौजूद है ।

रूपरेखा

एक और प्रभावी उपकरण है कि सीएलआर एक रूपरेखा एपीआई है। यह (मुख्य रूप से) थर्ड-पार्टी टूल्स द्वारा निम्न स्तर पर रनटाइम से कनेक्ट करने के लिए उपयोग किया जाता है। आप इस समीक्षा से एपीआई के बारे में अधिक जान सकते हैं, लेकिन उच्च स्तर पर, आप इसका उपयोग कॉलबैक बनाने के लिए कर सकते हैं जो यदि सक्रिय हैं:

• कचरा कलेक्टर से संबंधित घटनाएं;
• अपवाद फेंक दिए जाते हैं;
• असेंबलियों को लोड / अनलोड किया जाता है;
• और भी बहुत कुछ ।

बीओटीआर प्रोफाइलिंग एपीआई पेज से चित्र - अवलोकन

इसके अलावा, इसमें अन्य प्रभावी विशेषताएं हैं। सबसे पहले, आप उन हैंडलर को सेट कर सकते हैं, जो हर बार .NET विधि से निष्पादित होते हैं, चाहे वह पर्यावरण में ही हो या उपयोगकर्ता कोड से। इन कॉलबैक को एंटर / लीव हैंडलर के नाम से जाना जाता है। यहां उनका उपयोग करने का एक अच्छा उदाहरण है । हालांकि, इसके लिए आपको विभिन्न ओएस और सीपीयू आर्किटेक्चर के लिए कॉलिंग सम्मेलनों को समझने की जरूरत है, जो हमेशा आसान नहीं होता है । यह भी याद रखें कि प्रोफाइलिंग एपीआई एक COM घटक है जिसे केवल C / C ++ कोड से एक्सेस किया जा सकता है, लेकिन C # / F # / VB.NET से नहीं।

दूसरे, प्रोफाइलर सेटिफ़ंक्शन बॉडी () एपीआई का उपयोग करके जेआईटी संकलन से पहले किसी भी .NET विधि के आईएल कोड को फिर से लिख सकता है । यह एपीआई वास्तव में कुशल है। यह कई APM .NET टूल्स को अंडरलाइ करता है। आप मेरी पोस्ट से इसके उपयोग के बारे में अधिक जान सकते हैं कि सीलबंद कक्षाएं और स्टैटिक विधियाँ और संबंधित कोड कैसे मॉक करें ।

ICorProfiler API

यह पता चला है कि प्रोफाइलिंग एपीआई ने काम किया है, रनटाइम वातावरण में सभी प्रकार की चाल होनी चाहिए। संलग्न पृष्ठ पर rejit की अनुमति पर चर्चा को देखें (देखें ReJIT: ReJIT पर अधिक जानकारी के लिए एक गाइड कैसे करें )।

सभी रूपरेखा एपीआई इंटरफेस और कॉलबैक की एक पूरी परिभाषा \ vm \ inc \ corprof.idl में मिल सकती है ( इंटरफ़ेस विवरण भाषा देखें)। यह 2 तार्किक भागों में विभाजित है। एक भाग Profiler -> रनटाइम एनवायरनमेंट (EE) इंटरफ़ेस है, जिसे ICorProfilerInfo रूप में जाना जाता है:

 //  ,    ICorProfilerInfo*,  //     .  ,  DLL   //          ,     //    . 

इसे निम्नलिखित फाइलों में लागू किया गया है:

• \ vm \ proftoeeinterfaceimpl.h
• \ vm \ proftoeeinterfaceimpl.inl
• \ vm \ proftoeeinterfaceimpl.cpp

दूसरा मुख्य भाग कॉलबैक है रनटाइम -> प्रोफाइलर, जो इंटरफ़ेस ICorProfilerCallback तहत वर्गीकृत किया गया है:

 //       //  ICorProfilerCallaback* .       // ,     EEToProfInterfaceImpl. 

ये कॉलबैक निम्न फ़ाइलों में कार्यान्वित किए जाते हैं:

• vm \ eetoprofinterfaceimpl.h
• vm \ eetoprofinterfaceimpl.inl
• vm \ eetoprofinterfaceimpl.cpp
• vm \ eetoprofinterfacewrapper.inl

अंत में, यह ध्यान देने योग्य है कि प्रोफाइलिंग API .NET OS पर चलने वाले सभी OS और आर्किटेक्चर पर काम नहीं कर सकती है। यहां एक उदाहरण है: लिनक्स पर ELT कॉल स्टब मुद्दों । अधिक जानकारी के लिए CoreCLR प्रोफाइलर API की स्थिति देखें।

प्रोफाइलिंग वी। डिबगिंग

एक छोटे से विषयांतर के रूप में, मुझे कहना होगा कि प्रोफाइलिंग और डीबगिंग अभी भी थोड़ा ओवरलैप करते हैं। इसलिए, यह समझना उपयोगी है कि .NET रनटाइम ( सीएलआर डिबगिंग बनाम सीएलआर प्रोफाइलिंग से लिया गया) के संदर्भ में विभिन्न एपीआई क्या प्रदान करते हैं।

सीएलआर में डिबगिंग और प्रोफाइलिंग के बीच का अंतर

डिबगिंग

डेवलपर्स अलग-अलग समझते हैं कि डिबगिंग क्या है। उदाहरण के लिए, मैंने ट्विटर पर पूछा "आप .NET प्रोग्राम को कैसे डिबग करते हैं" और बहुत सारे अलग-अलग उत्तर मिले । उसी समय, उत्तर में उपकरण और विधियों की एक अच्छी सूची थी, इसलिए मैं उन्हें देखने की सलाह देता हूं। साभार #LazzWeb

मुझे लगता है कि सभी डिबगिंग का सार इस संदेश को दर्शाता है:

सीएलआर डिबगिंग संबंधित सुविधाओं की एक विस्तृत सूची प्रदान करता है। हालांकि, इन फंडों की आवश्यकता क्यों है? इस महान पोस्ट में कम से कम तीन कारणों का उल्लेख किया गया है क्यों देशी-डीबगिंग की तुलना में डिबगिंग को प्रबंधित किया जाता है? :

1. अनवांटेड कोड को डीबग करना हार्डवेयर स्तर पर अमूर्त किया जा सकता है, लेकिन प्रबंधित कोड को डीबग करना IL-कोड स्तर पर अमूर्त होना चाहिए।
2. प्रबंधित कोड को डीबग करना बहुत अधिक जानकारी की आवश्यकता है जो निष्पादन से पहले उपलब्ध नहीं है।
3. प्रबंधित कोड डिबगर को कचरा संग्राहक (GC) के साथ समन्वयित करना होगा

इसलिए, उपयोग में आसानी के लिए, CLR को एक उच्च-स्तरीय डिबगिंग API प्रदान करना चाहिए जिसे ICorDebug नाम से जाना जाता है। यह सामान्य डिबगिंग परिदृश्य (स्रोत: BOTR) दिखाते हुए नीचे दिए गए चित्र में दिखाया गया है:

ICorDebug API

कार्यान्वयन सिद्धांत और विभिन्न घटकों का विवरण CLR डिबगिंग से लिया गया है , एक संक्षिप्त परिचय :

.Net में सभी डीबगिंग समर्थन को dll लाइब्रेरी के शीर्ष पर लागू किया जाता है, जिसे हम Dac कहते हैं। यह फ़ाइल (जिसे आमतौर पर mscordacwks.dll कहा जाता है) हमारे सार्वजनिक डिबगिंग API ( ICorDebug ) और दो निजी डीबगिंग API: SOS-Dac API और IXCLR दोनों के लिए एक संरचनात्मक तत्व है।
एक आदर्श दुनिया में, हर कोई हमारे सार्वजनिक एपीआई ICorDebug उपयोग करेगा। हालांकि, ICorDebug कई ICorDebug का अभाव है जो टूल डेवलपर्स को चाहिए। यह वह समस्या है जिसे हम ठीक करने का प्रयास कर रहे हैं। हालाँकि, ये सुधार केवल CL.v.next में मौजूद हैं, लेकिन CLR के पुराने संस्करणों में नहीं। वास्तव में, क्रैश डंप डीबगिंग समर्थन केवल CLR v4 की रिलीज़ के साथ ICorDebug API में दिखाई दिया। हर कोई जो CLR v2 में डिबगिंग के लिए क्रैश डंप का उपयोग करता है, वह ICorDebug को बिल्कुल भी लागू नहीं कर सकेगा।

(अधिक जानकारी के लिए SOS और ICorDebug देखें)

वास्तव में, ICorDebug API को 70 से अधिक इंटरफेस में विभाजित किया गया है। मैं उन सभी को नहीं दूंगा, लेकिन मैं दिखाऊंगा कि उन्हें किन श्रेणियों में विभाजित किया जा सकता है। अधिक जानकारी के लिए, ICorDebug का विभाजन देखें, जहां यह सूची प्रकाशित की गई है।

• शीर्ष स्तर : ICorDebug + ICorDebug2 - शीर्ष-स्तरीय इंटरफेस जो पूरी तरह से ICorDebugProcess ऑब्जेक्ट के संग्रह के रूप में काम करते हैं।
• कॉलबैक : प्रबंधित कोड डीबगिंग ईवेंट्स डीबगर द्वारा लागू कॉलबैक ऑब्जेक्ट के तरीकों के माध्यम से भेजे जाते हैं।
• प्रक्रिया : इंटरफेस का यह सेट काम करने वाले कोड का प्रतिनिधित्व करता है और इसमें इवेंट से संबंधित एपीआई भी शामिल हैं।
• कोड / प्रकार निरीक्षण : ज्यादातर स्थिर पीई छवियों के साथ काम करता है, लेकिन वास्तविक डेटा के लिए सुविधाजनक तरीके हैं।
• निष्पादन नियंत्रण : धागे की प्रगति की निगरानी करने की क्षमता। व्यवहार में, इसका अर्थ है कि ब्रेकपॉइंट्स (F9) सेट करने और कोड (F11 कोड प्रविष्टि, F10 कोड बाइपास, S + F11 कोड से बाहर निकलने) की क्षमता। ICorDebug निष्पादन नियंत्रण फ़ंक्शन केवल प्रबंधित कोड में काम करता है।
• थ्रेड्स + कॉल स्टैक्स : कॉल स्टैक डीबगर द्वारा कार्यान्वित निरीक्षण कार्यों के लिए आधार हैं। कॉल स्टैक के साथ काम निम्नलिखित इंटरफेस का उपयोग करके किया जाता है। ICorDebug केवल प्रबंधित कोड के डिबगिंग का समर्थन करता है और तदनुसार, आप केवल प्रबंधित कोड के स्टैक को ट्रैक कर सकते हैं।
• वस्तु निरीक्षण : ऑब्जेक्ट निरीक्षण एपीआई का एक हिस्सा है जो आपको डीबग किए गए कोड में चर के मूल्यों को देखने की अनुमति देता है। प्रत्येक इंटरफ़ेस के लिए, मैं एमवीपी विधि देता हूं, जो मुझे लगता है, इस इंटरफ़ेस के उद्देश्य का संक्षेप में वर्णन करना चाहिए।

एपीआई की रूपरेखा के साथ, डीबगिंग एपीआई सपोर्ट का स्तर ओएस और प्रोसेसर आर्किटेक्चर द्वारा भिन्न होता है। उदाहरण के लिए, अगस्त 2018 तक, प्रबंधित कोड के निदान और डीबगिंग के लिए अभी भी कोई लिनक्स एआरएम समाधान नहीं है। लिनक्स समर्थन के बारे में अधिक जानकारी के लिए, एलएलडीबी के साथ लिनक्स पर डीबगिंग .NET कोर और माइक्रोसॉफ्ट से डायग्नोस्टिक्स रिपॉजिटरी देखें, जिसका उद्देश्य लिनक्स के तहत .NET प्रोग्राम को डीबग करना आसान है।

अंत में, यदि आप यह देखना चाहते हैं कि ICorDebug API C # में कैसे दिखता है, तो CLRMD लाइब्रेरी में मौजूद रैपरों पर एक नज़र डालें, जिसमें सभी उपलब्ध कॉलबैक (CLRMD पर अधिक इस पोस्ट में बाद में चर्चा की जाएगी) शामिल हैं।

एसओएस और डीएसी

BOTR पेज पर डेटा एक्सेस कंपोनेंट (DAC) पर विस्तार से चर्चा की गई है। अनिवार्य रूप से, यह सीएलआर डेटा संरचनाओं को आउट-ऑफ-द-प्रोसेस एक्सेस प्रदान करता है ताकि उनके अंदर की जानकारी को किसी अन्य प्रक्रिया से पढ़ा जा सके। इस प्रकार, डिबगर ( ICorDebug माध्यम से) या 'सन ऑफ स्ट्राइक' (SOS) एक्सटेंशन चल रहे CLR उदाहरण या मेमोरी डंप तक पहुंच सकता है और उदाहरण के लिए:

• सभी चल रहे धागे;
• ढेर वस्तुओं का प्रबंधन किया
• मशीन कोड सहित विधि के बारे में पूरी जानकारी;
• वर्तमान स्टैक ट्रेस।

एक छोटा विषयांतर : यदि आप यह पता लगाना चाहते हैं कि ये अजीब नाम कहां से आए हैं और .NET इतिहास में एक छोटा सा सबक मिलता है, तो स्टैक ओवरफ्लो पर इस उत्तर को देखें ।

एसओएस कमांड की पूरी सूची प्रभावशाली है । यदि आप इसे WinDBG के साथ एक साथ उपयोग करते हैं, तो आप यह पता लगा सकते हैं कि आपके कार्यक्रम और सीएलआर के अंदर क्या हो रहा है। यह देखने के लिए कि सब कुछ कैसे लागू किया जाता है, आइए देखें !HeapStat , जो विभिन्न ढेर के आकारों का विवरण प्रदर्शित करता है जो .NET GC उपयोग करता है:

(एसओएस से ली गई छवि: आगामी रिलीज में कुछ नए आदेश हैं - HeapStat)

यहाँ कोड की एक धारा है जो यह दिखाती है कि SOS और DAC एक साथ कैसे काम करते हैं:

• SOS पूरी टीम !HeapStat ( लिंक )
• वर्कस्टेशन GC के साथ काम करने वाले !HeapStat में SOS कोड (लिंक)
• SOS फ़ंक्शन GCHeapUsageStats(..) , जो काम का सबसे कठिन हिस्सा करता है ( लिंक )
• साझा DacpGcHeapDetails डेटा DacpGcHeapDetails जिसमें GC ढेर, बिट मास्क और व्यक्तिगत पीढ़ियों ( संदर्भ ) जैसे मुख्य डेटा में संकेत होते हैं।
• DAC GetGCHeapStaticData फ़ंक्शन जो DacpGcHeapDetails संरचना ( लिंक ) को भरता है
• साझा DacpHeapSegmentData डेटा DacpHeapSegmentData जिसमें एक व्यक्ति GC ढेर खंड ( लिंक ) के बारे में जानकारी शामिल है
• DAC GetHeapSegmentData(..) , जो DacpHeapSegmentData संरचना ( लिंक ) को पॉप्युलेट करता है

3 पार्टी डिबगर्स

चूंकि Microsoft ने डीबगिंग एपीआई प्रकाशित किया था, इसलिए थर्ड-पार्टी डेवलपर्स ICorDebug इंटरफेस का उपयोग करने में सक्षम थे। यहां उन लोगों की एक सूची दी गई है जिन्हें मैं खोजने में कामयाब रहा:

• .NET कोर रनटाइम के लिए सैमसंग डिबगर
  
  • डीबग करने वाला आपको .NET कोर रनटाइम के तहत .NET अनुप्रयोगों में त्रुटियों को ठीक करने के लिए GDB / MI या VSCode डीबगिंग एडाप्टर इंटरफ़ेस का उपयोग करने की अनुमति देता है।
  • संभवतः उनके Tizen OS में .NET Core को पोर्ट करने के लिए एक परियोजना के भाग के रूप में लिखा गया है
• dnSpy - .NET डिबगर और असेंबली एडिटर
  
  • एक बहुत शक्तिशाली उपकरण । यह एक डिबगर, असेंबली एडिटर, हेक्स एडिटर, डिकंपाइलर और बहुत कुछ है।
• MDbg.exe (.NET फ्रेमवर्क कमांड-लाइन डीबगर)
  
  • एक NuGet पैकेज के रूप में उपलब्ध है। इसे GitHub रिपॉजिटरी या Microsoft वेबसाइट से भी डाउनलोड किया जा सकता है।
  • हालाँकि, फिलहाल MDBG .NET Core को सपोर्ट नहीं करता है। अधिक जानकारी के लिए mdbg को coreclr में पोर्ट करने के लिए CoreCLR और ETA को पोर्ट MDBG देखें।
• JetBrains 'Rider' आपको विंडोज़ पर .NET कोर डीबग करने की अनुमति देता है।
  
  • इस उपकरण के साथ कुछ लाइसेंसिंग समस्याएँ थीं।
  • अधिक जानकारी इस HackerNews थ्रेड में मिल सकती है ।

मेमोरी डंप

अंतिम बात हम मेमोरी डंप के बारे में बात करेंगे, जिसे एक कार्य प्रणाली से प्राप्त किया जा सकता है और इसके बाहर विश्लेषण किया जा सकता है। .NET रनटाइम ने हमेशा विंडोज के तहत डंपिंग मेमोरी का समर्थन किया है। और अब जब .NET कोर क्रॉस-प्लेटफ़ॉर्म बन गया है, तो उपकरण दिखाई दिए हैं जो अन्य OS पर समान कार्य करते हैं।

मेमोरी डंप का उपयोग करते समय, एसओएस और डीएसी फाइलों के सही, मिलान वाले संस्करणों को प्राप्त करना कभी-कभी मुश्किल होता है। सौभाग्य से, Microsoft ने हाल ही में dotnet symbol CLI उपकरण जारी किया है, जो:

डिबगिंग के लिए आवश्यक सभी फाइलें (कैरेक्टर सेट, मॉड्यूल, किसी विशिष्ट कोरक मॉड्यूल के लिए एसओएस और डीएसी फाइलें) किसी भी विशिष्ट कोर डंप, मिनीडंप या किसी भी समर्थित प्लेटफॉर्म की फ़ाइलों के लिए डाउनलोड कर सकते हैं, जिसमें ईएलएफ, मको, विंडोज डीएलएल, पीडीबी और पोर्टेबल शामिल हैं। PDB।

अंत में, यदि आप मेमोरी डंप का थोड़ा विश्लेषण कर रहे हैं, तो मैं उत्कृष्ट सीएलआर एमडी लाइब्रेरी पर एक नज़र डालने की सलाह देता हूं जो माइक्रोसॉफ्ट ने कई साल पहले जारी की थी। मैंने पहले से ही इसके कार्यों के बारे में लिखा था। संक्षेप में, पुस्तकालय का उपयोग करते हुए, आप एक सहज सी # एपीआई युक्त कक्षाओं के माध्यम से मेमोरी डंप के साथ काम कर सकते हैं, जो कि ClrHeap, GC Roots, CLR थ्रेड्स, स्टैक फ्रेम्स और बहुत कुछ तक पहुंच प्रदान करते हैं। वास्तव में, सीएलआर एमडी एसओएस कमांड के अधिकांश (यदि सभी नहीं) को लागू कर सकते हैं।

आप इस पोस्ट से पता लगा सकते हैं कि यह कैसे काम करता है:

ClrMD प्रबंधित लाइब्रेरी केवल CLR में आंतरिक उपयोग के लिए इच्छित API डिबगिंग के आसपास एक आवरण है। इस तथ्य के बावजूद कि ये एपीआई निदान के लिए बहुत प्रभावी हैं, हम उन्हें सार्वजनिक, प्रलेखित रिलीज के रूप में समर्थन नहीं करते हैं, क्योंकि उनका उपयोग जटिल है और सीएलआर कार्यान्वयन की अन्य विशेषताओं से निकटता से संबंधित है। ClrMD इन निम्न-स्तरीय डिबगिंग API के आसपास एक आसान-उपयोग, प्रबंधनीय आवरण प्रदान करके इस समस्या को हल करता है।