रिमोट विंडोज डिबगर सत्र एक मशीन पर डिबगर को नेटवर्क के माध्यम से दूसरी मशीन के प्रोग्राम से अटैच करता है, और यह केवल आपकी अपनी लैब मशीनों के बीच होता है। सिम्बल्स पहले आते हैं। एक मशीन को होस्ट और दूसरी को टारगेट नाम दें। प्रोग्राम को डिबग सिम्बल्स के साथ बिल्ड करें और उसी बिल्ड के लिए मatching PDB रखें, क्योंकि गलत PDB गलत फंक्शन नाम देता है और सिम्बल्स के बिना स्टैक में केवल पते दिखाई देते हैं। StatusRivet को होस्ट पर इंस्टॉल करें, जहाँ आप काम करते हैं, और टारगेट को टेस्ट किए जा रहे प्रोग्राम तक सीमित रखें, कुछ और नहीं। किसी भी सेटिंग को नोट करें जिसे आप किसी भी मशीन पर बदलते हैं ताकि आप बाद में उसे पुनर्स्थापित कर सकें। सबसे छोटे इनपुट से क्रैश को दोहराएं, क्योंकि छोटा केस छोटा स्टैक देता है और आसान डिफ। यह जांच लें कि होस्ट और टारगेट एक-दूसरे से कनेक्ट हो सकते हैं, क्योंकि असफल कनेक्शन असफल डिबगर जैसा दिखता है।
अपने स्रोत और बिल्ड फाइलों वाले फोल्डर को चैट के वर्किंग फोल्डर के रूप में चुनें, क्योंकि फाइल टूल्स केवल उसी के अंदर पढ़ और संपादन करते हैं। सेव की गई स्टैक और नोट्स भी वहीं रखें, ताकि पूरा केस एक जगह हो और एजेंट उसकी सभी फाइलों को पढ़ सके।
Ask first उन एक्शन के बीच रुकता है जो कुछ बदलते हैं, ताकि आप उसे चलने से पहले पढ़ सकें। Plan only का उपयोग तब करें जब आप पहले स्टेप्स देखना चाहते हैं और कुछ भी न चलाएं। एक प्लान रीस्टार्ट के बाद भी बरकरार रहता है, इसलिए आप बाद में वापस आ सकते हैं।
प्रोग्राम, होस्ट और टारगेट मशीन का नाम और लक्षण बताएं, और कहें कि मशीनें आपकी हैं। अपने लैब नोट्स से कनेक्शन विवरण दें और उनका अनुमान न लगाएं। बताएं कि टारगेट पर कौन सा बिल्ड चल रहा है और उसका PDB कौन सा है।
डिफ पढ़ें, अपने बिल्ड कमांड के साथ फिर से बिल्ड करें और टारगेट पर अपना टेस्ट कमांड फिर से चलाएं। नोट्स रखें कि क्या बदला गया, और अगर नया टेस्ट फिर भी फेल होता है तो पुराना डंप रखें, ताकि अगली कोशिश यादداشت से नहीं, बल्कि सबूत से शुरू हो।
attach your debugger to the targetअटैच किया गयाsave the dump on the targetसेव किया गयाwrite the call stack to stack.txtसेव किया गयाstack.txtपढ़ा गया0xC0000005 stack.txt1 मिलान# Debug session checklist
1. Build the app with debug symbols and keep the PDB
2. Note the build the crash happened on
3. Start the debugger on the host machine
4. Attach to the app running on the target
5. Reproduce the crash with the smallest input
6. Save a crash dump on the target
7. Save the faulting thread's call stack to stack.txt
8. Read the exception code and the top frames
9. Match the first frame to a source line
10. Propose a minimal fix and rebuild
11. Run the test again and note what changedदो लैब मशीनों के बीच एक डिबगिंग सत्र के लिए एक साधारण टेक्स्ट चेकलिस्ट। इसमें सिम्बल्स के साथ बिल्ड, अटैच, सबसे छोटे इनपुट से क्रैश दोहराना, डंप और कॉल स्टैव सेव करना, शीर्ष फ्रेम पढ़ना और फिक्स के बाद टेस्ट रन शामिल है, जिसमें बदलाव के नोट्स हैं। इसे अपने प्रोजेक्ट फोल्डर में कॉपी करें और अपनी लैब के अनुसार संपादित करें। इसे कॉपी और संपादित करें।
कार्य: होस्ट मशीन से अपनी लैब टारगेट पर चल रहे अपने प्रोग्राम से अटैच करें। पहले अटैच करें। StatusRivet में प्रोजेक्ट फोल्डर खोलें, Ask first पर स्विच करें और सेटअप का वर्णन करें। Shell आपके डिबगर के कमांड-लाइन मोड को आपके द्वारा दिए गए कनेक्शन विवरण के साथ चलाता है, और कार्ड दिखाता है कि क्या यह असली एग्जिट कोड के माध्यम से अटैच हुआ। एजेंट कनेक्शन सेटिंग्स का अनुमान नहीं लगाता, इसलिए होस्ट, टारगेट और पोर्ट अपने लैब नोट्स से लें। रिमोट डिबगिंग केवल आपकी अपनी लैब मशीनों के लिए है, कभी भी उस कंप्यूटर के लिए नहीं जिसका मालिक आप नहीं हैं। अगले स्टेप से पहले कार्ड पढ़ें। अगर अटैच फेल हुआ, तो कुछ भी नहीं चलना चाहिए, और आप पहले कनेक्शन ठीक करें, फिर फिर से पूछें। कार्ड सटीक कमांड भी रखता है, ताकि आप उसे बाद में दोहरा सकें।
कार्य: टारगेट पर सबसे छोटे इनपुट से क्रैश दोहराने के बाद, सबूत सेव करें। दोनों फाइलें सेव करें। Shell आपके डिबगर को क्रैश डंप लिखने और फॉल्टिंग थ्रेड के कॉल स्टैव को एक टेक्स्ट फाइल में सेव करने के लिए कहता है, और कार्ड दोनों नतीजे दिखाते हैं। टारगेट पर विंडोज Jit डिबगर एंट्री एक ऐप्लिकेशन क्रैश होने पर स्वचालित रूप से डिबगर शुरू करती है। यह एक सिस्टम सेटिंग है, इसलिए इसे केवल टेस्ट मशीन पर बदलें, पिछली वैल्यू नोट करें और बाद में उसे पुनर्स्थापित करें। मिनीडंप से सिस्टम क्रैश का कारण खोजने के लिए, सेव किए गए कॉल स्टैव से शुरू करें। आप Ask first मोड में हर स्टेप मंजूर करते हैं, और अगले पढ़ने वाले के लिए दोनों फाइलें चेकलिस्ट के साथ रखते हैं। फाइलों का नाम बिल्ड के अनुसार रखें ताकि कोई उन्हें भ्रमित न करे।
कार्य: शीर्ष फ्रेम को अपने कोड से जोड़ें। सिम्बल्स से शुरू करें। read_file stack.txt खोलता है, grep प्रोजेक्ट में फंक्शन नाम और एक्ससेप्शन कोड (जैसे कि एक्सेस व्हायोलिएशन के लिए 0xC0000005) के लिए खोजता है, और read_file उस लाइन पर स्रोस फाइल खोलता है। matching PDB के साथ, स्टैक फंक्शन नाम, स्रोस फाइलें और लाइन नंबर दिखाता है, जबकि इसके बिना आप केवल पते देखते हैं। एक फ्रीजिंग मशीन जो kernel security check failure के साथ bsod पर समाप्त होती है, इस रूटीन के लिए मामला है: डंप, स्टैव, स्रोस। एजेंट द्वारा कुछ भी संपादित करने से पहले खुद सबूत पढ़ें, क्योंकि एजेंट टेक्स्ट से काम करता है और आपके लिए प्रोग्राम को स्टेप नहीं कर सकता। स्टेपिंग के लिए, अपने डिबगर का उपयोग करें और एजेंट को बताएं कि आपने क्या देखा।
कार्य: निष्कर्ष को बदलाव में बदलें। edit_file एक न्यूनतम डिफ प्रस्तावित करता है, उदाहरण के लिए एक मिसिंग नल चेक या बुरा इंडेक्स, और Ask first मोड में एजेंट रुक जाता है ताकि आप बदली गई लाइनों को पढ़ सकें। Shell फिर आपके बिल्ड कमांड (सिम्बल्स के साथ) और टेस्ट कमांड चलाता है, और कार्ड असली एग्जिट कोड रिपोर्ट करते हैं। आपके द्वारा लिखे गए ड्राइवर में kernel mode heap corruption bsod बुरे लिखने के बहुत बाद दिखाई दे सकता है, इसलिए केवल आखिरी फ्रेम नहीं, बल्कि स्टैव में पहले लिखे गए बफर्स की जांच करें। लैब टारगेट पर unexpected store exception bsod को उसी तरीके से हैंडल किया जाता है। टे पास होने के बाद ही डिफ स्वीकार करें, और नोट करें कि क्या बदला गया। स्वीकार करने से पहले टेस्ट करें। अगर टेस्ट फिर भी फेल होता है, तो नया स्टैव रखें और दूसरे स्टेप से लूप फिर से शुरू करें।
