क्रैश लॉग से टेस्टेड फिक्स तक, x64 डीबगर टास्क

StatusRivet क्या करता है

• फ़ाइलेंread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep और glob चैट के वर्किंग फोल्डर के अंदर काम करते हैं, और एक काउंटर बनाई गई, संपादित और पढ़ी गई फ़ाइलों की संख्या दिखाता है।
• ShellWindows पर, WSL में या अपने स्वयं के सर्वर पर SSH के माध्यम से बिल्ड, लिनटर्स, टेस्ट और आपके डीबगर के कमांड-लाइन मोड को चलाता है; सफलता असली एग्जिट कोड द्वारा निर्धारित की जाती है, और खतरनाक कमांड्स ब्लॉक हो जाते हैं।
• वेबweb_search पेज खोजता है और http_get एक आधिकारिक दस्तावेज़ पेड पढ़ता है, उदाहरण के लिए यह देखने के लिए कि किसी एक्सेप्शन कोड का क्या अर्थ है, इससे पहले कि आप उस पर कार्रवाई करें।
• स्क्रीनशॉट और छवियाँocr एक सेव किए गए स्क्रीनशॉट, जैसे कि कोई एरर डायलॉग, से टेक्स्ट पढ़ता है, और gen_image असली इमेज फ़ाइलें सेव करता है।
• ऑर्केस्ट्रेशनtask समानांतर सब-एजेंट्स चलाता है, run_on_model एक कठिन स्टेप को एक बड़े मॉडल पर भेजता है, और skill रीयूजेबल प्लेबुक्स को संभालता है, जिसमें वर्जन कंट्रोल भी शामिल है।
• अनुमोदन मोडAuto-run तुरंत एक्शन लेता है, Ask first उन एक्शन्स से पहले रुक जाता है जो कुछ बदलते हैं, और Plan only एक प्लान लिखता है और कुछ नहीं चलाता।
• Cronएक शेड्यूल पर एक प्रॉम्प्ट चलाता है, उदाहरण के लिए एक लैब मशीन पर टेस्ट रन, और नतीजा चैट में किसी अन्य एक्शन की तरह दिखाई देता है, उसी कार्ड्स और उसी आउटपुट के साथ।
• मॉडल्सएक क्लाउड AI प्रोवाइडर एक मानक API एंडपॉइंट के माध्यम से, आपके पीसी पर एक मॉडल, या इनबिल्ट मॉडल; टेस्ट बटन एक एंडपॉइंट की जांच करता है और उसकी प्रतिक्रिया समय और कॉन्टेक्स्ट विंडो दिखाता है।

चरण दर चरण चार डिबगिंग जॉब्स

एक क्रैश कॉल स्टैक पढ़ें

टास्क: आपका अपना ऐप एक टेस्ट मशीन पर क्रैश हो गया है और आपके पास एक कॉल स्टैक है जिसे आपके x64 डीबगर ने टेक्स्ट के रूप में सेव किया है। read_file stack.txt लोड करता है, और grep लॉग में एक्सेप्शन कोड खोजता है, उदाहरण के लिए एक्सेस वॉयलेशन के लिए 0xC0000005। एजेंट फिर फॉल्टिंग थ्रेड के शीर्ष फ्रेम्स की सूची बनाता है और पहले फ्रेम से मेल खाने वाली स्रोत फ़ाइल खोलता है। हर एक्शन चैट में एक कार्ड के रूप में दिखाई देता है, और आप पूरा आउटपुट पढ़ने के लिए एक कार्ड विस्तार से देख सकते हैं। यदि एक बूट bsod इवेंट लॉग में एक kernel error 41 एंट्री छोड़ता है, तो उस समय लिखा गया डंप, यदि कोई है, उस स्थिति को रखता है जिसकी आपको आवश्यकता है। शीर्ष से शुरू करें। फ्रेम्स को खुद पढ़ें, क्योंकि एजेंट टेक्स्ट आउटपुट से काम करता है, फिर Ask first मोड में सुझाए गए diff को स्वीकार या अस्वीकार करें।

स्टैक ओवरफ्लो ठीक करें

टास्क: लॉग में 0xC00000FD दिखाई देता है, स्टैक ओवरफ्लो का एक्सेप्शन कोड, और आप उस फंक्शन को चाहते हैं जिसने रिकर्सन किया था। grep आपके स्रोत में टॉप फ्रेम्स से फंक्शन नाम खोजता है, और read_file उसे खोलता है ताकि एजेंट देख सके कि रिकर्सन कैसे समाप्त होता है। edit_file एक न्यूनतम diff सुझाता है, उदाहरण के लिए एक गायब स्टॉप कंडीशन, और ठीक दिखाता है कि कौन सी लाइनें बदल रही हैं। Shell फिर आपका बिल्ड कमांड और आपका टेस्ट कमांड चलाता है, और हर कार्ड असली एग्जिट कोड रिपोर्ट करता है। मेमोरी मैनेजमेंट स्टॉप कोड के साथ एक bsod एक अलग विफलता है, लेकिन विधि वही है: एक्सेप्शन खोजें, स्टैक पढ़ें, एक समय में एक बदलाव टेस्ट करें। हर बदलाव छोटा रखें। diff और टेस्ट नतीजे की समीक्षा करें इससे पहले कि आप कुछ भी रखें, और अंतिम एडिट के बाद टेस्ट को एक बार फिर चलाएं।

JIT डिबगिंग सेटिंग जांचें

टास्क: एक क्रैश-टाइम डीबगर पर भरोसा करने से पहले, एक टेस्ट मशीन पर JIT डिबगिंग वैल्यू की जांच करें। JIT का अर्थ है जस्ट-इन-टाइम: जब एक ऐप्लिकेशन क्रैश होता है तो विंडोज़ स्वचालित रूप से एक डीबगर शुरू करता है, और यह एक सिस्टम सेटिंग है। Shell आपको दिया गया कमाड चलाता है वर्तमान मान पढ़ने के लिए, और write_file उस मान को settings-before.txt में सेव करता है, ताकि पुराना मान लिखा जाए। इसे केवल एक टेस्ट मशीन पर बदलें, अपने दैनिक पीसी पर कभी नहीं, और सेव किए गए मान को बाद में वापस लाएं। Ask first मोड में एजेंट हर उस एक्शन से पहले रुक जाता है जो कुछ बदलता है, ताकि आप बदलाव और रीस्टोर को अलग-अलग अनुमोदित कर सकें। मान लिख लें। शुरू करने से पहले सेव की गई फ़ाइल पढ़ें, और मान को रीस्टोर करने से पहले इसे फिर से पढ़ें।

एक लैब टारगेट पर ड्राइवर डिबग करें

टास्क: एक ड्राइवर जिसने आप लिखा है एक टेस्ट टारगेट को क्रैश करता है और आपको फॉल्टिंग फंक्शन की आवश्यकता है। कर्नेल-लेवल वर्क आमतौर पर दो मशीनों या एक वर्चुअल मशीन की आवश्यकता होती है, एक डीबगर चला रहा है और एक टेस्ट टारगेट के रूप में, एक डिबग कनेक्शन द्वारा लिंक्ड, और टारगेट एक लैब में रहता है। Shell आपके स्वयं के लैब मशीन पर SSH के माध्यम से कमांड्स चलाता है, read_file डीबगर द्वारा सेव किए गए टेक्स्ट को पढ़ता है, और grep मॉड्यूल नाम को आपके स्रोत से मिलाता है। एक नए कंप्यूटर पर, एक dpc watchdog violation bsod आपके द्वारा लिखे गए ड्राइवर से आ सकता है, इसलिए अटके हुए थ्रेड का स्टैक पढ़ने का पहला चीज़ है। इसे एक लैब में रखें। आप हर खोज की समीक्षा करते हैं इससे पहले कि आप एक लाइन बदलें, और टेस्ट को बाद में टारगेट पर फिर से चलाते हैं।