विंडोजमध्ये IRQL (इंटरप्ट रिक्वेस्ट लेव्हल) म्हणजे काय आणि ते BSOD शी कसे संबंधित आहे?

जर तुम्ही कधी निळा स्क्रीन पाहिला असेल ज्यावर असे संदेश असतील IRQL_NOT_LESS_OR_EQUAL o ड्रायव्हर_आयआरक्यूएल_कमी_किंवा_समान नाही, तुम्हाला कदाचित ड्रायव्हर्सच्या जगाबाहेर फारशी माहिती नसलेली संकल्पना आली असेल: IRQL (इंटरप्ट रिक्वेस्ट लेव्हल). विंडोज, जेव्हा सिस्टम एका विशिष्ट मर्यादेपेक्षा जास्त असते तेव्हा इंटरप्ट प्रायोरिटीची ही पातळी थ्रेड प्रायोरिटीपेक्षा जास्त असते आणि याचा थेट परिणाम स्थिरतेवर होतो.

पुढील ओळींमध्ये तुम्हाला आढळेल एक पूर्ण मार्गदर्शक आणि स्पेनमधून स्पॅनिशमध्ये IRQL म्हणजे काय, ते कसे कार्य करते याबद्दल, ते निळे पडदे का ट्रिगर करते, WinDbg मधील समस्येचे निदान कसे करावे आणि तुम्ही त्रुटी अनुभवणारे वापरकर्ता असाल किंवा कर्नल-मोड ड्राइव्हर्स विकसित करत असाल तर काय करावे. चला व्यवसायाकडे उतरूया.

विंडोजमध्ये IRQL (इंटरप्ट रिक्वेस्ट लेव्हल) म्हणजे काय?

विंडोज मध्ये, IRQL प्राधान्य परिभाषित करते हार्डवेअर प्रोसेसर कुठे काम करतो कोणत्याही वेळी. विंडोज ड्रायव्हर मॉडेल (WDM) मध्ये, कमी IRQL वर चालणारा कोड उच्च IRQL वर चालणारा कोड द्वारे व्यत्यय आणला जाऊ शकतो. खरं तर, एका मल्टी-कोर संगणकावर, प्रत्येक CPU वेगळ्या IRQL वर असू शकतो, ज्यामुळे सिंक्रोनाइझेशन गुंतागुंतीचे होते.

एक महत्त्वाचा नियम आहे: जेव्हा एखादा CPU PASSIVE_LEVEL पेक्षा जास्त IRQL वर चालत असतो, तेव्हा तो फक्त त्याहूनही जास्त IRQL वर असलेल्या क्रियाकलापानेच रोखता येतो.हे वापरकर्ता कोड, कर्नल फंक्शन्स, डिफर्ड कॉलर्स (DPCs) आणि डिव्हाइस इंटरप्ट सर्व्हिस रूटीन्स (ISRs) यांच्यातील सहअस्तित्वाचे आयोजन करते.

स्तर आणि प्राधान्यक्रम: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL आणि DIRQL

सर्वसाधारणपणे, x86 वर, 0 आणि 31 मधील IRQL मूल्ये वापरली जातात; x64 वर, 0 आणि 15 मधीलव्यावहारिक अर्थ सारखाच आहे: IRQL 0 (PASSIVE_LEVEL) म्हणजे जिथे सामान्य वापरकर्ता कोड आणि अनेक ड्रायव्हर फंक्शन्स कार्यान्वित केले जातात; एपीसी आणि पेजमधील दोष ते सहसा IRQL 1 (APC_LEVEL) वर मॅप केले जातात; IRQL 2 (DISPATCH_LEVEL) मध्ये थ्रेड शेड्युलर आणि DPC समाविष्ट असतात. DISPATCH_LEVEL च्या वर डिव्हाइस इंटरप्ट्स (DIRQL म्हणून ओळखले जाणारे) आणि HIGH_LEVEL सारख्या इतर अंतर्गत वापरांसाठी राखीव स्तर आहेत.

ड्रायव्हर इकोसिस्टममध्ये, DISPATCH_LEVEL वर अनेक सामान्य दिनचर्या चालतात.: उदाहरणार्थ, DPC आणि StartIo. हे डिझाइन सुनिश्चित करते की त्यापैकी एक अंतर्गत रांगांना किंवा इतर सामायिक संसाधनांना स्पर्श करत असताना, त्याच स्तरावरील दुसरा रूटीन त्या CPU वर प्रीम्प्शन करत नाही, कारण प्रीम्प्शन नियम फक्त उच्च स्तरावर इंटरप्टना परवानगी देतो.

DISPATCH_LEVEL आणि प्रोफाइलिंग/उच्च पातळी दरम्यान जागा आहे प्रत्येक उपकरणाचे हार्डवेअर इंटरप्ट्स (DIRQL)डिव्हाइसचा IRQL इतर डिव्हाइसपेक्षा त्याची प्राधान्यता परिभाषित करतो. WDM ड्रायव्हर IRP_MN_START_DEVICE सह IRP_MJ_PNP दरम्यान हे IRQL मिळवतो. हे डिव्हाइस IRQL हे जागतिक, निश्चित मूल्य नाही, तर एका विशिष्ट इंटरप्ट लाइनशी संबंधित मूल्य आहे.

IRQL विरुद्ध थ्रेड प्रायोरिटी

संकल्पनांमध्ये गोंधळ न करण्याचा सल्ला दिला जातो: शेड्यूलर कधी प्रीम्प्ट्स करतो आणि कोणता थ्रेड कार्यान्वित करतो हे थ्रेड प्रायोरिटी ठरवते.; IRQL कोणत्या प्रकारची क्रियाकलाप अंमलात आणता येईल आणि कोणते व्यत्यय लपवले जातील हे नियंत्रित करते. DISPATCH_LEVEL वर, थ्रेड स्विचिंग नाही: ते IRQL नियंत्रित करते, थ्रेड प्राधान्य नाही.

IRQL आणि पेजिंग: तुम्ही काय करू नये

IRQL वाढवण्याचा तात्काळ परिणाम म्हणजे प्रणाली पानातील दोष हाताळू शकत नाही.. सुवर्ण नियम: DISPATCH_LEVEL वर किंवा त्यापेक्षा जास्त चालणारा कोड पृष्ठ दोष निर्माण करू शकत नाही. प्रत्यक्षात, याचा अर्थ असा की त्या दिनचर्या आणि त्यांनी स्पर्श केलेला डेटा नॉन-पेज्ड मेमरीमध्ये राहणे आवश्यक आहे. याव्यतिरिक्त, काही कर्नल मदतनीस IRQL वर आधारित त्यांचा वापर मर्यादित करतात: उदाहरणार्थ, KeWaitForSingleObject जर तुम्ही ब्लॉक करत नसाल तरच DISPATCH_LEVEL कॉल करता येईल (शून्य टाइमआउट), आणि शून्य टाइमआउट नसलेल्यांसाठी, तुम्ही DISPATCH_LEVEL च्या खाली असणे आवश्यक आहे.

IRQL चे अंतर्निहित आणि स्पष्ट नियंत्रण

बहुतेक वेळा, सिस्टम स्वतःच तुमच्या दिनचर्यांचे योग्य IRQL वर आवाहन करते. त्यांनी काय करावे यासाठी. IRP साठी डिस्पॅच रूटीन PASSIVE_LEVEL वर चालतात (ते कोणत्याही मदतनीसाला ब्लॉक करू शकतात किंवा कॉल करू शकतात), StartIo आणि DPC शेअर केलेल्या रांगांचे संरक्षण करण्यासाठी DISPATCH_LEVEL वर चालतात आणि ISR DIRQL वर चालतात.

जर तुम्हाला ते स्पष्टपणे नियंत्रित करायचे असेल तर, तुम्ही IRQL वाढवू आणि कमी करू शकता KeRaiseIrql y KeLowerIrqlएक खूप वापरला जाणारा शॉर्टकट आहे: KeRaiseIrqlToDpcLevel() मागील IRQL परत करते आणि तुम्हाला DISPATCH_LEVEL वर सोडते. महत्वाचे: सिस्टमने तुम्हाला कॉल केला तेव्हा IRQL कधीही त्याच्या मूल्यापेक्षा कमी करू नका; ते सिंक्रोनाइझेशन बिघडल्याने खूप गंभीर रेस विंडो उघडू शकतात.

IRQL-संबंधित निळ्या स्क्रीन त्रुटी: IRQL_NOT_LESS_OR_EQUAL आणि DRIVER_IRQL_NOT_LESS_OR_EQUAL

या समस्यांशी संबंधित दोन क्लासिक बग चेक आहेत IRQL_कमी_किंवा_समान नाही (०xA) y ड्रायव्हर_आयआरक्यूएल_कमी_किंवा_समान नाही (०xडी१)दोन्हीही खूप जास्त असलेल्या IRQL वर पेज करण्यायोग्य (किंवा अवैध) पत्त्यावर प्रवेश करण्याचा प्रयत्न दर्शवितात. हे सहसा ड्रायव्हर्स चुकीचे पत्ते वापरत असल्याने, चुकीचे पॉइंटर्स संदर्भित करत नसल्यामुळे किंवा अयोग्य पातळीवर पेज करण्यायोग्य कोड अंमलात आणल्यामुळे होते.

च्या विशिष्ट प्रकरणात ड्रायव्हर_आयआरक्यूएल_कमी_किंवा_समान नाही (०x०००००डी१), पॅरामीटर्स खूप माहितीपूर्ण आहेत: १) संदर्भित मेमरी अॅड्रेस; २) त्या वेळी IRQL; ३) अॅक्सेस प्रकार (० वाचन, १ लेखन, २/८ कार्यान्वित); ४) मेमरीचा संदर्भ देणाऱ्या सूचनांचा अॅड्रेस. डीबगरसह तुम्ही वापरू शकता ln पॅरामीटर ४ वर जवळचे चिन्ह सूचीबद्ध करा आणि कोणते फंक्शन चालू होते ते जाणून घ्या..

लक्षात ठेवण्याची सामान्य कारणे

विशिष्ट कोडच्या पलीकडे, असे नमुने आहेत जे पुनरावृत्ती होतात. DISPATCH_LEVEL किंवा त्याहून उच्चतम वर अवैध पॉइंटरला संदर्भित करणे हे निश्चितच आपत्तीसाठी एक उपाय आहे. त्या स्तरावर पेजेबल डेटा अॅक्सेस करणे किंवा पेजेबल कोड (उदा. पेजेबल म्हणून चिन्हांकित केलेले फंक्शन) कार्यान्वित करणे देखील बग चेक ट्रिगर करते.

इतर सामान्य प्रकरणांमध्ये हे समाविष्ट आहे आधीच डाउनलोड केलेल्या दुसऱ्या ड्रायव्हरमध्ये फंक्शन कॉल करा. (डँगलिंग फंक्शन पॉइंटर), किंवा अप्रत्यक्षपणे अवैध फंक्शन पॉइंटरद्वारे आवाहन केले जाते. बर्‍याचदा, जर सिस्टम मॉड्यूल ओळखण्यास सक्षम असेल, तर तुम्हाला त्याचे नाव निळ्या स्क्रीनवरच दिसेल आणि ते सेव्ह देखील केले जाते KiBugCheckDriver, सह प्रवेशयोग्य dx KiBugCheckDriver WinDbg कडून.

एक व्यावहारिक तपशील: बहुतेक D1/A मध्ये, खरी समस्या IRQL ची नाही., परंतु संदर्भित मेमरी अॅड्रेस. म्हणूनच निदानावर लक्ष केंद्रित करण्यासाठी पॅरामीटर्स १, ३ आणि ४ महत्वाचे आहेत.

WinDbg सह निदान: उपयुक्त आदेश आणि पॅरामीटर वाचन

या प्रकरणांवर काम करण्यासाठी, WinDbg हे एक महत्त्वाचे साधन आहे., आणि जर BSOD मध्ये उल्लेख असेल तर ntoskrnl.exe ही माहिती कर्नल उपप्रणालीमध्ये दोष आहे की नाही याबद्दल बरेच मार्गदर्शन प्रदान करते. सुरुवात करा !analyze -v बग तपासणी, स्टॅक आणि जर तुम्ही भाग्यवान असाल तर, संबंधित मॉड्यूलचा सारांश मिळविण्यासाठी. जर डंपमध्ये कॅप्चर फ्रेम असेल, .trap तुम्हाला अयशस्वी CPU च्या संदर्भात ठेवते.

अगोदर निर्देश केलेल्या बाबीसंबंधी बोलताना आज्ञा ढीग म्हणून k, kb, kc, kd, kp, kP, kv ते तुम्हाला बॅकट्रेस तपशीलांचे वेगवेगळे स्तर दाखवतात. सह ln पॅरामीटर ४ वर तुम्ही वगळू शकता स्मृतीचा संदर्भ देणाऱ्या सूचनांकडे आणि जवळचे चिन्ह मिळवा. आणि जर तुम्हाला शंका असेल की इंटरप्टच्या आधी प्राधान्य पातळी चालू आहे, !irql लक्ष्य प्रोसेसरसाठी जतन केलेला IRQL तुम्हाला दाखवतो (उदा. DISPATCH_LEVEL).

पॅरामीटर १ च्या दिशेचे विश्लेषण करण्यासाठी, !pool ते तुम्हाला सांगेल की ते पेज्ड पूलचे आहे का; !address y !pte त्या क्षेत्राच्या मेमरी मॅपिंगमध्ये खोलवर जा. तुम्ही वापरू शकता मेमरी डिस्प्ले कमांड ज्या सामग्रीमध्ये प्रवेश करण्याचा प्रयत्न केला गेला होता त्याची तपासणी करण्यासाठी. शेवटी, u, ub, uu तुम्हाला पॅरामीटर ४ च्या पत्त्याभोवती वेगळे करण्याची परवानगी देते.

विसरू नका lm t n लोड केलेल्या मॉड्यूल्सची यादी करण्यासाठी y !memusage सामान्य स्मृती स्थितीसाठी. जर KiBugCheckDriver काहीतरी आहे, dx KiBugCheckDriver ते युनिकोड मॉड्यूलचे नाव परत करेल: एका सामान्य उदाहरणात, बग तपासणी दरम्यान "Wdf01000.sys" हा ड्रायव्हर म्हणून पाहिला गेला.

सिस्टम टूल्स: ड्रायव्हर व्हेरिफायर, इव्हेंट व्ह्यूअर आणि डायग्नोस्टिक्स

El ड्रायव्हर व्हेरिफायर रिअल टाइममध्ये ड्रायव्हर्सच्या वर्तनाचे परीक्षण करते आणि चुकीचा संसाधन वापर (जसे की पूल) आढळल्यास त्रुटी दूर करते, कोडच्या समस्याग्रस्त क्षेत्राला वेगळे करण्यासाठी अपवाद वाढवते. हे यासह लाँच केले जाते verifier पासून कमांड प्रॉम्प्ट आणि जास्त ओव्हरहेड टाळण्यासाठी शक्य तितक्या लहान ड्रायव्हर्सचा संच निवडणे उचित आहे.

जर तुम्हाला WinDbg सोबत स्वतःला दिसत नसेल, मूलभूत उपाययोजना लागू करा: विशिष्ट डिव्हाइस/ड्रायव्हरकडे निर्देशित करणाऱ्या त्रुटींसाठी सिस्टम लॉग इन इव्हेंट व्ह्यूअर तपासा; निळ्या स्क्रीनने उद्धृत केलेला ड्रायव्हर अपडेट किंवा अक्षम करा; तुमच्या विंडोजच्या आवृत्तीसह हार्डवेअर सुसंगतता सत्यापित करा; आणि जर तुम्हाला रॅमचा संशय असेल तर विंडोज मेमरी डायग्नोस्टिक वापरा. ​​या कृती, जरी सोप्या असल्या तरी, ते मोठ्या संख्येने प्रकरणे सोडवतात..

वास्तविक जीवनातील प्रकरणे: जेव्हा बीएसओडी यादृच्छिक वाटतात

विंडोज १० प्रो (एएमडी रायझन ५ ३४००जी सीपीयू) असलेला वापरकर्ता, GPU द्रुतगती NVIDIA GeForce GTX 1660 Ti आणि Gigabyte B450 AORUS PRO WIFI बोर्ड, १६ जीबी रॅम) मध्ये अधूनमधून "IRQL_LESS_OR_NOT_EQUAL" स्क्रीन येत होत्या. मी आधीच आवश्यक ड्रायव्हर्स (नेटवर्क, ग्राफिक्स) अपडेट केले होते, सर्व विंडोज अपडेट्स इन्स्टॉल केले होते आणि मेमरी टूल चालवले होते, सर्व काही कोणत्याही समस्या न आढळता.

अशा परिस्थितीत, पुढील पायरी म्हणजे WinDbg वापरून डंपचे विश्लेषण करणे. आणि नमुने शोधा: जेव्हा ते पडते तेव्हा समाविष्ट असलेल्या प्रक्रिया (उदाहरणार्थ, explorer.exe), ग्राफिकल इंटरफेस मॉड्यूल्स (win32kfull.sys) आणि कार्ये जसे की xxxProcessNotifyWinEvent स्टॅकमध्ये दिसत आहे. जरी हे मॉड्यूल विंडोज असले तरी, ट्रिगर बहुतेकदा तृतीय-पक्ष ड्रायव्हर (ग्राफिक्स, इनपुट, ओव्हरले, कॅप्चर कार्ड) असतो जो अयोग्य IRQL वर मेमरी वापरतो आणि दोष आत उद्भवतो. win32k.

येथे व्यावहारिक शिफारस अशी आहे की ओव्हरले सॉफ्टवेअर तात्पुरते अक्षम करा (कॅप्चर, GPU OSD), आक्रमक सॉफ्टवेअर पेरिफेरल ड्रायव्हर्स (मॅक्रोसह माईस/कीबोर्ड), आणि ग्राफिक्स ड्रायव्हर्सच्या बीटा आवृत्त्या, आणि ते कमी करा. संशयितांवर ड्रायव्हर व्हेरिफायर वापरल्याने स्पष्ट स्टॅकसह समस्या कमी होण्यास मदत होऊ शकते.

एक अतिशय सामान्य नेटवर्क पॅटर्न: ndis.sys नेहमीच दोषी नसते.

आणखी एक सामान्य केस: ndis.sys सह स्क्रीनशॉट (विंडोज नेटवर्क लेयर). खऱ्या संगणकावर, सिस्टम स्टार्टअप होताच लगेच क्रॅश होते. व्यावहारिक उपाय म्हणजे बूट करणे सुरक्षित मोड नेटवर्क फंक्शन्सशिवाय, उघडा डिव्हाइस व्यवस्थापक आणि समस्या दूर करण्यासाठी "नेटवर्क अडॅप्टर्स" अंतर्गत अडॅप्टर्स अक्षम करा.

त्या संघात एक होता रिअलटेक पीसीआयई जीबीई फॅमिली कंट्रोलर आणि अ‍ॅथेरोस एआर५००७जी. दोन्ही निष्क्रिय करून, हे आढळून आले की खरे कारण athrx.sys (अ‍ॅथेरोस), जरी निळ्या पडद्याचा उल्लेख आहे ndis.sysडंपने याची पुष्टी केली: स्टॅक मधून गेला ndis!NdisFreeTimerObject पण दोषी मॉड्यूल होता athrx.sysशेवटची दुरुस्ती अशी होती डिव्हाइस अनइंस्टॉल करा आणि अपडेटेड अधिकृत ड्रायव्हर्स इन्स्टॉल करा. अ‍ॅथेरोस उत्पादकाच्या वेबसाइटवरून. नैतिक: बीएसओडीमध्ये उल्लेख केलेला मॉड्यूल प्रभावित उपप्रणालीचा भाग असू शकतो, स्त्रोताचा नाही.

वापरकर्त्यांसाठी सामान्य समर्थन प्रतिसाद आणि जलद पावले

एका खऱ्या सपोर्ट एक्सचेंजमध्ये, एका तंत्रज्ञाने उत्तर दिले: "गैरसोयीबद्दल मी दिलगीर आहे. ही ड्रायव्हर, मेमरी किंवा अँटीव्हायरस समस्या असू शकते. कृपया तुमचे ड्रायव्हर्स अपडेट करा आणि जर ती कायम राहिली तर मेमरी डायग्नोस्टिक चालवा."हा मूलभूत पण वैध सल्ला आहे; तथापि, जर त्रुटी कायम राहिल्या तर, व्हेरिफायर आणि डंप विश्लेषणासह पुढे जाणे चांगली कल्पना आहे.

तांत्रिक नसलेल्या वापरकर्त्यांसाठी, एक वाजवी प्रोटोकॉल असा असेल: १) सिस्टम इव्हेंट्स तपासा, २) की ड्रायव्हर्स अपडेट करा (चिपसेट/नेटवर्क/ग्राफिक्स), ३) रॅम तपासा एकात्मिक साधनासह, ४) चाचणी बूट कर्नल/GUI मध्ये हुक घालणाऱ्या थर्ड-पार्टी सॉफ्टवेअरशिवाय क्लीन करा आणि ५) काहीही स्पष्ट नसल्यास थर्ड-पार्टी ड्रायव्हर्सवर व्हेरिफायर वापरा.

ड्रायव्हर डेव्हलपर्ससाठी सर्वोत्तम पद्धती

जर तुम्ही विकसित होत असाल आणि तुम्हाला D1/A आढळला तर तपासा की रनिंग रूटीन पेजेबल म्हणून चिन्हांकित केलेले नाही. DISPATCH_LEVEL किंवा त्याहून उच्च आवृत्तीवर चालत असताना पेजेबल फंक्शन्स कॉल करू नका. यामध्ये पेज केलेल्या विभागांमधील डेटाचे संदर्भ टाळणे आणि DDK मध्ये वर्णन केलेल्या कर्नल मदतनीसांसाठी IRQL निर्बंधांचे पालन करणे समाविष्ट आहे.

शेअर केलेला डेटा सिंक्रोनाइझ करण्यासाठी, "नेहमी समान उच्च IRQL वर सामायिक डेटा अॅक्सेस करा" हा नियम लागू करा. आणि योग्य असेल तेव्हा स्पिन लॉक वापरा. ​​मल्टीप्रोसेसरवर, केवळ IRQL वेगवेगळ्या CPU मधील बहिष्काराची हमी देत ​​नाही; स्पिन लॉक IRQL (DISPATCH_LEVEL पर्यंत) वाढवतात आणि कोर दरम्यान प्रवेश समन्वयित करतात. जर तुम्हाला संवेदनशील हार्डवेअर रजिस्टरवर ऑपरेट करण्याची आवश्यकता असेल, KeSynchronizeExecution योग्य DIRQL वर महत्त्वाचे विभाग कार्यान्वित करण्यास मदत करते.

जेव्हा योजनेत IRQL वाढवण्याची आवश्यकता असते, संयुक्त KeRaiseIrqlToDpcLevel DISPATCH_LEVEL साठी किंवा KeRaiseIrql काळजीपूर्वक, मागील IRQL जतन करणे आणि ते अचूकपणे पुनर्संचयित करणे KeLowerIrql. इनपुट IRQL च्या खाली जा, अगदी एका क्षणासाठीही, ही एक गंभीर सिंक्रोनाइझेशन त्रुटी आहे..

इंटरप्ट्स आणि हार्डवेअरशी संबंध

IRQL ही अशी यंत्रणा आहे ज्याद्वारे विंडोज प्राधान्यक्रम आणि काही अंतर्गत कामांमध्ये व्यत्यय आणण्याचे आदेशआर्किटेक्चरल पातळीवर, ते "इंटरप्ट", "इंटरप्ट हँडलर" किंवा "इंटरप्ट प्रायोरिटी लेव्हल" सारख्या संकल्पनांशी संबंधित आहे आणि क्लासिक प्लॅटफॉर्मवर, प्रोग्रामेबल इंटरप्ट कंट्रोलर (PIC)इतर प्रणालींमध्ये, प्राधान्य नियंत्रण अशा यंत्रणेद्वारे व्यक्त केले जाते जसे की spl en युनिक्स; सर्वसाधारण कल्पना एकच आहे: कोण कोणाला व्यत्यय आणू शकते.

प्रगत डीबगिंग टिप्स

ज्या डंपमध्ये स्टॅक निर्देशित करतो win32kfull!xxxProcessNotifyWinEvent बग तपासणी 0xA/0xD1 सह, संदर्भ तपासा .process y .thread (उपलब्ध असल्यास), अशा प्रक्रिया पहा explorer.exe en !process 0 1 आणि ओव्हरले आणि GUI इंटरॅक्शन ड्रायव्हर्स तपासा. बऱ्याचदा समस्या त्या मार्गावर येणाऱ्या तिसऱ्या पक्षाने भ्रष्ट केलेली स्मृती आहे..

IRQL तपासायला विसरू नका !irql, आणि कॉन्ट्रास्ट: जर तुम्ही DISPATCH_LEVEL (2) वर असाल आणि पॅरामीटर 3 वाचन/लेखन/कार्यान्वित दर्शवित असेल तर एका पृष्ठावर, ते का पडले आहे याचा तुम्हाला आधीच एक संकेत आहे. तो संकेत क्रॉस करा ln विशिष्ट कार्य मिळविण्यासाठी पॅरामीटर ४ मध्ये.

समजून घ्या आयआरक्यूएल म्हणजे काय? आणि ते कर्नल एक्झिक्युशनमध्ये कसे बसते हे सिग्नलपासून आवाज वेगळे करण्यास मदत करते. जर तुम्ही वापरकर्ता असाल तर लक्ष केंद्रित करा ड्रायव्हर्स आणि हार्डवेअर (डिफॉल्टनुसार व्हेरिफायर, इव्हेंट्स आणि चाचण्यांसह). जर तुम्ही विकसित करत असाल, तर IRQL, नॉन-पेज्ड मेमरी आणि स्पिन लॉकसह सिंक्रोनाइझेशनसाठी नियमांचे काटेकोरपणे पालन करा. योग्य टूल्स (WinDbg, व्हेरिफायर) आणि पॅरामीटर्सचे काळजीपूर्वक वाचन (1, 3 आणि 4) वापरून, या बग तपासणी आता गूढ राहिलेल्या नाहीत. आणि त्या अशा समस्या बनतात ज्या पद्धतशीरपणे सोडवता येतात.