🗿 📁 👊🏿 हम डिबगर विंडोज के तहत लिखते हैं [भाग 1] 🔐 😞 🙅🏻

प्रविष्टि

हम सभी, समय-समय पर, डिबगर से डिबग प्रोग्राम का उपयोग करते हैं। डीबगर का उपयोग C ++, C #, Java और सैकड़ों अन्य भाषाओं के साथ किया जा सकता है। यह या तो बाहरी (WinDbg) हो सकता है या विकास के वातावरण (विजुअल स्टूडियो) में एम्बेडेड हो सकता है। लेकिन क्या आपने कभी सोचा है कि डिबगर कैसे काम करता है?
और आप भाग्यशाली हैं। लेखों की इस श्रृंखला में हम समझेंगे कि कैसे और कैसे डीबगिंग अंदर से काम करती है। यह आलेख केवल Windows के लिए डिबगर लिखने पर चर्चा करता है। संकलक, लिंकर्स और अन्य जटिल प्रणालियों के बिना। इस प्रकार, हम केवल निष्पादन योग्य फ़ाइलों को डीबग कर सकते हैं, क्योंकि हम एक बाहरी डीबगर लिखेंगे। इस लेख को पाठक को मल्टीथ्रेडिंग की मूल बातें समझने की आवश्यकता होगी।

प्रोग्राम को डीबग कैसे करें:

ध्वज DEBUG_ONLY_THIS_PROCESS या DEBUG_PROCESS के साथ प्रक्रिया प्रारंभ करें;
एक डीबग लूप शुरू करें जो संदेशों और घटनाओं को पकड़ लेगा;

शुरू करने से पहले, याद रखें:

डीबगर एक प्रक्रिया / प्रोग्राम है जो किसी अन्य प्रक्रिया को डीबग करेगा;
डीबग्ड प्रोग्राम (ओपी) एक प्रक्रिया / प्रोग्राम है जिसे डीबग किया जाता है;
यह डिबगर है जो ओपी में शामिल होता है। इसके अलावा, डिबगर विभिन्न प्रक्रियाओं (विभिन्न थ्रेड्स में) से जुड़ सकता है;
केवल वे प्रक्रियाएँ जिन्हें डीबगर के अंतर्गत से प्रारंभ किया गया था, डीबग की जा सकती हैं। इस प्रकार, CreateProcess और डीबगर लूप एक ही थ्रेड में होना चाहिए;
जब डिबगर प्रक्रिया पूरी हो जाती है, तो यह ओपी को भी पूरा करता है;
जब डीबगर व्यस्त ईवेंट प्रसंस्करण में व्यस्त होता है, तो यह ओपी के सभी थ्रेड्स को थोड़ी देर के लिए जमा देता है। इसके बारे में बाद में;

एक डिबग ध्वज के साथ एक प्रक्रिया शुरू करना

हम CreateProcess फ़ंक्शन का उपयोग करके प्रक्रिया शुरू करते हैं और इसके छठे पैरामीटर (dwCreationFlags) में हम ध्वज DEBUG_ONLY_THIS_PROCESS को इंगित करते हैं। यह ध्वज डिबगिंग (डिबगिंग ईवेंट, प्रक्रिया प्रारंभ / समाप्ति, अपवाद, आदि) के लिए प्रारंभ की जाने वाली प्रक्रिया को तैयार करने के लिए विंडोज़ से कहता है। बाद में एक अधिक विस्तृत विवरण। कृपया ध्यान दें कि हम बिल्कुल DEBUG_ONLY_THIS_PROCESS का उपयोग करेंगे। इसका मतलब है कि हम केवल उस प्रक्रिया को डीबग करना चाहते हैं जो हम चलाते हैं, और इसके द्वारा उत्पन्न भी नहीं।

STARTUPINFO si; PROCESS_INFORMATION pi; ZeroMemory( &si, sizeof(si) ); si.cb = sizeof(si); ZeroMemory( &pi, sizeof(pi) ); CreateProcess ( ProcessNameToDebug, NULL, NULL, NULL, FALSE, DEBUG_ONLY_THIS_PROCESS, NULL,NULL, &si, &pi );

उसके बाद, आपको कार्य प्रबंधक में नई प्रक्रिया को देखना चाहिए, लेकिन वास्तव में, यह अभी तक शुरू नहीं हुआ है। नई बनाई गई प्रक्रिया अभी भी जमी हुई है। नहीं, उन्होंने अनुमान नहीं लगाया, हमें ResumeTread को कॉल करने की आवश्यकता नहीं है, लेकिन डिबगिंग चक्र लिखें।

डिबग लूप

डीबग लूप डीबगर का दिल है, और इसे WaitForDebugEvent फ़ंक्शन के आसपास बनाया गया है। यह दो मापदंडों को प्राप्त करता है: एक DEBUG_EVENT संरचना का सूचक और एक टाइमआउट (DWORD)। हम एक टाइमआउट के रूप में इन्फिनिट निर्दिष्ट करेंगे। यह फ़ंक्शन kernel32.dll में समाहित है, इसलिए हमें किसी अतिरिक्त लाइब्रेरी को लिंक करने की आवश्यकता नहीं है।

 BOOL WaitForDebugEvent(DEBUG_EVENT* lpDebugEvent, DWORD dwMilliseconds);

DEBUG_EVENT संरचना में कई डीबगिंग जानकारी शामिल होती है: एक ईवेंट कोड, एक प्रक्रिया आईडी, एक स्ट्रीम आईडी और लागू जानकारी। जैसे ही WaitForDebugEvent पूरी होती है और हमारे पास लौटती है, हमें एक डीबगर संदेश मिलता है, और फिर जारी कोड जारी रखने के लिए ContinueDebugEvent पर कॉल करें। नीचे आप न्यूनतम डिबगिंग चक्र देख सकते हैं।

 DEBUG_EVENT debug_event = {0}; for(;;) { if (!WaitForDebugEvent(&debug_event, INFINITE)) return; ProcessDebugEvent(&debug_event); // User-defined function, not API ContinueDebugEvent(debug_event.dwProcessId, debug_event.dwThreadId, DBG_CONTINUE); }

कॉन्टिन्यूडेबुज को कॉल करते हुए, हम ओएस को ओपी चलाना जारी रखने के लिए कहते हैं। dwProcessId और dwThreadId हमें प्रक्रिया और थ्रेड बताता है। हमें ये मान WaitForDebugEvent से मिले हैं। अंतिम पैरामीटर इंगित करता है कि निष्पादन जारी रखना है या नहीं। यह पैरामीटर केवल तभी प्रासंगिक होगा जब डिबगिंग में एक अपवाद फेंक दिया जाता है। हम इस पर बाद में विचार करेंगे। इस बीच, हम सिर्फ DBG_CONTINUE का उपयोग करते हैं (एक अन्य संभावित मूल्य DBG_EXCEPTION_NOT_HANDLED है)।

डिबग इवेंट्स प्राप्त करना

नौ प्रमुख डिबगिंग इवेंट और अपवाद श्रेणी में 20 उप-ईवेंट हैं। इसे सबसे सरल से शुरू करने पर विचार करें। निम्नलिखित DEBUG_EVENT की संरचना है:

 struct DEBUG_EVENT { DWORD dwDebugEventCode; DWORD dwProcessId; DWORD dwThreadId; union { EXCEPTION_DEBUG_INFO Exception; CREATE_THREAD_DEBUG_INFO CreateThread; CREATE_PROCESS_DEBUG_INFO CreateProcessInfo; EXIT_THREAD_DEBUG_INFO ExitThread; EXIT_PROCESS_DEBUG_INFO ExitProcess; LOAD_DLL_DEBUG_INFO LoadDll; UNLOAD_DLL_DEBUG_INFO UnloadDll; OUTPUT_DEBUG_STRING_INFO DebugString; RIP_INFO RipInfo; } u; };

जब WaitForDebugEvent सफल होता है, तो यह इस संरचना को पॉप्युलेट करता है। dwDebugEventCode इंगित करता है कि कौन सा डीबग इवेंट हमारे पास आया था। इस कोड के आधार पर, Union'a u के सदस्यों में से एक को घटना के बारे में जानकारी होती है। उदाहरण के लिए, यदि dwDebugEventCode == OUTPUT_DEBUG_STRING_EVENT है, तो केवल OUTPUT_DEBUG_STRING_INFO सही ढंग से भरा जाएगा।

OUTPUT_DEBUG_STRING_EVENT को संसाधित किया जा रहा है

आउटपुट के लिए टेक्स्ट को आउटपुट करने के लिए, डेवलपर्स आमतौर पर OutputDebugString फ़ंक्शन का उपयोग करते हैं। आपके द्वारा उपयोग की जा रही भाषा / रूपरेखा के आधार पर, आपको TRACE / ATLTRACE मैक्रोज़ से परिचित होना चाहिए। .NET डेवलपर System.Diagnostics.Debug.Print / System.Diagnostics.Trace.WriteLine से परिचित हो सकते हैं। लेकिन ये सभी तरीके OutputDebugString को कॉल करते हैं अगर _DEBUG मैक्रो घोषित किया जाता है और डीबगर संदेश प्राप्त करता है।
जब डिबग संदेश प्राप्त होता है, तो हम डीबगस्ट्रिंग को संसाधित करते हैं। OUTPUT_DEBUG_STRING_INFO की संरचना नीचे प्रस्तुत की गई है:

 struct OUTPUT_DEBUG_STRING_INFO { LPSTR lpDebugStringData; // char* WORD fUnicode; WORD nDebugStringLength; };

NDebugStringLength फ़ील्ड में समाप्ति नल सहित स्ट्रिंग की लंबाई है। FUnicode फ़ील्ड शून्य है यदि स्ट्रिंग ANSI है, और गैर-शून्य है यदि यह यूनिकोड है। इस मामले में, हमें nDebugStringLength X2 बाइट्स पढ़ना चाहिए। चेतावनी! lpDebugStringData में एक संदेश के साथ एक लाइन के लिए एक सूचक होता है, लेकिन सूचक को डिबग किए जाने वाले प्रोग्राम की मेमोरी के बारे में डेटा को संदर्भित करता है , न कि डीबगर को।
किसी अन्य प्रक्रिया की मेमोरी से डेटा पढ़ने के लिए, हमें ReadProcessMemory पर कॉल करना होगा और हमें ऐसा करने की अनुमति होनी चाहिए। चूंकि हमने डिबगिंग के लिए प्रक्रिया बनाई है, इसलिए समाधान के साथ कोई समस्या नहीं है।

 case OUTPUT_DEBUG_STRING_EVENT: { CStringW strEventMessage; // Force Unicode OUTPUT_DEBUG_STRING_INFO & DebugString = debug_event.u.DebugString; WCHAR *msg=new WCHAR[DebugString.nDebugStringLength]; // Don't care if string is ANSI, and we allocate double... ReadProcessMemory(pi.hProcess, // HANDLE to Debuggee DebugString.lpDebugStringData, // Target process' valid pointer msg, // Copy to this address space DebugString.nDebugStringLength, NULL); if ( DebugString.fUnicode ) strEventMessage = msg; else strEventMessage = (char*)msg; // char* to CStringW (Unicode) conversion. delete []msg; // Utilize strEventMessage }

क्या होगा अगर ऑप मेमोरी को पढ़ते समय समाप्त हो जाए?

खैर, ऐसा नहीं होगा me आपको याद दिला दूं कि डीबग संदेश को संसाधित करने के दौरान डिबगर ओपी के सभी थ्रेड्स को जमा देता है। इस प्रकार, प्रक्रिया स्वयं पूरी नहीं कर पाएगी, कोई भी कार्य प्रबंधक (मानक या नहीं) भी प्रक्रिया को पूरा करने में सक्षम नहीं होगा। यदि आप प्रयास करते हैं, तो अगले संदेश में, हमारे डिबगर को EXIT_PROCESS_DEBUG_EVENT ईवेंट प्राप्त होगा।

CREATE_PROCESS_DEBUG_EVENT प्रसंस्करण

घटना तब दिखाई देती है जब ओपी बस शुरू हो रहा होता है। यह पहला संदेश होना चाहिए जो डीबगर को प्राप्त होता है। इस संदेश के लिए, संबंधित DEBUG_EVENT फ़ील्ड CreateProcessInfo होगी। नीचे आप खुद CREATE_PROCESS_DEBUG_INFO की संरचना देख सकते हैं:

 struct CREATE_PROCESS_DEBUG_INFO { HANDLE hFile; // The handle to the physical file (.EXE) HANDLE hProcess; // Handle to the process HANDLE hThread; // Handle to the main/initial thread of process LPVOID lpBaseOfImage; // base address of the executable image DWORD dwDebugInfoFileOffset; DWORD nDebugInfoSize; LPVOID lpThreadLocalBase; LPTHREAD_START_ROUTINE lpStartAddress; LPVOID lpImageName; // Pointer to first byte of image name (in Debuggee) WORD fUnicode; // If image name is Unicode. };

कृपया ध्यान दें कि hProcess और hThread उन लोगों से भिन्न हो सकते हैं जो हमें PROCESS_INFORMATION में मिलते हैं। प्रक्रिया और थ्रेड आईडी समान होनी चाहिए। प्रत्येक हैंडल जो आपको विंडोज से मिलता है वह अलग है। इसके विभिन्न कारण हैं।
hFile, lpImageName की तरह, ओपी फ़ाइल का नाम पाने के लिए इस्तेमाल किया जा सकता है। सच है, हम पहले से ही इस फ़ाइल का नाम जानते हैं, क्योंकि हमने इसे लॉन्च किया है। लेकिन हमारे लिए EXE या DLL का स्थान जानना महत्वपूर्ण है, क्योंकि जब आप LOAD_DLL_DEBUG_EVENT संदेश प्राप्त करते हैं, तो लाइब्रेरी का नाम जानना अच्छा होगा।
जैसा कि आप MSDN पर पढ़ सकते हैं, lpImageName में कभी भी पूर्ण फ़ाइल नाम नहीं होता है और यह ओपी मेमोरी में निहित होगा। इसके अलावा, इस बात की कोई गारंटी नहीं है कि पूर्ण फ़ाइल नाम भी ओपी मेमोरी में होगा। साथ ही, फ़ाइल का नाम अधूरा हो सकता है। इसलिए, हम फ़ाइल नाम hFile से प्राप्त करेंगे।

HFile से फ़ाइल नाम कैसे प्राप्त करें

दुर्भाग्य से, हमें MSDN में वर्णित विधि का उपयोग करने की आवश्यकता होगी, जिसमें लगभग 10 फ़ंक्शन कॉल हैं। नीचे एक छोटा संस्करण है:

 case CREATE_PROCESS_DEBUG_EVENT: { CString strEventMessage = GetFileNameFromHandle(debug_event.u.CreateProcessInfo.hFile); // Use strEventMessage, and other members // of CreateProcessInfo to intimate the user of this event. }

आपने देखा होगा कि मैंने इस संरचना के कई क्षेत्रों पर विचार नहीं किया। निम्नलिखित भागों में हम इस सब पर पूरी तरह से विचार करेंगे।

LOAD_DLL_DEBUG_EVENT प्रसंस्करण

यह ईवेंट CREATE_PROCESS_DEBUG_EVENT के समान है, और जैसा कि आप अनुमान लगा सकते हैं, इस घटना को निकाल दिया जाता है जब ओएस DLL को लोड करता है। यह घटना हर बार एक DLL लोड, स्पष्ट रूप से या अंतर्निहित रूप से होती है। डीबग जानकारी केवल उस समय होती है जब DLL लोड किया गया था, और उसका वर्चुअल पता। घटना को संभालने के लिए, हम Union'a फ़ील्ड LoadDll का उपयोग करते हैं। इसमें LOAD_DLL_DEBUG_INFO टाइप है

 struct LOAD_DLL_DEBUG_INFO { HANDLE hFile; // Handle to the DLL physical file. LPVOID lpBaseOfDll; // The DLL Actual load address in process. DWORD dwDebugInfoFileOffset; DWORD nDebugInfoSize; LPVOID lpImageName; // These two member are same as CREATE_PROCESS_DEBUG_INFO WORD fUnicode; };

फ़ाइल नाम प्राप्त करने के लिए, हम GetFileNameFromHandle फ़ंक्शन का उपयोग करेंगे, उसी तरह जैसे हमने CREATE_PROCESS_DEBUG_EVENT में उपयोग किया था। जब मैं UNLOAD_DLL_DEBUG_EVENT के बारे में बात करूंगा तो मैं यह कोड दिखाऊंगा। UNLOAD_DLL_DEBUG_EVENT इवेंट में DLL लाइब्रेरी के नाम के बारे में पूरी जानकारी नहीं है।

CREATE_THREAD_DEBUG_EVENT प्रसंस्करण

यह घटना तब उत्पन्न होती है जब ओपी एक नया धागा बनाता है। लगभग CREATE_PROCESS_DEBUG_EVENT की तरह, इस घटना को एक नया धागा शुरू होने से पहले निकाल दिया जाता है। इस घटना के बारे में जानकारी प्राप्त करने के लिए, हम CreateThread फ़ील्ड का उपयोग करते हैं। CREATE_THREAD_DEBUG_INFO की संरचना नीचे वर्णित है:

 struct CREATE_THREAD_DEBUG_INFO { // Handle to the newly created thread in debuggee HANDLE hThread; LPVOID lpThreadLocalBase; // pointer to the starting address of the thread LPTHREAD_START_ROUTINE lpStartAddress; };

थ्रेड आईडी DEBUG_EVENT :: dwThreadId में उपलब्ध है, इसलिए हमारे लिए थ्रेड के बारे में सभी जानकारी प्रदर्शित करना आसान है:

 case CREATE_THREAD_DEBUG_EVENT: { CString strEventMessage; strEventMessage.Format(L"Thread 0x%x (Id: %d) created at: 0x%x", debug_event.u.CreateThread.hThread, debug_event.dwThreadId, debug_event.u.CreateThread.lpStartAddress); // Thread 0xc (Id: 7920) created at: 0x77b15e58 }

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

EXIT_THREAD_DEBUG_EVENT प्रसंस्करण

जैसे ही बच्चा थ्रेड पूरा होता है और सिस्टम में एक रिटर्न कोड देता है, यह ईवेंट उत्पन्न होता है। DEBUG_EVENT में dwThreadId फ़ील्ड में समाप्ति थ्रेड की आईडी है। CREATE_THREAD_DEBUG_EVENT से स्ट्रीम और अन्य जानकारी प्राप्त करने के लिए, हमें इस जानकारी को किसी प्रकार के सरणी में संग्रहीत करने की आवश्यकता है। इस घटना के बारे में जानकारी प्राप्त करने के लिए, हम ExitThread फ़ील्ड का उपयोग करते हैं, जो कि EXIT_THREAD_DEBUG_INFO प्रकार की है:

 struct EXIT_THREAD_DEBUG_INFO { DWORD dwExitCode; // The thread exit code of DEBUG_EVENT::dwThreadId };

नीचे घटना हैंडलर के लिए कोड है:

 case EXIT_THREAD_DEBUG_EVENT: { CString strEventMessage; strEventMessage.Format( _T("The thread %d exited with code: %d"), debug_event.dwThreadId, debug_event.u.ExitThread.dwExitCode); // The thread 2760 exited with code: 0 }

प्रसंस्करण UNLOAD_DLL_DEBUG_EVENT

बेशक, इस घटना में जानकारी शामिल है और ओपी की स्मृति से DLL को पृष्ठांकित किया गया है। लेकिन इतना आसान नहीं है! यह केवल तभी उत्पन्न होता है जब FreeLibrary को कॉल किया जाता है, और तब नहीं जब सिस्टम स्वयं लाइब्रेरी को अनलोड करता है। जानकारी के लिए, UnloadDll (UNLOAD_DLL_DEBUG_INFO) का उपयोग करें:

 struct UNLOAD_DLL_DEBUG_INFO { LPVOID lpBaseOfDll; };

जैसा कि आप देख सकते हैं, केवल पुस्तकालय का आधार पता हमारे पास उपलब्ध है। इसीलिए मैंने आपको तुरंत LOAD_DLL_DEBUG_EVENT के कोड के बारे में नहीं बताया। DLL को लोड करते समय, हमें lpBaseOfDll भी मिलता है। आप अपने पते के अलावा, लाइब्रेरी के नाम को स्टोर करने के लिए मैप का उपयोग कर सकते हैं।
यह ध्यान रखना महत्वपूर्ण है कि सभी पुस्तकालय लोडिंग घटनाओं को उनके अनलोडिंग इवेंट प्राप्त नहीं होंगे। हालाँकि, हमें लाइब्रेरी के सभी नामों को संग्रहित करना चाहिए, क्योंकि LOAD_DLL_DEBUG_EVENT हमें यह जानकारी नहीं देता है कि लाइब्रेरी कैसे भरी हुई थी।
नीचे दोनों घटनाओं को संभालने के लिए कोड है:

 std::map < LPVOID, CString > DllNameMap; ... case LOAD_DLL_DEBUG_EVENT: { strEventMessage = GetFileNameFromHandle(debug_event.u.LoadDll.hFile); // Storing the DLL name into map. Map's key is the Base-address DllNameMap.insert( std::make_pair( debug_event.u.LoadDll.lpBaseOfDll, strEventMessage) ); strEventMessage.AppendFormat(L" - Loaded at %x", debug_event.u.LoadDll.lpBaseOfDll); } break; ... case UNLOAD_DLL_DEBUG_EVENT: { strEventMessage.Format(L"DLL '%s' unloaded.", DllNameMap[debug_event.u.UnloadDll.lpBaseOfDll] ); // Get DLL name from map. } break;

EXIT_PROCESS_DEBUG_EVENT प्रसंस्करण

यह सबसे सरल घटनाओं में से एक है, और जैसा कि आप अनुमान लगा सकते हैं, यह ओपी प्रक्रिया समाप्त होने पर कहा जाता है। यह घटना हमें दिखाती है कि प्रक्रिया कैसे समाप्त हुई: सामान्य रूप से या तत्काल (उदाहरण के लिए, कार्य प्रबंधक के माध्यम से), या डीबग किया गया प्रोग्राम क्रैश हो गया। सूचना हमें EXIT_PROCESS_DEBUG_INFO ExitProcess से मिलती है;

 struct EXIT_PROCESS_DEBUG_INFO { DWORD dwExitCode; };

जैसे ही हम इस घटना को प्राप्त करते हैं, हमें डिबग चक्र को बाधित करने और डिबग स्ट्रीम को पूरा करने की आवश्यकता होती है। ऐसा करने के लिए, हम एक ध्वज सेट कर सकते हैं जो डिबगिंग के पूरा होने का संकेत देगा।

 bool bContinueDebugging=true; ... case EXIT_PROCESS_DEBUG_EVENT: { strEventMessage.Format(L"Process exited with code: 0x%x", debug_event.u.ExitProcess.dwExitCode); bContinueDebugging=false; } break;

EXCEPTION_DEBUG_EVENT प्रसंस्करण

यह सभी डिबगिंग घटनाओं में सबसे आश्चर्यजनक और जटिल बात है। MSDN से:

यह घटना तब उत्पन्न होती है जब डीबग की गई प्रक्रिया में कोई अपवाद होता है (संभवतः शून्य से विभाजित होने पर, सरणी की सीमाओं से परे जाकर, इंट 3 निर्देश को निष्पादित करते हुए, या एसईएच में वर्णित किसी अन्य अपवाद को)। DEBUG_EVENT संरचना में EXCEPTION_DEBUF_INFO संरचना शामिल है। यह वह है जो अपवाद का वर्णन करता है।

इस घटना के प्रसंस्करण का वर्णन इसके बारे में पूरी तरह से बताने के लिए एक अलग लेख की आवश्यकता है (हाँ, भले ही आंशिक रूप से)। इसलिए, मैं आपको एक प्रकार के अपवाद के बारे में बताऊंगा।
अपवाद फ़ील्ड में अपवाद के बारे में जानकारी होती है जो अभी हुई है। नीचे आप EXCEPTION_DEBUG_INFO संरचना का विवरण देख सकते हैं:

 struct EXCEPTION_DEBUG_INFO { EXCEPTION_RECORD ExceptionRecord; DWORD dwFirstChance; };

ExceptionRecord फ़ील्ड में अपवाद के बारे में विस्तृत जानकारी है।

 struct EXCEPTION_RECORD { DWORD ExceptionCode; DWORD ExceptionFlags; struct _EXCEPTION_RECORD *ExceptionRecord; PVOID ExceptionAddress; DWORD NumberParameters; ULONG_PTR ExceptionInformation[EXCEPTION_MAXIMUM_PARAMETERS]; // 15 };

इससे पहले कि हम EXCEPTION_RECORD में तल्लीन हों, मैं आपसे EXCEPTION_DEBUG_INFO :: dwFirstChance पर चर्चा करना चाहूंगा
जब कोई प्रक्रिया डिबगिंग के अंतर्गत होती है, तो ओपी के मिलने से पहले डिबगर को हमेशा एक अपवाद मिलता है। आपने + ++ के तहत एप्लिकेशन को डीबग करते समय "SomeModule में 0x00412882 पर प्रथम-अपवाद अपवाद" प्रविष्टि देखी होगी। यह फर्स्ट चांस अपवादों को संदर्भित करता है। एक ही अपवाद दूसरे मौका अपवादों पर हो सकता है या नहीं भी हो सकता है।
जब एक ओपी एक अपवाद फेंकता है, तो इसे दूसरे मौके के रूप में माना जाता है। ओपी इस अपवाद को संभाल सकता है, या यह सिर्फ गिर सकता है। ये अपवाद C ++ अपवादों के नहीं हैं, बल्कि Windows SEH इंजन के हैं। मैं लेख के अगले भाग में थोड़ा और खुलासा करूंगा।
सबसे पहले, डिबगर अपवाद संदेश (पहला मौका अपवाद) प्राप्त करता है, इससे उसे ओपी की तुलना में तेजी से अपवाद को संभालने में मदद मिलती है। कुछ पुस्तकालयों ने डिबगर को अपना काम करने में मदद करने के लिए पहले-मौका अपवादों को फेंक दिया।

ContinueDebugEvent के बारे में थोड़ा और

इस फ़ंक्शन (dwContinueStatus) का तीसरा पैरामीटर केवल एक अपवाद प्राप्त करने के लिए हमारे लिए महत्वपूर्ण है। अन्य घटनाओं के लिए, इस पैरामीटर को अनदेखा किया जाता है।
अपवाद प्राप्त करने के बाद, ContinueDebugEvent को इसके साथ बुलाया जाना चाहिए:

DBG_CONTINUE यदि अपवाद डीबगर द्वारा सफलतापूर्वक पकड़ा गया था। डीबग किए गए प्रोग्राम से कुछ भी अधिक की आवश्यकता नहीं है और इसे सामान्य रूप से निष्पादित किया जा सकता है।
डीबग_EXCEPTION_NOT_HANDLED यदि यह अपवाद डीबगर द्वारा नियंत्रित नहीं किया जा सकता (हैंडल नहीं किया जा सकता है)। डीबगर केवल यह रिकॉर्ड कर सकता है कि यह अपवाद था।

कृपया ध्यान दें कि यदि DBG_CONTINUE को डिबगिंग ईवेंट के दौरान लौटाया जाता है जिसमें इसे वापस नहीं किया जा सकता है, तो ठीक उसी अपवाद को डीबगर में फेंक दिया जाएगा, और वही ईवेंट तुरंत आ जाएगा। लेकिन जब से हम सिर्फ डिबगर लिखना शुरू कर रहे हैं, चलो एक बंदूक नहीं, एक सुरक्षित गुलेल के साथ खेलते हैं, और हम EXCEPTION_NOT_HANDLED लौटाएंगे। इस लेख का अपवाद इंट 3 (ब्रेकपॉइंट) है, जिस पर हम बाद में चर्चा करेंगे।

अपवाद कोड

EXCEPTION_ACCESS_VIOLATION
EXCEPTION_ARRAY_BOUNDS_EXCEEDED
EXCEPTION_BREAKPOINT
EXCEPTION_DATATYPE_MISALIGNMENT
EXCEPTION_FLT_DENORMAL_OPERAND
EXCEPTION_FLT_DIVIDE_BY_ZERO
EXCEPTION_FLT_INEXACT_RESULT
EXCEPTION_FLT_INVALID_OPERATION
EXCEPTION_FLT_OVERFLOW
EXCEPTION_FLT_STACK_CHECK
EXCEPTION_FLT_UNDERFLOW
EXCEPTION_ILLEGAL_INSTRUCTION
EXCEPTION_IN_PAGE_ERROR
EXCEPTION_INT_DIVIDE_BY_ZERO
EXCEPTION_INT_OVERFLOW
EXCEPTION_INVALID_DISPOSITION
EXCEPTION_NONCONTINUABLE_EXCEPTION
EXCEPTION_PRIV_INSTRUCTION
EXCEPTION_SINGLE_STEP
EXCEPTION_STACK_OVERFLOW

शांत हो जाओ, मैं उन सभी का वर्णन नहीं करने जा रहा हूं। केवल EXCEPTION_BREAKPOINT:

 case EXCEPTION_DEBUG_EVENT: { EXCEPTION_DEBUG_INFO& exception = debug_event.u.Exception; switch( exception.ExceptionRecord.ExceptionCode) { case STATUS_BREAKPOINT: // Same value as EXCEPTION_BREAKPOINT strEventMessage= "Break point"; break; default: if(exception.dwFirstChance == 1) { strEventMessage.Format(L"First chance exception at %x, exception-code: 0x%08x", exception.ExceptionRecord.ExceptionAddress, exception.ExceptionRecord.ExceptionCode); } dwContinueStatus = DBG_EXCEPTION_NOT_HANDLED; } break; }

आपको इस बात की जानकारी होनी चाहिए कि ब्रेकपॉइंट क्या है। मानक दृष्टिकोण से परे, एक ब्रेकपॉइंट को डिबगब्रेक एपीआई का उपयोग करके या विधानसभा निर्देश {इंट 3} का उपयोग करके बुलाया जा सकता है। .NET में, आप System.Diagnostics.Debugger.Break का उपयोग करके इसे बना सकते हैं। डीबगर को STATUS_BREAKPOINT (EXCEPTION_BREAKPOINT के समान) कोड प्राप्त होगा। डिबगर वर्तमान प्रक्रिया को रोकने के लिए आमतौर पर इस घटना का उपयोग करता है, और उस स्थान का स्रोत कोड दिखा सकता है जहां घटना हुई थी। लेकिन चूंकि हमारा डिबगर अभी विकसित होना शुरू हो रहा है, हम उपयोगकर्ता को केवल मूल जानकारी बिना स्रोत कोड के दिखाएंगे।
यदि किसी एप्लिकेशन में एक ब्रेकपॉइंट कहा जाता है जो डीबगर के नीचे नहीं है, तो यह बस दुर्घटनाग्रस्त हो जाएगा। आप निम्नलिखित निर्माण का उपयोग कर सकते हैं:

 if ( !IsDebuggerPresent() ) AfxMessageBox(L"No debugger is attached currently."); else DebugBreak();

अंत में, मैं एक साधारण डिबगिंग ईवेंट देना चाहूंगा: EXCEPTION_DEBUG_EVENT। यह आयोजन लगातार होता रहेगा। Visual Studio जैसे डीबगर्स इसे अनदेखा करते हैं, लेकिन WinDbg नहीं करता है।

निष्कर्ष

डीबगमे के लिए किसी भी डीबगर का उपयोग करें।

दूसरा हिस्सा और भी दिलचस्प होगा और वह रास्ते में है!
UPD: भाग 2

हम डिबगर विंडोज के तहत लिखते हैं [भाग 1]