यदि आपने अभी तक ऐसा नहीं किया है तो पहले भाग को अवश्य पढ़ें। अन्यथा, दूसरे भाग को समझना मुश्किल होगा।

प्रस्तावना

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

कार्यों की सूची:

• मुख्य () फ़ंक्शन के साथ डिबगिंग प्रारंभ करें
• प्रक्रिया का प्रारंभ पता प्राप्त करना
• प्रारंभ पते पर ब्रेकपॉइंट सेटिंग्स
• ब्रेकपॉइंट पर रुकें, निर्देश रद्द करें
• डिबगिंग को रोकना और उपयोगकर्ता कार्यों की प्रतीक्षा करना
• उपयोगकर्ता कमांड द्वारा निरंतर डिबगिंग

• CDebuggerCore - डीबग इंटरफ़ेस वर्ग

• स्रोत कोड और लाइन नंबर प्राप्त करना
• कस्टम ब्रेकपॉइंट सेट करना
• कोड ट्रेस (स्टेप-इन, स्टेप-आउट, स्टेप-ओवर)
• सशर्त विराम बिंदु
• चल रही प्रक्रिया को डीबग करना
• किसी प्रक्रिया से डिस्कनेक्ट करना, समाप्त करना या प्रतीक्षा करना?
• दुर्घटनाग्रस्त प्रक्रिया को समाप्त करना
• मैन्युअल रूप से डिबगर कनेक्ट कर रहा है

चलो डिबगिंग शुरू करते हैं!

जब आप अपने कार्यक्रम को डिबग करना चाहते हैं तो आप क्या करते हैं? खैर, अधिकांश भाग के लिए, हम डिबगिंग एप्लिकेशन शुरू करने के लिए F5 दबाते हैं और विज़ुअल स्टूडियो डीबगर प्रोग्राम को उन जगहों पर रोक देगा जहां आप ब्रेकप्वाइंट सेट करते हैं (सशर्त वाले सहित)। डीबग असिस्टेंस विफल डायलॉग बॉक्स में रिपीट बटन पर क्लिक करने से स्रोत कोड सही जगह पर खुलता है और निष्पादन बंद हो जाता है। DebugBreak या _asm int 3 को कॉल करना यही काम करता है। और यह "एप्लिकेशन को डीबग कैसे करें" विकल्पों का एक छोटा सा हिस्सा है।
शायद ही कभी या समय-समय पर, हम F11 (स्टेप-इन) को दबाकर शुरुआत से ही डिबगिंग शुरू कर देते हैं, और VS मुख्य / wmain या WinMain / wWinMain फ़ंक्शंस (या _ _ उपसर्ग के साथ) के साथ डीबग करना शुरू कर देता है। खैर, यह डीबग की जा रही प्रक्रिया का तार्किक प्रारंभ पता है। मैं इसे "तार्किक" कहता हूं क्योंकि यह वास्तविक शुरुआत पता नहीं है, जिसे मॉड्यूल के प्रवेश बिंदु के रूप में भी जाना जाता है। कंसोल अनुप्रयोगों के लिए, यह mainCRTStartup फ़ंक्शन है, जो तब मुख्य फ़ंक्शन को कॉल करता है और Visual Studio डीबगर मुख्य से शुरू होता है। Dll पुस्तकालयों का अपना प्रवेश बिंदु भी हो सकता है। यदि आप थोड़ा और जानना चाहते हैं, तो / ENTRY ध्वज जानकारी पढ़ें।
इसका मतलब यह है कि हमें एप्लिकेशन के प्रवेश बिंदु पर कार्यक्रम को रोकना चाहिए और डेवलपर को डिबगिंग जारी रखने की अनुमति देनी चाहिए। हां, मैंने मॉड्यूल के इनपुट बिंदु पर कार्यक्रम के निष्पादन को "निलंबित" कहा - प्रक्रिया पहले से ही चल रही है और अगर हम इसे निलंबित नहीं करते हैं, तो यह कहीं न कहीं समाप्त हो जाएगा। जैसे ही आप F11 दबाते हैं कॉल स्टैक (नीचे की छवि) दिखाई देगा।

प्रवेश बिंदु पर प्रक्रिया को रोकने के लिए हमें क्या करने की आवश्यकता है?
संक्षेप में:

1. प्रक्रिया प्रारंभ पता प्राप्त करें
2. इस पते पर निर्देश को बदलें - उदाहरण के लिए, इसे ब्रेकपॉइंट निर्देश के साथ बदलें (_asm int 3)
3. जैसे ही निष्पादन इस ब्रेकपॉइंट तक पहुंचता है, मूल निर्देश को पुनर्स्थापित करने के लिए प्रोग्राम स्टॉप को प्रोसेस करें
4. यदि संभव हो तो निष्पादन रोकें, कॉल स्टैक, रजिस्टर और स्रोत कोड दिखाएं
5. उपयोगकर्ता द्वारा अनुरोध के अनुसार निष्पादन जारी रखें

केवल पाँच अंक! लेकिन वास्तव में, कार्य एक आसान नहीं है।

प्रक्रिया का प्रारंभ पता प्राप्त करना

प्रविष्टि बिंदु और तार्किक * प्रविष्टि बिंदु (मुख्य / WinMain फ़ंक्शन) का शुरुआती पता एक ऐसा जंगल है! आपको इन अवधारणाओं के बारे में संक्षेप में बताने से पहले, मैं आपको इसके बारे में एक अच्छा विचार दे दूं। लेकिन पहली बात जो आपको समझनी चाहिए: इस पते पर पहला निर्देश वह बिंदु है जहां कार्यक्रम शुरू होता है, और डीबगर केवल इस पते के साथ काम करता है।
* [यह शब्द मेरे द्वारा गढ़ा गया था और केवल इस लेख के लिए प्रासंगिक है!]
यह वही है जो WinMain फ़ंक्शन विज़ुअल स्टूडियो (एनोटेशन के साथ) में असंतुष्ट रूप में दिखता है:

आप डिबगिंग शुरू करके, राइट-क्लिक करके और "असंतुष्ट कोड" का चयन करके एक ही दृश्य पर स्विच कर सकते हैं। कोड बाइट्स डिफ़ॉल्ट रूप से (हरे रंग में हाइलाइट किए गए) प्रदर्शित नहीं होते हैं, लेकिन आप उन्हें संदर्भ मेनू के माध्यम से सक्षम कर सकते हैं।
धैर्य रखें! आपको मशीन की भाषा या निर्देशकों की किसी भी बोली में निर्देश समझने की आवश्यकता नहीं है! यह सिर्फ दृष्टांत के लिए है। उपरोक्त उदाहरण में, 0x00978F10 का प्रारंभ पता है, और 8B FF पहला निर्देश है। हमें बस इसे ब्रेकपॉइंट निर्देश के साथ बदलने की आवश्यकता है। हम जानते हैं कि इस तरह के एपीआई फ़ंक्शन को डीबगब्रेक कहा जाता है, लेकिन इतने कम स्तर पर हम इसका उपयोग नहीं कर सकते हैं। X86 के लिए, ब्रेकपाइंट निर्देश _asm int 3 है। इसमें 0xCC (204) का नामकरण कोड है।
यह पता चला है कि हमें केवल एसएस के साथ बाइट 8 बी के मूल्य को बदलने की आवश्यकता है और यह बात है! जब प्रोग्राम शुरू होता है, तो EXCEPTION_BREAKPOINT कोड के साथ इस स्थान पर एक EXCEPTION_DEBUG_EVENT अपवाद फेंका जाएगा। हम जानते हैं कि हमने यह किया है और उसके बाद हम इस अपवाद को संभालते हैं जैसा हमें चाहिए। यदि आप इस पैराग्राफ को नहीं समझते हैं, तो मैं आपसे आखिरी बार पूछता हूं, पहले लेख का पहला भाग पढ़ें [http://habrahabr.ru/post/154847/]।
X86 निर्देश निश्चित लंबाई नहीं हैं, लेकिन कौन परवाह करता है? हमें यह देखने की जरूरत नहीं है कि निर्देश कितने बाइट्स (1, 2, N) लेता है। हम सिर्फ पहली बाइट बदलते हैं। अनुदेश का पहला बाइट केवल 8 बी नहीं, कुछ भी हो सकता है। लेकिन हमें यह गारंटी देनी चाहिए कि जैसे ही कार्यक्रम को जारी रखने का समय आएगा, हम मूल बाइट को पुनर्स्थापित करेंगे।
उन लोगों के लिए एक छोटी सी टिप्पणी जो सब कुछ जानते हैं और उन लोगों के लिए जो कुछ नहीं जानते हैं। सबसे पहले, ब्रेकपॉइंट्स प्रोग्राम के निष्पादन को प्रारंभ पते पर रोकने का एकमात्र तरीका नहीं हैं। एक अधिक उपयुक्त विकल्प एक बार का ब्रेकपॉइंट है, जिसे हम बाद में चर्चा करेंगे। दूसरे, सीसी निर्देश केवल ब्रेकपॉइंट निर्देश नहीं है, लेकिन हमारे लिए यह आंखों के लिए पर्याप्त है।
आरंभिक पता प्राप्त करने में कुछ कठिनाइयाँ हैं, लेकिन आपकी रुचि बनाए रखने के लिए, मैं आपको प्रारंभिक पता प्राप्त करने के लिए C ++ कोड दिखाता हूँ। CREATE_PROCESS_DEBUG_INFO संरचना में lpStartAddress सदस्य का प्रारंभ पता होता है। पहली बार डिबगिंग ईवेंट को संसाधित करते समय हम इस जानकारी को पढ़ सकते हैं:

// This is inside Debugger-loop controlled by WaitForDebugEvent, ContinueDebugEvent switch(debug_event.dwDebugEventCode) { case CREATE_PROCESS_DEBUG_EVENT: { LPVOID pStartAddress = (LPVOID)debug_event.u.CreateProcessInfo.lpStartAddress; // Do something with pStartAddress to set BREAKPOINT. ... ... 

टाइप करें CREATE_PROCESS_DEBUG_INFO :: lpStartAddress LPTHREAD_START_ROUTINE है, और मुझे लगता है कि आप जानते हैं कि यह क्या है (एक फ़ंक्शन का सूचक)। लेकिन, जैसा कि मैंने कहा, शुरुआती पते के साथ कुछ कठिनाइयाँ हैं। संक्षेप में, यह पता उस जगह के सापेक्ष है जहां एप्लिकेशन छवि को मेमोरी में लोड किया गया था। अधिक आश्वस्त होने के लिए, मैं आपको / हेडर विकल्प के साथ डंपबिन उपयोगिता आउटपुट दिखाता हूं:

 dumpbin /headers DebugMe.exe ... OPTIONAL HEADER VALUES 10B magic # (PE32) 8.00 linker version A000 size of code F000 size of initialized data 0 size of uninitialized data 11767 entry point (00411767) @ILT+1890(_wWinMainCRTStartup) 1000 base of code 

यह पता (00411767) हमारे आवेदन के डिबगिंग के दौरान lpStartAddress में संग्रहीत है। लेकिन जब मैंने विजुअल स्टूडियो के तहत डिबगिंग शुरू की, तो wWinMainCRTStartup का पता इससे अलग था (@ILT का इससे कोई लेना-देना नहीं है)।
इस प्रकार, मुझे प्रारंभ पता प्राप्त करने की पेचीदगियों की चर्चा को स्थगित करने दें और बस गेटस्टार्टड्रेस () फ़ंक्शन का उपयोग करें, जिसका कोड बाद में दिखाया जाएगा। यह सटीक पता लौटा देगा जहां ब्रेकपॉइंट सेट किया जाना चाहिए!

ब्रेकपॉइंट निर्देश को प्रारंभ पते पर निर्देश बदलें

एक बार जब हम प्रारंभ पता प्राप्त करते हैं, तो इस बिंदु पर निर्देश को एक ब्रेकपॉइंट (CC) में बदलना पूरी तरह से तुच्छ है। हमें करने की आवश्यकता है:

1. इस पते पर एक बाइट पढ़ें और इसे सहेजें
2. इसकी जगह बाइट 0xCC लिखें
3. स्पष्ट निर्देश कैश
4. डिबगिंग जारी रखें

अब आपको दो महत्वपूर्ण प्रश्न पूछने हैं:

1. निर्देश कैसे पढ़ें, लिखें और रीसेट करें?
2. हम ऐसा कब करते हैं?

पहले दूसरे प्रश्न का उत्तर दूं। हम CREATE_PROCESS_DEBUG_EVENT ईवेंट (या, आपके विवेक पर, EXCEPTION_BREAKPOINT के समय) के प्रसंस्करण के दौरान निर्देश पढ़ेंगे, लिखेंगे और रीसेट करेंगे। जब प्रक्रिया लोड होने लगती है, तो हमें वास्तविक प्रारंभ पता (मेरा मतलब CRT-Main पता) मिलता है, इस पते पर पहला निर्देश पढ़ें, इसे सहेजें और इस जगह पर 0xCC बाइट लिखें। फिर हम अपने डिबगर पर ContinueDebugEvent () कहते हैं।
बेहतर समझ के लिए, मैं आपको कोड दिखाता हूं:

 DWORD dwStartAddress = GetStartAddress(m_cProcessInfo.hProcess, m_cProcessInfo.hThread); BYTE cInstruction; DWORD dwReadBytes; // Read the first instruction ReadProcessMemory(m_cProcessInfo.hProcess, (void*)dwStartAddress, &cInstruction, 1, &dwReadBytes); // Save it! m_OriginalInstruction = cInstruction; // Replace it with Breakpoint cInstruction = 0xCC; WriteProcessMemory(m_cProcessInfo.hProcess, (void*)dwStartAddress,&cInstruction, 1, &dwReadBytes); FlushInstructionCache(m_cProcessInfo.hProcess,(void*)dwStartAddress,1); 

कोड के बारे में थोड़ा सा:
• M_cProcessInfo हमारी कक्षा का एक सदस्य है, जो CreateProcess फ़ंक्शन द्वारा पॉपुलेट की गई PROCESS_INFORMATION से अधिक कुछ नहीं है।
• GetStartAddress () फ़ंक्शन प्रक्रिया का प्रारंभ पता देता है। UIC एप्लिकेशन के लिए, यह wWinMainCRTStartup () फ़ंक्शन का पता है;
• फिर हम प्रारंभ पते पर स्थित बाइट प्राप्त करने और उसके मूल्य को बचाने के लिए ReadProcessMemory कहते हैं
• उसके बाद, हम WriteProcessMemory फ़ंक्शन का उपयोग करके इस पते पर एक ब्रेकपॉइंट निर्देश (0xCC) लिखते हैं
• निष्कर्ष में, हम FlushInstructionCache को कॉल करते हैं ताकि सीपीयू नए निर्देश को पढ़े, न कि किसी पुराने को कैश किया जाए। सीपीयू, बेशक, अनुदेश को कैश नहीं कर सकता है, लेकिन आपको हमेशा फ्लशइन्स्ट्रक्शन कैशे को कॉल करना चाहिए।
ध्यान दें कि ReadProcessMemory के लिए PROCESS_VM_READ विशेषाधिकारों की आवश्यकता होती है। इसके अलावा, WriteProcessMemory के लिए PROCESS_VM_READ की आवश्यकता होती है PROCESS_VM_OPERATION - इन सभी अनुमतियों को डीबगर को जैसे ही बनाया जाता है, यह डिबग फ़्लैग CreateProcess को पास कर देता है। इस प्रकार, हमें कुछ भी करने की आवश्यकता नहीं है और पढ़ना / लिखना हमेशा सफल होगा (मान्य मेमोरी पते के साथ, निश्चित रूप से!)।

ब्रेकपॉइंट निर्देशों को संसाधित करना और मूल निर्देश को पुनर्स्थापित करना

जैसा कि आप जानते हैं, ब्रेकपॉइंट स्टेटमेंट (EXCEPTION_BREAKPOINT) अपवाद का प्रकार है जो EXCEPTION_DEBUG_EVENT डिबगिंग ईवेंट के साथ आता है। हम EXCEPTION_DEBUG_INFO संरचना का उपयोग करके डिबगिंग घटनाओं को संभालते हैं। नीचे दिया गया कोड आपको याद रखने और समझने में मदद करेगा:

 // Inside debugger-loop switch(debug_event.dwDebugEventCode) { case EXCEPTION_DEBUG_EVENT: { EXCEPTION_DEBUG_INFO & Exception = debug_event.u.Exception; // Out of union // Exception.ExceptionCode would be the actual exception code. ... 

ऑपरेटिंग सिस्टम डिबगर को हमेशा एक ब्रेकपॉइंट निर्देश भेजेगा, जो इंगित करेगा कि प्रक्रिया लोड हो रही है। यही कारण है कि आप ब्रेकपॉइंट के पहले अपवाद पर "शुरू के पते पर ब्रेकपॉइंट निर्देश सेट कर सकते हैं"। यह सुनिश्चित करता है कि पहले के बाद के सभी ब्रेकप्वाइंट आपके हैं।
कोई फर्क नहीं पड़ता कि आपके ब्रेकप्वाइंट कहां हैं, फिर भी आपको पहले ब्रेकपॉइंट इवेंट को अनदेखा करना होगा। हालांकि डिबगर्स, जैसे कि WinDbg, आपको यह ब्रेकपॉइंट दिखाएगा, Visual Studio डीबगर इस ब्रेकपॉइंट को अनदेखा कर देगा और प्रोग्राम की तार्किक शुरुआत (मुख्य / WinMain नहीं CRT-Main) से निष्पादन शुरू करेगा।
इस प्रकार, बाधा हैंडलिंग कोड इस तरह दिखाई देगा:

 // 'Exception' is the same variable declared above switch(Exception.ExceptionRecord.ExceptionCode) { case EXCEPTION_BREAKPOINT: if(m_bBreakpointOnceHit) // Would be set to false, before debugging starts { // Handle the actual breakpoint event } else { // This is first breakpoint event sent by kernel, just ignore it. // Optionally display to the user that first BP was ignored. m_bBreakpointOnceHit = true; } break; ... 

आप प्रक्रिया प्रारंभ करने के दौरान इसे सेट करने के बजाय ब्रेकपॉइंट सेट करने के लिए किसी अन्य भाग का उपयोग कर सकते हैं। किसी भी स्थिति में, ब्रेकपॉइंट इवेंट का मुख्य प्रसंस्करण आई-पार्ट में होता है। हमें उस ब्रेकपॉइंट को संभालने की आवश्यकता है जिसे हमने प्रारंभ पते पर रखा था।
यह मुश्किल और पेचीदा हो जाता है - ध्यान केंद्रित करें, ध्यान से पढ़ें, आराम से बैठें। यदि आपके पास इस लेख को पढ़ने के दौरान ब्रेक नहीं था, तो इसे करें!
सरल शब्दों में, ब्रेकपॉइंट घटना हुई जहां हमने इसे रखा। अब हम सिर्फ निष्पादन में बाधा डालते हैं, कॉल स्टैक (और अन्य उपयोगी जानकारी) दिखाते हैं, मूल निर्देश लौटाते हैं और डिबगिंग जारी रखने के लिए उपयोगकर्ता से किसी भी कार्रवाई की प्रतीक्षा करते हैं।
कोडांतरक या मशीन कोड स्तर पर, जब एक ब्रेकपॉइंट इवेंट उत्पन्न होता था और डीबगर को भेजा जाता था, तो निर्देश को पहले ही निष्पादित कर दिया गया था, हालांकि यह आकार में केवल एक बाइट था। अनुदेश सूचक पहले ही इसी बाइट में चला गया है।
इस प्रकार, हमारे पते पर मूल निर्देशों को लिखने के अलावा, हमें प्रोसेसर रजिस्टरों को भी समायोजित करने की आवश्यकता है। हम GetThreadContext और SetThreadContext फ़ंक्शन का उपयोग करके अपनी विशेष प्रक्रिया के रजिस्टरों को प्राप्त और सेट कर सकते हैं। दोनों कार्य एक संदर्भ संरचना लेते हैं। कड़ाई से बोलते हुए, इस संरचना के सदस्य प्रोसेसर वास्तुकला पर निर्भर करते हैं। चूँकि यह लेख x86 आर्किटेक्चर के बारे में है, हम उसी संरचना की परिभाषा का पालन करेंगे जो कि winnt.h हैडर फ़ाइल में पाई जा सकती है।
यहां बताया गया है कि हम प्रवाह संदर्भ कैसे प्राप्त कर सकते हैं:

 CONTEXT lcContext; lcContext.ContextFlags = CONTEXT_ALL; GetThreadContext(m_cProcessInfo.hThread, &lcContext); ,   .  ?   EIP      .    Eip  CONTEXT.     , EIP        .    ,          ,          .      : lcContext.Eip --; // Move back one byte SetThreadContext(m_cProcessInfo.hThread, &lcContext); 

ईआईपी वह पता है जिस पर प्रोसेसर अगले निर्देश को पढ़ेगा और उसे निष्पादित करेगा। आपके पास इन कार्यों को सफलतापूर्वक करने के लिए THREAD_GET_CONTEXT और THREAD_SET_CONTEXT अधिकार हैं, और आपके पास पहले से ही हैं।
मुझे संक्षेप में दूसरे विषय पर स्विच करने दें: मूल निर्देशों को बहाल करना! चल रही प्रक्रिया में मूल निर्देश लिखने के लिए, हमें WriteProcessMemory को कॉल करना होगा, इसके बाद FlushInstructionCache। यह कैसे करना है:

 DWORD dwWriteSize; WriteProcessMemory(m_cProcessInfo.hProcess, StartAddress, &m_cOriginalInstruction, 1,&dwWriteSize); FlushInstructionCache(m_cProcessInfo.hProcess,StartAddress, 1); 

मूल निर्देश बहाल। हम ContinueDebugEvent पर कॉल कर सकते हैं। हमने क्या किया है:

1. GetThreadContext, EIP को एक, SetThreadContext से कम करें।
2. मूल निर्देशों को पुनर्स्थापित करें
3. डिबगिंग जारी रखें

अच्छा, कॉल स्टैक कहाँ है? रजिस्टर? स्रोत कोड? और कार्यक्रम कब समाप्त होगा? यह सब उपयोगकर्ता की बातचीत के बिना होगा!

निष्पादन रोकें, कॉल स्टैक, मान और स्रोत कोड पंजीकृत करें, यदि कोई हो

कॉल स्टैक को प्रदर्शित करने के लिए, हमें मौजूदा * .PDB फ़ाइलों में संग्रहीत डिबग प्रतीकों को लोड करना होगा। DbgHelp.dll से फ़ंक्शन का एक सेट हमें प्रतीकों को डाउनलोड करने, फ़ाइलों के स्रोत कोड को सूचीबद्ध करने, कॉल स्टैक का पता लगाने और बहुत कुछ करने में मदद करेगा। और यह सब बाद में माना जाएगा।
सीपीयू रजिस्टरों को प्रदर्शित करने के लिए, हमें बस वास्तविक संरचना को CONTEXT संरचना से प्रदर्शित करना होगा। दृश्य स्टूडियो डीबगर (डिबग -> विंडोज -> रजिस्टर या Alt + F5) के रूप में 10 रजिस्टरों को प्रदर्शित करने के लिए आप निम्नलिखित कोड का उपयोग कर सकते हैं:

 CString strRegisters; strRegisters.Format( L"EAX = %08X\nEBX = %08X\nECX = %08X\n" L"EDX = %08X\nESI = %08X\nEDI = %08X\n" L"EIP = %08X\nESP = %08X\nEBP = %08X\n" L"EFL = %08X", lcContext.Eax, lcContext.Ebx, lcContext.Ecx, lcContext.Edx, lcContext.Esi, lcContext.Edi, lcContext.Eip, lcContext.Esp, lcContext.Ebp, lcContext.EFlags ); 

और वह यह है! इस पाठ को उपयुक्त विंडो में प्रदर्शित करें।
उपयोगकर्ता को उपयुक्त कमांड (जारी, स्टेप-इन, स्टॉप डिबगिंग और अन्य) देने तक कार्यक्रम को रोकने के लिए, हमें कंटीन्यूब्यूवेंट को कॉल नहीं करना चाहिए। चूंकि डिबग स्ट्रीम और GUI स्ट्रीम अलग-अलग हैं, हम बस GUI स्ट्रीम को वर्तमान जानकारी प्रदर्शित करने और डिबग स्ट्रीम को फ्रीज करने के लिए कहते हैं, जब तक कि किसी प्रकार का "ईवेंट" नहीं आता है, उदाहरण के लिए, उपयोगकर्ता से।
उलझन में? शब्द "ईवेंट" उद्धरण चिह्नों में है, क्योंकि यह CreateEvent फ़ंक्शन द्वारा उत्पन्न एक ईवेंट से अधिक कुछ नहीं है। प्रोग्राम निष्पादन को रोकने के लिए, हम WaitForSingleObject (डिबगर थ्रेड में) कहते हैं। डीबगर थ्रेड को फिर से शुरू करने के लिए, हम बस GUI थ्रेड से SetEvent को कॉल करते हैं। बेशक, अपनी प्राथमिकताओं के आधार पर, आप धाराओं को सिंक्रनाइज़ करने के लिए अन्य तकनीकों का उपयोग कर सकते हैं। यह आइटम फ़ंक्शन के कार्यान्वयन का केवल एक सामान्य विचार देता है "निष्पादन को निलंबित करें - निष्पादन जारी रखें"।
अब, इस तर्क के लिए, हम कोड तर्क लिख सकते हैं:

1. GetThreadContext, EIP को एक, SetThreadContext से कम करें
2. WriteProcessMemory, FlushInstructionCache का उपयोग करके मूल निर्देश लौटाएं
3. वर्तमान रजिस्टर मान प्रदर्शित करें
4. प्रतीकात्मक सूचना के कार्यों का उपयोग करना * .PDB फाइलें, स्रोत कोड और लाइन नंबर (यदि संभव हो) प्रदर्शित करें
5. कॉल स्टैक ट्रेस फ़ंक्शन और प्रतीक सूचना फ़ंक्शंस का उपयोग करके, कॉल स्टैक प्राप्त करें और इसे प्रदर्शित करें
6. उपयोगकर्ता की प्रतिक्रिया की प्रतीक्षा है
7. उपयोगकर्ता द्वारा अनुरोध की गई घटना का निष्पादन (जारी रखें, चरण, रोकें, ...)
8. कॉल जारी करें

आश्चर्य? बहुत बढ़िया! मुझे आशा है कि आप डिबगिंग का आनंद लेंगे!
उल्लेख के लायक एक महत्वपूर्ण बिंदु यह है कि जिस थ्रेड को डीबग किया जा रहा है वह प्राथमिक थ्रेड डीबग नहीं किया जा सकता है, लेकिन इसे एक ब्रेकपॉइंट निर्देश कहना होगा। अब तक, हम अभी भी कार्यक्रम के निष्पादन को रोकने के लिए पहले ब्रेकपॉइंट इवेंट को संसाधित कर रहे हैं। लेकिन ऊपर सूचीबद्ध आठ कदम सभी डिबगिंग घटनाओं (किसी भी डीबग किए गए थ्रेड से) पर लागू होंगे जो प्रोग्राम निष्पादन को रोक सकते हैं।
ईआईपी को बदलने के साथ अभी भी छोटी कठिनाइयां हैं। मैं आपको समस्या के बारे में बताता हूं, और मैं आपको बाद में इसका समाधान दिखाऊंगा। ब्रेकपॉइंट उपयोगकर्ता द्वारा निर्धारित किया जा सकता है, और हम इन पते पर निर्देशों को सीसी के साथ भी बदलते हैं (बेशक, मूल निर्देशों को ध्यान में रखते हुए)। जैसे ही कार्यक्रम का निष्पादन अगले ब्रेकपॉइंट तक पहुंचता है, हम बस निर्देश को वापस करते हैं और उन 8 चरणों को निष्पादित करते हैं जो मैंने ऊपर वर्णित किया था। पर्याप्त विस्तार से? ठीक है, अगर हम ऐसा करते हैं, तो कार्यक्रम केवल एक बार इस स्थान पर निलंबित हो जाएगा, और यदि हम मूल निर्देशों को वापस नहीं करते हैं, तो हमें पूर्ण भ्रम हो जाता है!

वैसे भी, मुझे जारी रखने दो!
अरे हाँ! स्रोत कोड! मुझे पता है कि आप पहले से ही जानना चाहते हैं कि यह कैसे करना है!
किसी भी * .EXE और * .DLL इमेज में डीबगिंग जानकारी को * .PDB फ़ाइल में दिया जा सकता है। इसके बारे में थोड़ा सा:

• डिबगिंग की सूचना केवल तभी उपलब्ध होगी जब संकलन के दौरान लिंकर पर / DEBUG ध्वज सेट किया गया था। विज़ुअल स्टूडियो में, आप इसे प्रोजेक्ट प्रॉपर्टीज़ में बदल सकते हैं (Linker-> Debugging -> Generate Debug Info)।
• / DEBUG ध्वज का मतलब यह नहीं है कि EXE / DLL डीबग कॉन्फ़िगरेशन में बनाया जाएगा। _DEBUG / DEBUG प्रीप्रोसेसर मैक्रोज़ का संकलन समय पर किया जाता है। लेकिन बाकी लिंकिंग के दौरान पहले से ही है।
• इसका मतलब यह है कि रिलीज़ कॉन्फ़िगरेशन में भी, छवि में डीबगिंग जानकारी हो सकती है, और डीबग कॉन्फ़िगरेशन में यह नहीं हो सकता है।
• * .PDB एक्सटेंशन वाली फ़ाइल डिबगिंग जानकारी संग्रहीत करती है और आमतौर पर इसका नाम <program_name> .pdb होता है, लेकिन इसे लिंकर विकल्पों का उपयोग करके नाम बदला जा सकता है। फ़ाइल में स्रोत कोड के बारे में सभी जानकारी शामिल है: फ़ंक्शन, कक्षाएं, प्रकार और बहुत कुछ।
• लिंकर EXE / DLL छवि के हेडर में * .PDB फ़ाइल जानकारी का एक छोटा सा टुकड़ा रखता है। चूंकि यह जानकारी हेडर में रखी गई है, इसलिए यह फ़ाइल प्रदर्शन को प्रभावित नहीं करता है, केवल फ़ाइल का आकार कई बाइट्स / किलोबाइट से बढ़ता है।

डिबगिंग जानकारी प्राप्त करने के लिए, हमें DbgHelp.Dll के अंदर Sym * फ़ंक्शन का उपयोग करना होगा। यह पुस्तकालय सबसे महत्वपूर्ण स्रोत-स्तरीय डिबगिंग घटक है। इसमें कॉल स्टैक ट्रेस फ़ंक्शन और छवि / exe / dll छवि जानकारी प्राप्त करने के लिए भी है। उनका उपयोग करने के लिए, आपको Dbghelp.h और DbgHelp.lib को कनेक्ट करना होगा।
डिबगिंग जानकारी प्राप्त करने के लिए, आपको इस प्रक्रिया के लिए चरित्र हैंडलर को इनिशियलाइज़ करना होगा। चूंकि हमारी लक्ष्य प्रक्रिया डिबग्यू है, इसलिए हम इसे डिबग्यू पहचानकर्ता के साथ आरंभ करते हैं। चरित्र हैंडलर को आरंभ करने के लिए, हमें SymInitialize फ़ंक्शन को कॉल करना होगा:

 BOOL bSuccess = SymInitialize(m_cProcessInfo.hProcess, NULL, false); 

पहला पैरामीटर रनिंग प्रक्रिया का पहचानकर्ता है, जिसे प्रतीकात्मक जानकारी की आवश्यकता होती है। दूसरा पैरामीटर वह पथ है जहाँ * .PDB फ़ाइल को देखना है, जिसे अर्धविराम द्वारा अलग किया गया है। तीसरा पैरामीटर कहता है कि क्या चरित्र हैंडलर को सभी मॉड्यूल के लिए वर्णों को स्वचालित रूप से लोड करना चाहिए या नहीं।
अब नीचे की पंक्तियाँ समझ में आती हैं:

 'Debugger.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Cannot find or open the PDB file 'Debugger.exe': Loaded 'C:\Windows\SysWOW64\mfc100ud.dll', Symbols loaded. 

Visual Studio 2010 msvcrt.dll के लिए वर्ण नहीं ढूँढ सका। और mfc100ud.dll लाइब्रेरी के अपने डिबगिंग प्रतीक हैं, इसलिए विज़ुअल स्टूडियो उन्हें डाउनलोड करने में सक्षम था। संक्षेप में, इसका मतलब है कि एमएफसी पुस्तकालयों के लिए, विजुअल स्टूडियो प्रतीकात्मक जानकारी, स्रोत कोड, वर्ग / फ़ंक्शन नाम, कॉल स्टैक आदि प्रदर्शित करेगा। संबंधित पुस्तकालयों / exe फ़ाइलों के लिए प्रतीकों को स्पष्ट रूप से लोड करने के लिए, हम SymLoadModule64 / SymLoadModuleEx फ़ंक्शन को कॉल करते हैं।
हमें इन कार्यों को कहां और कब करना चाहिए? डिबगिंग चक्र से पहले (यानी किसी भी डीबगिंग इवेंट से पहले, लेकिन CreateProcess के बाद) जानकारी को इनिशियलाइज़ और लोड करने की कोशिश करते हुए मुझे बहुत समय लग गया। यह काम नहीं किया। जब CREATE_PROCESS_DEBUG_EVENT को संसाधित किया जा रहा हो, तो इसे किया जाना चाहिए। चूँकि हम निर्भर मॉड्यूल से वर्णों को स्वचालित रूप से लोड करने से इनकार करते हैं, इसलिए हमें नए लोड किए गए EXE फ़ाइल के लिए SymLoadModule64 / Ex फ़ंक्शन को कॉल करना होगा। आने वाली घटनाओं के लिए LOAD_DLL_DEBUG_EVENT, हमें भी इस फ़ंक्शन को कॉल करना होगा। मॉड्यूल की सेटिंग के आधार पर, हम या तो उपयोगकर्ता को डिबगिंग जानकारी दिखा सकते हैं या नहीं।
नीचे आप लाइब्रेरी लोडिंग इवेंट को संसाधित करते समय डिबगिंग सूचना लोडिंग कोड का एक उदाहरण देख सकते हैं। GetFileNameFromHandle फ़ंक्शन को आलेख के पिछले भाग में वर्णित किया गया है।

 case LOAD_DLL_DEBUG_EVENT: { CStringA sDLLName; sDLLName = GetFileNameFromHandle(debug_event.u.LoadDll.hFile); DWORD64 dwBase = SymLoadModule64 (m_cProcessInfo.hProcess, NULL, sDLLName, 0, (DWORD64)debug_event.u.LoadDll.lpBaseOfDll, 0); strEventMessage.Format(L"Loaded DLL '%s' at address %x.", sDLLName, debug_event.u.LoadDll.lpBaseOfDll); ... 

बेशक, समान कोड प्रक्रिया लोडिंग पर भी होगा। एक छोटा सा चेतावनी: डिबग सूचना के सफल आरंभ और इसके सफल लोडिंग का मतलब यह नहीं है कि स्रोत कोड उपलब्ध होगा! यदि उपलब्ध हो तो हमें * .PDB से जानकारी लोड करने के लिए SymGetModuleInfo64 पर कॉल करना होगा। यह कैसे करना है:

 // Code continues from above IMAGEHLP_MODULE64 module_info; module_info.SizeOfStruct = sizeof(module_info); BOOL bSuccess = SymGetModuleInfo64(m_cProcessInfo.hProcess,dwBase, &module_info); // Check and notify if (bSuccess && module_info.SymType == SymPdb) { strEventMessage += ", Symbols Loaded"; } else { strEventMessage +=", No debugging symbols found."; } 

स्टैक ट्रेसिंग पर उनके उत्कृष्ट लेख के लिए मैं जोचेन कलंबाच का बहुत आभारी हूं, जिसने मुझे स्रोत कोड और स्टैक ट्रेसिंग के बारे में जानकारी खोजने में मदद की।
जब प्रतीक प्रकार SymPdb होता है, तो हमें स्रोत कोड के बारे में जानकारी होती है। * .PDB में केवल स्रोत कोड के बारे में जानकारी होती है, स्रोत कोड स्वयं (* .h और * .cpp फ़ाइलें) निर्दिष्ट पथ पर उपलब्ध होना चाहिए! * .PDB में चरित्र नाम, फ़ाइल नाम, लाइन नंबर और बहुत कुछ शामिल हैं। यदि हमारे पास फ़ंक्शन नाम हैं, तो स्टैक ट्रेसिंग (स्रोत कोड की समीक्षा किए बिना) पूरी तरह से संभव है।
अंत में, ब्रेकपॉइंट घटना के आगमन पर, हम कॉल स्टैक प्राप्त कर सकते हैं और इसे दिखा सकते हैं। ऐसा करने के लिए, हमें StackWalk64 फ़ंक्शन को कॉल करना होगा। नीचे आप एक पट्टी-नीचे कोड नमूना देख सकते हैं जो इस फ़ंक्शन का उपयोग करता है। कृपया, पूरी तरह से समझने के लिए, जोचेन कलम्बच का लेख पढ़ा, जिसमें मैंने बात की थी।

 void RetrieveCallstack(HANDLE hThread) { STACKFRAME64 stack={0}; // Initialize 'stack' with some required stuff. StackWalk64(IMAGE_FILE_MACHINE_I386, m_cProcessInfo.hProcess, hThread, &stack, &context, _ProcessMemoryReader, SymFunctionTableAccess64, SymGetModuleBase64, 0); ... 

STACKFRAME64 एक डेटा संरचना है जिसमें पते होते हैं जिनसे कॉल स्टैक जानकारी पुनर्प्राप्त की जाती है। जैसा कि जोचेन लिखते हैं, x86 के लिए हमें StackWalk64 फ़ंक्शन को कॉल करने से पहले इस संरचना को शुरू करने की आवश्यकता है:

 CONTEXT context; context.ContextFlags = CONTEXT_FULL; GetThreadContext(hThread, &context); // Must be like this stack.AddrPC.Offset = context.Eip; // EIP - Instruction Pointer stack.AddrPC.Mode = AddrModeFlat; stack.AddrFrame.Offset = context.Ebp; // EBP stack.AddrFrame.Mode = AddrModeFlat; stack.AddrStack.Offset = context.Esp; // ESP - Stack Pointer stack.AddrStack.Mode = AddrModeFlat; 

StackWalk64 पर कॉल करते समय, पहला स्थिर मशीन का प्रकार परिभाषित करता है जो x86 है। अगला तर्क डिबग की जा रही प्रक्रिया का पहचानकर्ता है। तीसरा धागा पहचानकर्ता है जिसमें हम कॉल स्टैक प्राप्त करेंगे (जरूरी नहीं कि मुख्य धागा)। चौथा पैरामीटर हमारे लिए सबसे महत्वपूर्ण पैरामीटर है। पांचवीं संरचना का संदर्भ है, जिसमें आरंभीकरण के लिए आवश्यक पते हैं। _ProcessMemoryReader फ़ंक्शन एक फ़ंक्शन है जिसे हमने घोषित किया है कि ReadProcessMemory के अलावा कुछ भी नहीं है। अन्य दो Sym * फ़ंक्शन DbgHelp.dll से हैं। अंतिम पैरामीटर एक फ़ंक्शन पॉइंटर भी है, लेकिन हमें इसकी आवश्यकता नहीं है।
कॉल स्टैक का पता लगाने के लिए, ट्रेस समाप्त होने तक आपको निश्चित रूप से एक लूप की आवश्यकता होती है। हालांकि इस तरह के प्रश्न: अमान्य कॉल स्टैक, अंतहीन कॉल स्टैक और कुछ अन्य खुले हैं, मैंने इसे सरल बनाने का फैसला किया: फ़ंक्शन को कॉल करें जब तक कि वापसी पता NULL नहीं हो जाता, या जब तक StackWalk64 विफल नहीं हो जाता। निम्नलिखित दिखाता है कि हम कॉल स्टैक कैसे प्राप्त करेंगे (फ़ंक्शन के नाम थोड़े समय बाद होंगे):

 BOOL bSuccess; do { bSuccess = StackWalk64(IMAGE_FILE_MACHINE_I386, ... ,0); if(!bTempBool) break; // Symbol retrieval code goes here. // The contents of 'stack' would help determining symbols. // Which would put information in a vector. }while ( stack.AddrReturn.Offset != 0 ); 

डीबग प्रतीक में कई गुण होते हैं:

• मॉड्यूल नाम (exe या dll)
• प्रतीक नाम - सजाया या सजाया नहीं गया
• प्रतीक प्रकार: फ़ंक्शन, वर्ग, पैरामीटर, स्थानीय चर, आदि।
• चरित्र का आभासी पता

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

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

 IMAGEHLP_MODULE64 module={0}; module.SizeOfStruct = sizeof(module); SymGetModuleInfo64(m_cProcessInfo.hProcess, (DWORD64)stack.AddrPC.Offset, &module);  module.ModuleName      ,    .  module.MoadedImageModule       . Module.LineNumbers  ,        (1 – ).        .         ,   SymGetSymFromAddr64  SymFromAddr.       PIMAGEHLP_SYMBOL64,     6 ,     ( ,  )  SYMBOL_INFO.    ,    ,    –   .     : IMAGEHLP_SYMBOL64 *pSymbol; DWORD dwDisplacement; pSymbol = (IMAGEHLP_SYMBOL64*)new BYTE[sizeof(IMAGEHLP_SYMBOL64)+MAX_SYM_NAME]; memset(pSymbol, 0, sizeof(IMAGEHLP_SYMBOL64) + MAX_SYM_NAME); pSymbol->SizeOfStruct = sizeof(IMAGEHLP_SYMBOL64); // Required pSymbol->MaxNameLength = MAX_SYM_NAME; // Required SymGetSymFromAddr64(m_cProcessInfo.hProcess, stack.AddrPC.Offset, &dwDisplacement, pSymbol); // Retruns true on success 

इस अजीब कोड के बारे में थोड़ा सा:

• वर्ण नाम पैनकेक चर हो सकता है। इस प्रकार, हमें इस चर के लिए एक पर्याप्त बड़े बफर को आवंटित करने की आवश्यकता है। पूर्वनिर्धारित मैक्रो MAX_SYM_NAME का मूल्य 2000 है।
• IMAGEHLP_SYMBOL64 DbgHlp.dll . ( — . .), SizeOfStruct , . MaxNameLength .
• : Name (, ) Address, ( ).

SymFromAddr का उपयोग करना और SYMBOL_INFO को प्रारंभ करना बहुत समान है, और मैं इस नई सुविधा का उपयोग करना पसंद करता हूं। हालाँकि अब यह हमें कोई अतिरिक्त जानकारी नहीं दे सकता है, फिर मैं आवश्यकतानुसार इस संरचना के सभी क्षेत्रों की व्याख्या करूँगा।
अंत में, कॉल स्टैक को पूरा करने के लिए, हमें स्रोत कोड पथ और लाइन नंबर प्राप्त करने की आवश्यकता है। मैं आपको याद दिलाता हूं कि * .PDB फ़ाइल में यह जानकारी केवल तब होती है जब डिबगिंग वर्णों का लोडिंग सफल था। इसके अलावा, पीडीबी में केवल स्रोत कोड के बारे में जानकारी होती है, स्रोत कोड के बारे में नहीं।
एक पंक्ति संख्या के साथ जानकारी प्राप्त करने के लिए, हमें SymGetLineFromAddr64 का उपयोग करना होगा और इसे IMAGEHLP_LINE64 संरचना के माध्यम से प्राप्त करना होगा। यह फ़ंक्शन 4 तर्क लेता है, और पहले तीन संयोग ऊपर वर्णित फ़ंक्शन के साथ हैं। केवल सही आकार के साथ संरचना को शुरू करना आवश्यक है। यह इस तरह दिखता है:

 IMAGEHLP_LINE64 line; line.SizeOfStruct = sizeof(line); bSuccess = SymGetLineFromAddr64(m_cProcessInfo.hProcess, (DWORD)stack.AddrPC.Offset, &dwDisplacement, &line); if(bSuccess) { // Use line.FileName, and line.LineNumber } 

DbgHlp.dll से प्रतीक सुविधाओं या किसी अन्य फ़ंक्शन को डीबग करना स्रोत कोड डाउनलोड करने और उसे प्रदर्शित करने का समर्थन नहीं करता है। हमें इसे स्वयं करने की आवश्यकता है। यदि लाइन जानकारी या स्रोत कोड फ़ाइल उपलब्ध नहीं है, तो हम स्रोत कोड नहीं दिखा पाएंगे।
लेखन के समय, मैंने अभी तक यह तय नहीं किया है कि स्रोत कोड उपलब्ध नहीं होने पर क्या प्रदर्शित किया जाएगा। हम निर्देशों का एक सेट दिखा सकते हैं, लेकिन x86 निर्देश आकार में तय नहीं हैं। हम एक पंक्ति पर बाइट्स का एक क्रम दिखा सकते हैं (उदाहरण के लिए, "55 04 एफएफ 76 78 एई ...")। या हम निर्देशों को अलग कर सकते हैं और परिणाम दिखा सकते हैं। हालांकि मेरे पास x86 कोड को डिसाइड करने के लिए एक मॉड्यूल है, लेकिन यह सभी निर्देशों को नहीं समझता है।
फिलहाल, मैंने आपको एक विशिष्ट पते पर डिबगिंग को रोकने के लिए महत्वपूर्ण कदम दिखाए हैं। इनमें आधार पता प्राप्त करना, उस पते पर एक ब्रेकपॉइंट सेट करना, एक ब्रेकपॉइंट पर एक व्यवधान घटना को संभालना, मूल निर्देश को वापस करना, रजिस्टर मान प्राप्त करना, कॉल स्टैक, स्रोत कोड और यूआई में डिबगिंग जानकारी प्रदर्शित करने के बारे में बुनियादी जानकारी शामिल है। मैंने यह भी स्पष्ट किया कि हमें उपयोगकर्ता के अनुरोध के अनुसार निलंबित डिबग किए गए एप्लिकेशन को बाधित करने और जारी रखने के लिए विंडोज घटनाओं का उपयोग करने की आवश्यकता है।

डिबग किए गए एप्लिकेशन को निलंबित करें और उपयोगकर्ता के अनुरोध पर इसके निष्पादन को फिर से शुरू करें

जैसा कि पहले उल्लेख किया गया है, डिबग किए गए एप्लिकेशन को रोकने के लिए, हम बस कंटीन्यूब्यूवेंट को कॉल नहीं करते हैं। डीबगर आर्किटेक्चर का अर्थ है कि डीबग किए गए एप्लिकेशन के सभी थ्रेड भी निलंबित हैं।
यहां डिबगिंग और फिर से शुरू डिबगिंग का एक उदाहरण है (UT उपयोगकर्ता थ्रेड है, DT डीबगर थ्रेड है):
[UT] उपयोगकर्ता डीबग थ्रेड को उपयोगकर्ता इंटरफ़ेस का उपयोग करके आरंभ करता है। यह ऑपरेशन UI को आरेखित करना बंद नहीं करता है।
[DT] CreateEvent के माध्यम से डिबग ईवेंट की शुरुआत करता है।
[DT] डीबगर ने CreateProcess के माध्यम से डीबग किए गए अनुप्रयोग को लॉन्च किया और डीबगिंग चक्र में प्रवेश करता है।
[DT] डिबगर एक ब्रेकपॉइंट तक पहुंचता है, सूचना प्रदर्शित करता है, और निष्पादन को रोक देता है।
[डीटी] डिबगर WaitForSingleObject का उपयोग करता है एक निलंबित अवस्था में डीटी बनाए रखने के लिए
[केन्द्र शासित प्रदेशों] उपयोगकर्ता प्रदर्शन डिबगिंग (जारी रखें, बंद करो और समारोह दर्ज) के साथ जुड़े किसी भी कार्रवाई
[केन्द्र शासित प्रदेशों] डिबगर निष्पादन और SetEvent-अप डीटी को फिर से शुरू करने के लिए उचित कार्यों कॉल
[ डीटी] निष्पादन को जारी रखता है, उपयोगकर्ता के कार्यों का विश्लेषण करता है और डिबगिंग चक्र जारी रखता है या डीबग करना बंद कर देता है।
जब मैं आपको डिबगिंग कर्नेल का इंटरफ़ेस (वर्ग) दिखाऊंगा तो सब कुछ थोड़ा स्पष्ट हो जाएगा। यदि आपके पास एक अच्छी स्मृति है और / या आप उत्सुक हैं, तो आपको ध्यान देना चाहिए कि मैंने एक दो बातें नहीं कही हैं:
आधार पता प्राप्त करने के लिए वास्तविक कोड (GetStartAddress! फ़ंक्शन)। मैं आपको याद दिलाता हूं, CREATE_PROCESS_DEBUG_INFO :: lpStartAddress प्रारंभिक पता है, लेकिन यह हमेशा सही नहीं होता है। और ब्रेकप्वाइंट को कैसे संभालना है जिसे एक से अधिक बार रोकने की आवश्यकता है? अब जो कोड लिखा गया है वह ब्रेकपॉइंट्स को एक बार आग लगा देता है, क्योंकि वे प्रोग्राम के लिए मूल पते को सामान्य रूप से कार्य करने के लिए पुनर्स्थापित करते हैं।
किसी भी स्थिति में, मैंने DbgHelp.dll और Sym * फ़ंक्शन का वर्णन करने के बाद, मैं आपको प्रक्रिया का प्रारंभ पता प्राप्त करने का कार्य दिखा सकता हूं। फ़ंक्शन का नाम SymFromName है और यह प्रतीक का नाम लेता है, और SYMBOL_INFO लौटाता है। पिछला समान फ़ंक्शन SymGetSymFromName64, जो PIMAGEHLP_SYMBOL64 के माध्यम से जानकारी देता है। नीचे दिए गए कोड का उपयोग करके, हम SymWromName फ़ंक्शन का उपयोग करके wWinMainCRTStartup का पता प्राप्त कर सकते हैं:

 DWORD GetStartAddress( HANDLE hProcess, HANDLE hThread ) { SYMBOL_INFO *pSymbol; pSymbol = (SYMBOL_INFO *)new BYTE[sizeof(SYMBOL_INFO )+MAX_SYM_NAME]; pSymbol->SizeOfStruct= sizeof(SYMBOL_INFO ); pSymbol->MaxNameLen = MAX_SYM_NAME; SymFromName(hProcess,"wWinMainCRTStartup",pSymbol); // Store address, before deleting pointer DWORD dwAddress = pSymbol->Address; delete [](BYTE*)pSymbol; // Valid syntax! return dwAddress; } 

बेशक, यह केवल wWinmainCRTStartup पते को निकालता है, जो प्रोग्राम का शुरुआती बिंदु नहीं हो सकता है। खैर, यह हमारे लेख के दायरे से परे है, जैसे कि यह निर्धारित करना कि क्या कोई EXE फ़ाइल पीटी गई है, चाहे वह 32-बिट हो, मानवरहित कोड, यूनिकोड या एएनएसआई बिल्ड, या जैसी हो।
कस्टम ब्रेकप्वाइंट के बारे में क्या? थोड़ी देर बाद मैं इसके बारे में लिखूंगा।

CDebuggerCore - डिबगिंग-इंटरफ़ेस वर्ग

मैंने एक अमूर्त वर्ग लिखा है जिसमें डीबगिंग के लिए केवल कुछ शुद्ध वर्चुअल फ़ंक्शन की आवश्यकता है। पिछले लेख के विपरीत, जो उपयोगकर्ता इंटरफ़ेस और एमएफसी में निकटता से एकीकृत था, मैंने इस वर्ग को कुछ भी नहीं से स्वतंत्र बना दिया। मैंने इस वर्ग में देशी विंडोज पहचानकर्ता, एसटीएल और सीएसट्रिंग वर्ग का उपयोग किया। कृपया ध्यान दें कि आप <atlstr.h> कनेक्शन के माध्यम से गैर-एमएफसी अनुप्रयोगों से CString का उपयोग कर सकते हैं। यह MFC पुस्तकालयों के साथ कार्यक्रम की रचना करने के लिए आवश्यक नहीं है, बस एक हेडर फ़ाइल पर्याप्त है। यदि CString अभी भी आपको परेशान करता है, तो इसे अपने पसंदीदा स्ट्रिंग वर्ग और इसे के साथ बदलें।
यहाँ CDebuggerCore का मूल कंकाल है:

 class CDebuggerCore { HANDLE m_hDebuggerThread; // Handle to debugger thread HANDLE m_heResumeDebugging; // Set by ResumeDebugging PROCESS_INFORMATION m_cProcessInfo; // Other member not shown for now. public: // Asynchronous call to start debugging // Spawns a thread, that has the debugging-loop, which // calls following virtual functions to notify debugging events. int StartDebugging(const CString& strExeFullPath); // How the user responded to continue debugging, // it may also include stop-debugging. // To be called from UI-thread int ResumeDebugging(EResumeMode); // Don't want to listen anything! Terminate! void StopDebugging(); protected: // Abstract methods virtual void OnDebugOutput(const TDebugOutput&) = 0; virtual void OnDllLoad(const TDllLoadEvent&) = 0; virtual void OnUpdateRegisters(const TRegisters&) = 0; virtual void OnUpdateCallStack(const TCallStack&) = 0; virtual void OnHaltDebugging(EHaltReason) = 0; }; 

कुछ पाठकों को यह वर्ग पसंद नहीं आ सकता है। लेकिन डिबगर कोड कैसे काम करता है, यह समझाने के लिए मुझे कोड खुद लिखना होगा!
चूंकि यह वर्ग सार है, इसलिए इसे कुछ अन्य वर्ग के लिए आधार होना चाहिए और सभी आभासी तरीकों (ऑन *) को अतिभारित किया जाना चाहिए। कहने की जरूरत नहीं है, इन आभासी कार्यों को विभिन्न डिबगिंग घटनाओं के आधार पर मुख्य वर्ग से बुलाया जाता है। किसी वर्चुअल फ़ंक्शन को रिटर्न वैल्यू की आवश्यकता नहीं होती है, इसलिए आप कार्यान्वयन को खाली छोड़ सकते हैं।
मान लीजिए आपने CDebuggerCore से विरासत में मिली CDebugger क्लास बनाई और सभी वर्चुअल फ़ंक्शंस को लागू किया। तब आप इस कोड से डिबगिंग शुरू कर सकते हैं:

 // In header, or at some persist-able location CDebugger theDebugger; // The point in code where you ask it to start debugging: theDebugger.StartDebugging("Path to executable"); 

जो बस डिबग राज्य को सेट करने के लिए आवश्यक चर को इनिशियलाइज़ करता है, इवेंट हैंडलर बनाता है जिसे मैंने ऊपर लिखा था, और डीबग स्ट्रीम शुरू करता है। उसके बाद, विधि समाप्त होती है - इसका मतलब है कि StartDebugging अतुल्यकालिक है।
वास्तव में, डीबगिंग लूप डीबगर थ्रेड विधि में है (यह इस कोड में नहीं है)। यह CreateProcess के माध्यम से निष्पादन योग्य फ़ाइल चलाता है, डिबगिंग चक्र में प्रवेश करता है और WaitForDebugEvent और ContinueDebugEvent फ़ंक्शन का उपयोग करके अपनी प्रगति को नियंत्रित करता है। जब कोई भी डीबगिंग घटना होती है, तो यह विधि संबंधित ऑन * वर्चुअल विधियों में से एक को कॉल करती है। उदाहरण के लिए, यदि OUTPUT_DEBUG_STRING_EVENT ईवेंट आता है, तो यह स्ट्रिंग पैरामीटर के साथ OnDebugOutput को कॉल करता है। और अन्य डिबगिंग घटनाओं के लिए, यह उपयुक्त तरीके कहता है। और विरासत में मिला वर्ग पहले से ही सभी घटनाओं को ठीक से संसाधित करता है।
डिबगिंग को बाधित करने वाली कुछ डिबगिंग घटनाओं, जैसे कि ब्रेकपॉइंट इवेंट के लिए, डीबगिंग लूप पहले उपयुक्त ऑन * विधि को कॉल करेगा, और फिर उपयुक्त कोड के साथ हॉल्टबगिंग को कॉल करेगा। यह फ़ंक्शन CDebuggerCore के लिए निजी के रूप में वर्णित है, और इसे निम्नानुसार घोषित किया गया है:

 // Enum enum EHaltReason { // Reason codes, like Breakpoint }; // In CDebuggerCore private: void HaltDebugging(EHaltReason); 

इस विधि का वर्णन नीचे दिया गया है:

 void CDebuggerCore::HaltDebugging(EHaltReason eHaltReason) { // Halt the debugging OnHaltDebugging(eHaltReason); // And wait for it, until ResumeDebugging is called, which would set the event WaitForSingleObject(m_heResumeDebugging,INFINITE); } 

चूंकि डिबगिंग लूप स्टॉप के लिए सटीक कारण जानता है, इसलिए इसे हॉल्टडेबगिंग को पास करता है, जो इसे ऑनहॉलडबगिंग को दर्शाता है। ओवरहाल्टडबगिंग ओवरराइडिंग पूरी तरह से डेवलपर के साथ टिकी हुई है, और वह पहले से ही तय करता है कि इस या उस घटना को कैसे संसाधित किया जाए। इंटरफ़ेस थ्रेड स्थिर नहीं होता है, लेकिन आगे उपयोगकर्ता की प्रतिक्रिया का इंतजार करता है। डीटी को रोक दिया जाता है।
सही UI के साथ, जैसे: मेनू, हॉट की आदि। UI थ्रेड ResumeDebugging को उपयुक्त रेज़्यूमे मोड (उदाहरण के लिए, "प्रोग्राम जारी रखें (जारी रखें)", "फ़ंक्शन (StepIp) दर्ज करें" या "स्टॉप डीबगिंग (रोकें)") के साथ कॉल करता है। ResumeDebugging विधि, जो एक तर्क के रूप में एक EresumeMode ध्वज लेता है, इस ध्वज के लिए वर्ग का एक चर सदस्य सेट करता है, फिर एक घटना का संकेत करने के लिए SetEvent को कॉल करता है। यह डिबग थ्रेड को निष्पादित करना जारी रखेगा।
अब जब HaltDebugging ने एक मान लौटाया है, डीबग लूप यह जाँचता है कि उपयोगकर्ता ने क्या कार्रवाई की है। ऐसा करने के लिए, m_eResumeMode चर की जाँच करें जो कि ResumeDebugging द्वारा निर्धारित किया गया था और डीबग करना जारी रखता है; या उपयुक्त डिबगिंग आने पर पूर्ण डिबगिंग। उदाहरण के लिए, EResumeMode कुछ इस तरह दिखता है:

 // What action was initiated by user to resume enum EResumeMode { Continue, // F5 Stop, // Shift+F5 StepOver, // F10 // More .. }; 

अंतिम भाग में होगा:

• स्रोत कोड और लाइन नंबर प्राप्त करना
• कस्टम ब्रेकपॉइंट सेट करना
• कोड ट्रेस (स्टेप-इन, स्टेप-आउट, स्टेप-ओवर)
• सशर्त विराम बिंदु
• चल रही प्रक्रिया को डीबग करना
• किसी प्रक्रिया से डिस्कनेक्ट करना, समाप्त करना या प्रतीक्षा करना?
• दुर्घटनाग्रस्त प्रक्रिया को समाप्त करना
• मैन्युअल रूप से डिबगर कनेक्ट कर रहा है