डीबगशेल

विंडोज डीबगर इंजन के लिए एक PowerShell फ्रंट-एंड।

क्या आप टैब करके अपनी महिमा के लिए तैयार हैं? त्वरित परिचय के लिए, Getting Started देखें।

अस्वीकरण

1. यह परियोजना विंडोज डीबगर टीम द्वारा निर्मित, समर्थित या निगरानी नहीं की गई है। जबकि डीबगर टीम अपने API और फ्रंट एंड (windbg, kd, et al) के बारे में प्रतिक्रिया का स्वागत करती है, उनका इस परियोजना से कोई संबंध नहीं है। इस परियोजना से संबंधित बग या प्रतिक्रिया डीबगर टीम को दर्ज न करें।

2. यह एक वित्त पोषित परियोजना नहीं है: इसके लिए कोई आधिकारिक संसाधन आवंटित नहीं किए गए हैं, और केवल स्वयंसेवकों द्वारा ही काम किया जाता है। इस परियोजना पर कोई उत्पादन निर्भरता न लें जब तक कि आप इसे पूरी तरह से स्वयं समर्थन करने को तैयार न हों। बेझिझक मुद्दे दर्ज करें और पुल रिक्वेस्ट सबमिट करें, लेकिन समझें कि सीमित स्वयंसेवक संसाधनों के साथ, आपके सबमिशन को संभालने में कुछ समय लग सकता है।

3. यह एक प्रयोगात्मक परियोजना है: यह पूरी तरह से तैयार नहीं है, और आपको अक्सर ब्रेकिंग बदलावों की उम्मीद करनी चाहिए।

उपरोक्त अस्वीकरणों का परिणाम: मैं उच्च मूल्य के लाइव लक्ष्यों पर DbgShell को अटैच करने से बचूंगा।

बाइनरी

https://aka.ms/dbgshell-latest

प्रेरणा

क्या आपने कभी डीबगर में कुछ स्वचालित करने की कोशिश की है? (cdb/ntsd/kd/windbg) आपके लिए वह कैसा रहा?

DbgShell का मुख्य प्रेरणा यह है कि डीबगर में कुछ भी स्वचालित करना बहुत मुश्किल है। आज डीबगर को स्वचालित करने में सहायता के लिए सुविधाएं मौजूद हैं, बिल्कुल। लेकिन मेरी राय में वे लोगों की जरूरतों को पूरा नहीं कर रही हैं।

• अंतर्निहित स्क्रिप्टिंग भाषा का उपयोग करना रहस्यमयी, सीमित, सही करना मुश्किल और सहायता प्राप्त करना मुश्किल है।
• एक पूर्ण विकसित डीबगर एक्सटेंशन DLL लिखना बहुत शक्तिशाली है, लेकिन यह एक महत्वपूर्ण निवेश है—यादृच्छिक, वास्तविक दुनिया की समस्याओं को डीबग करते समय त्वरित, "एक-बार" की समस्याओं को हल करने के लिए बहुत महंगा है। लागत के बावजूद, बड़ी संख्या में डीबगर एक्सटेंशन मौजूद हैं। मुझे लगता है कि इतने सारे नहीं होने चाहिए; मुझे लगता है कि इतने सारे होने का एकमात्र कारण यह है कि कोई व्यवहार्य विकल्प नहीं हैं।
• बेहतर इंटरफ़ेस प्रदान करने के मौजूदा प्रयास (जैसे PowerDbg) "स्क्रैपिंग" और टेक्स्ट पार्सिंग पर आधारित हैं, जो बहुत सीमित है (वैचारिक रूप से कष्टप्रद का उल्लेख नहीं करना) और इस प्रकार वास्तव में बेहतर इंटरफ़ेस के वादे को पूरा करने में असमर्थ हैं (वे सबसे अच्छे रूप में केवल मामूली रूप से बेहतर हैं)।
• डीबगर एक्सटेंशन लिखने का आसान तरीका प्रदान करने के मौजूदा प्रयास केवल एक अस्थायी उपाय हैं जो डीबगर एक्सटेंशन विकसित करने के दर्द को संबोधित करते हैं; वे वास्तव में बड़ी समस्या का समाधान नहीं करते हैं। (उदाहरण के लिए, दो प्रमुख कमियां हैं: वे अभी भी बहुत निम्न-स्तर हैं (आपको dbgeng COM API से निपटना होगा), और कोई REPL नहीं है)
• डीबगर टीम ने हाल ही में Javascript scripting पेश किया है। Javascript पुरानी windbg स्क्रिप्टिंग भाषा की तुलना में बहुत बेहतर (और अधिक अच्छी तरह से परिभाषित) भाषा है, लेकिन मुझे लगता है कि PowerShell के कुछ फायदे हैं, जिनमें से सबसे बड़ा यह है कि वास्तव में कोई भी Javascript शेल का उपयोग नहीं करता है—PowerShell एक संयुक्त शेल और स्क्रिप्टिंग भाषा के रूप में बहुत बेहतर है।

DbgShell परियोजना का लक्ष्य ऑब्जेक्ट-आधारित PowerShell दुनिया की अच्छाई को डीबगिंग दुनिया में लाना है। जब आप किसी 'ऑब्जेक्ट' को डंप करने के लिए 'dt' करते हैं, तो आपको एक वास्तविक ऑब्जेक्ट मिलना चाहिए। स्क्रिप्टिंग PowerShell स्क्रिप्ट लिखने जितनी आसान होनी चाहिए।

DbgShell परियोजना dbgeng.dll के लिए एक PowerShell फ्रंट-एंड प्रदान करती है, जिसमें शामिल हैं:

• एक प्रबंधित "ऑब्जेक्ट मॉडल" (यदि आप चाहें तो C# से उपयोग योग्य), जो dbgeng COM API से उच्च-स्तरीय है,
• एक PowerShell "नेविगेशन प्रदाता", जो एक डीबगिंग लक्ष्य के पहलुओं को पदानुक्रमित नामस्थान के रूप में उजागर करता है (ताकि आप किसी विशेष थ्रेड पर "cd" कर सकें, स्टैक देखने के लिए "dir" टाइप कर सकें, एक फ्रेम में "cd" कर सकें, लोकल्स/रजिस्टर आदि देखने के लिए दूसरा "dir" कर सकें),
• लक्ष्य में हेरफेर करने के लिए cmdlets,
• एक कस्टम PowerShell होस्ट जो डीबगर CLI अनुभव पर बेहतर नियंत्रण की अनुमति देता है, साथ ही मानक powershell.exe होस्ट में उपलब्ध नहीं होने वाली सुविधाएँ प्रदान करता है (अर्थात्, ANSI एस्केप कोड का उपयोग करके टेक्स्ट कलराइज़ेशन के लिए समर्थन (ISO/IEC 6429 की तरह))

कस्टम होस्ट अभी भी एक कमांड-लाइन (conhost.exe-आधारित) प्रोग्राम है (ntsd/cdb/kd के अनुरूप), लेकिन इसे windbg (!DbgShell) से लागू किया जा सकता है।

स्वचालन को बहुत आसान और अधिक शक्तिशाली बनाने के अलावा, यह अन्य चिंताओं को भी संबोधित करेगा, जैसे कि उन लोगों के लिए उपयोग में आसानी जिन्हें डीबगर्स का उपयोग अक्सर नहीं करना पड़ता है। (एक शिकायत जो मैंने सुनी है वह यह है कि "जब मुझे windbg का उपयोग करने की आवश्यकता होती है, तो मैं अपना सारा समय .CHM में बिताता हूँ")

दूसरी ओर, अनुभवी windbg उपयोगकर्ताओं के लिए, एक अन्य लक्ष्य संक्रमण को यथासंभव निर्बाध बनाना है। इसलिए, उदाहरण के लिए, नामस्थान प्रदाता डेटा तक पहुँचने का एकमात्र तरीका नहीं है; आप अभी भी पारंपरिक कमांड जैसे "~3 s", "k", आदि का उपयोग कर सकते हैं।

"स्वचालन" और "स्क्रिप्टिंग" से आपका क्या अर्थ है?

मैं केवल उस प्रकार की बात नहीं कर रहा हूँ जहाँ आप एक टेक्स्ट एडिटर खोलते हैं और कुछ जटिल करने के लिए एक बड़ी स्क्रिप्ट लिखते हैं—मैं यह भी बात कर रहा हूँ कि कमांड लाइन पर सीधे अपेक्षाकृत सरल चीजें निकालने में सक्षम होना। ऐसी कई स्थितियाँ हैं जहाँ आप थोड़ी सी तर्कशक्ति का उपयोग करना चाहेंगे, लेकिन इतनी बड़ी या पुन: प्रयोज्य नहीं कि आप इसे सहेजना भी चाहें। बस "एक-लाइनर्स" जैसे "यदि खोला जा रहा फ़ाइल उपयोगकर्ता के डेस्कटॉप पर है और फ़ंक्शन Blah स्टैक पर है तो CreateFile पर ब्रेक लगाएँ" निकालना आसान होना चाहिए।

PowerShell क्यों?

मुझे स्पष्ट होने दें: मुझे PowerShell के साथ "तालमेल बिठाने" में लगभग 4 साल लग गए। मुझे लगता है कि इसमें तीखे किनारे हैं, ऐसे पहलू जो सीधे कठिन हैं, और डिज़ाइन और कार्यान्वयन दोनों में बहुत सारे बग हैं। कभी-कभी यह वास्तव में मुझे परेशान करता है। हालाँकि, PowerShell के लाभ आकर्षक हैं, और मुझे विश्वास दिलाया है कि यह इस परियोजना के लिए उपयोग करने के लिए सबसे अच्छी चीज़ है:

• यह एक स्क्रिप्टिंग वातावरण और एक CLI वातावरण दोनों है। तथ्य यह है कि इसे दोनों करना है, कुछ नकारात्मक चीजों की ओर ले जाता है जैसे कि एक अधिक कठिन सीखने की अवस्था, लेकिन अंत में यह अत्यंत सुविधाजनक है, क्योंकि आप कमांड-लाइन REPL में जल्दी से काम करने के साथ-साथ पूर्ण-विशेषताओं वाली, मजबूत स्क्रिप्ट लिखने में सक्षम होना चाहते हैं।
• यह बहुत खोजने योग्य है—Get-Command, टैब पूर्णता, फ़ाइल सिस्टम जैसे पदानुक्रमित डेटा को उजागर करने की क्षमता, सहायता प्रदान करने और संश्लेषित करने की सुविधाएँ, बहुत अच्छी हैं।
• टैब पूर्णता। मुझे पता है कि मैंने पिछले बुलेट में इसका उल्लेख किया है, लेकिन यह इतना शानदार है कि इसका अपना एक बुलेट होना चाहिए।
• ऑब्जेक्ट पाइपलाइन: PowerShell पाइपलाइन की ऑब्जेक्ट-ओरिएंटेड प्रकृति स्ट्रिंग-पार्सिंग-आधारित स्क्रिप्टिंग के बुरे पुराने दिनों की तुलना में इतनी अधिक शक्तिशाली और उपयोग में आसान है कि यह मज़ेदार भी नहीं है। कल्पना करें कि "dt" करके एक "ऑब्जेक्ट" को "डंप" करें, और वास्तव में एक ऑब्जेक्ट प्राप्त करें। DbgShell ऐसा करता है।
• लोग इसे जानते हैं: मेरा अनुमान है कि PowerShell और/या C# जानने वाले लोगों की संख्या windbg स्क्रिप्टिंग तकनीक जानने वाले लोगों की तुलना में कम से कम कुछ ऑर्डर ऑफ मैग्नीट्यूड अधिक है। इसका मतलब है कि अधिक लोग PowerShell-आधारित डीबगर को आसानी से "उठा" पाएंगे; और इसका यह भी अर्थ है कि जब लोगों को सहायता की आवश्यकता होती है, तो संभावित सहायकों का समूह बहुत बड़ा होता है (स्क्रिप्टिंग से संबंधित मुद्दों के लिए, वैसे भी)।
• PowerShell अभी भी एक सामान्य-उद्देश्य वाला शेल है: DbgShell का उपयोग करते समय, आपके पास न केवल डीबगर कमांड बल्कि आप "cd" करके फ़ाइल सिस्टम, रजिस्ट्री, AD आदि में जा सकते हैं; आप Send-MailMessage, Get-WmiObject, Invoke-WebRequest, Invoke-RestMethod निष्पादित कर सकते हैं, मनमाना प्रोग्राम चला सकते हैं, आदि।

वर्तमान स्थिति