- يقوم IRQL بتحديد أولويات التنفيذ وإخفاء المقاطعات حسب المستوى، وفوق DISPATCH فإنه يأمر IRQL، وليس أولوية الخيط.
- الكثير BSOD عادةً ما تحدث أخطاء 0xA/0xD1 بسبب الوصول إلى ذاكرة قابلة للترحيل أو غير صالحة عند IRQL عالية وعناوين غير صحيحة أو رمز قابل للترحيل.
- يعد WinDbg وDriver Verifier أمرًا أساسيًا: استخدم !analyze، !irql، ln، .trap، !pool، !address وفحص المعلمات 1 و3 و4.
- En السائقين، يمنع أخطاء الصفحة عند IRQL عالية، ويستخدم ذاكرة غير مقسمة وأقفال الدوران؛ بالنسبة للمستخدم، يقوم بتحديث/عزل برامج التشغيل التي تسبب المشاكل.
إذا سبق لك أن رأيت شاشة زرقاء تحتوي على رسائل مثل IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUALربما صادفت مفهومًا غير معروف خارج عالم برامج التشغيل: IRQL (مستوى طلب المقاطعة). في ويندوز، هذا المستوى من أولوية المقاطعة يأخذ الأولوية على أولوية الخيط عندما يكون النظام فوق حد معين، وهذا له عواقب مباشرة على الاستقرار.
في السطور القادمة ستجد ل دليل كامل وباللغة الإسبانية من إسبانيا حول ما هو IRQL وكيف يعمللماذا تظهر الشاشات الزرقاء؟ كيفية تشخيص المشكلة في WinDbg، وما العمل سواء كنتَ مستخدمًا يعاني من الخطأ أو تُطوّر برامج تشغيل في وضع النواة. لنبدأ.
ما هو IRQL (مستوى طلب المقاطعة) في Windows؟
في نظام التشغيل Windows ، يقوم ملف يحدد IRQL أولوية خردوات حيث يعمل المعالج في أي وقت. ضمن نموذج برنامج تشغيل Windows (WDM)، قد يُقاطع الكود الذي يعمل عند مستوى IRQL منخفض بواسطة كود يعمل عند مستوى IRQL أعلى. في الواقع، على جهاز كمبيوتر واحد متعدد الأنوية، قد يكون لكل وحدة معالجة مركزية مستوى IRQL مختلف، مما يُعقّد المزامنة.
هناك قاعدة أساسية واحدة: عندما يتم تشغيل وحدة المعالجة المركزية عند IRQL أعلى من PASSIVE_LEVEL، فلا يمكن استباقها إلا من خلال النشاط عند IRQL أعلى.يقوم هذا بتنظيم التعايش بين كود المستخدم ووظائف النواة والمتصلين المؤجلين (DPCs) وروتين خدمة مقاطعة الجهاز (ISRs).
المستويات والأولويات: PASSIVE_LEVEL وAPC_LEVEL وDISPATCH_LEVEL وDIRQL
بشكل عام ، في x86، يتم استخدام قيم IRQL بين 0 و31؛ وفي x64، بين 0 و15المعنى العملي هو نفسه: IRQL 0 (PASSIVE_LEVEL) هو المكان الذي يتم فيه تنفيذ كود المستخدم العادي والعديد من وظائف برنامج التشغيل؛ أخطاء APC والصفحة عادةً ما تُربط هذه المستويات بمستوى IRQL 1 (APC_LEVEL)؛ ويشمل مستوى IRQL 2 (DISPATCH_LEVEL) مُجدول الخيوط وDPCs. فوق مستوى DISPATCH_LEVEL، توجد مستويات مخصصة لمقاطعات الأجهزة (المعروفة باسم DIRQL) واستخدامات داخلية أخرى مثل HIGH_LEVEL.
في نظام بيئي للسائق، يتم تشغيل العديد من الروتينات الشائعة في DISPATCH_LEVELعلى سبيل المثال، DPC وStartIo. يضمن هذا التصميم أنه في حال اتصال أحدهما بقوائم انتظار داخلية أو موارد مشتركة أخرى، فإن روتينًا آخر على نفس المستوى لا يسبقه على وحدة المعالجة المركزية، لأن قاعدة الأولوية تسمح فقط بالمقاطعات على مستويات أعلى.
بين DISPATCH_LEVEL ومستويات التوصيف/المستويات العالية هناك مساحة لـ مقاطعات الأجهزة لكل جهاز (DIRQL)يُحدد IRQL للجهاز أولويته على الأجهزة الأخرى. يحصل برنامج تشغيل WDM على IRQL هذا أثناء IRP_MJ_PNP باستخدام IRP_MN_START_DEVICE. IRQL هذا الجهاز ليس قيمة ثابتة عالمية، بل هو القيمة المرتبطة بخط مقاطعة محدد.
IRQL مقابل أولوية الخيط
ومن المستحسن عدم الخلط بين المفاهيم: تحدد أولوية الخيط متى يستبق المجدول الخيط الذي سيتم تنفيذهيتحكم IRQL بنوع النشاط الذي يمكن تنفيذه والمقاطعات المُقنّعة. فوق مستوى الإرسال (DISPATCH_LEVEL)، لا يوجد تبديل للخيوط: IRQL هو المتحكم، وليس أولوية الخيوط.
IRQL والترقيم: ما لا يجب عليك فعله
إن التأثير الفوري لرفع IRQL هو أن النظام لا يمكن التعامل مع أخطاء الصفحةالقاعدة الذهبية: لا يمكن أن يُسبب تشغيل الكود عند مستوى الإرسال أو أعلى منه أخطاءً في الصفحات. عمليًا، هذا يعني أن هذه الإجراءات والبيانات التي تلمسها يجب أن توجد في الذاكرة غير المقسمةبالإضافة إلى ذلك، تقوم بعض مساعدات النواة بتقييد استخدامها استنادًا إلى IRQL: على سبيل المثال، KeWaitForSingleObject لا يمكن استدعاء DISPATCH_LEVEL إلا إذا لم تقم بالحظر (مهلة زمنية صفرية)، وبالنسبة لمهلة زمنية غير صفرية، يجب أن تكون أقل من DISPATCH_LEVEL.
التحكم الضمني والصريح في IRQL
في معظم الأوقات، يقوم النظام نفسه باستدعاء روتيناتك في IRQL الصحيح لما يجب عليهم فعله. تعمل روتينات الإرسال لـ IRPs على مستوى PASSIVE_LEVEL (يمكنها حظر أو استدعاء أي مساعد)، وتعمل StartIo وDPC على مستوى DISPATCH_LEVEL لحماية قوائم الانتظار المشتركة، وتعمل ISRs على مستوى DIRQL.
إذا كنت بحاجة إلى التحكم فيه صراحةً، يمكنك رفع وخفض IRQL باستخدام KeRaiseIrql y KeLowerIrqlهناك اختصار مستخدم كثيرًا: KeRaiseIrqlToDpcLevel() يُرجع IRQL السابق ويتركك عند DISPATCH_LEVEL. هام: لا تخفض IRQL أبدًا إلى ما دون القيمة التي كانت عليها عندما اتصل بك النظام؛ فتعطيل هذه المزامنة قد يؤدي إلى نوافذ سباق خطيرة.
أخطاء الشاشة الزرقاء المتعلقة بـ IRQL: IRQL_NOT_LESS_OR_EQUAL وDRIVER_IRQL_NOT_LESS_OR_EQUAL
هناك فحصان كلاسيكيان للأخطاء مرتبطان بهذه المشكلات: IRQL_NOT_LESS_OR_EQUAL (0xA) y برنامج التشغيل_IRQL_NOT_LESS_OR_EQUAL (0xD1)يشير كلاهما إلى محاولة الوصول إلى عنوان قابل للترقيم (أو غير صالح) عند مستوى IRQL مرتفع جدًا. يحدث هذا عادةً بسبب استخدام برامج التشغيل لعناوين غير صحيحة، أو إلغاء مرجع مؤشرات خاطئة، أو تنفيذ تعليمات برمجية قابلة للترقيم بمستويات غير مناسبة.
في حالة محددة من DRIVER_IRQL_NOT_LESS_OR_EQUAL (0x000000D1)المعلمات مفيدة للغاية: ١) عنوان الذاكرة المرجعية؛ ٢) IRQL في ذلك الوقت؛ ٣) نوع الوصول (٠ قراءة، ١ كتابة، ٢/٨ تنفيذ)؛ ٤) عنوان التعليمات التي أشارت إلى الذاكرة. باستخدام مصحح الأخطاء، يمكنك استخدام ln على المعلمة 4 ل قم بإدراج الرمز الأقرب ومعرفة الوظيفة التي كانت تعمل.
أسباب شائعة يجب وضعها في الاعتبار
إلى جانب الكود المحدد، هناك أنماط تتكرر. إلغاء الرجوع إلى مؤشر غير صالح إلى DISPATCH_LEVEL أو أعلى هذه وصفة أكيدة للكارثة. الوصول إلى البيانات القابلة للتجزئة على هذا المستوى، أو تنفيذ شيفرة قابلة للتجزئة (مثل دالة مُعَرَّفة على أنها قابلة للتجزئة)، يُفعِّل أيضًا فحص الأخطاء.
وتشمل الحالات الشائعة الأخرى ما يلي: استدعاء وظيفة في برنامج تشغيل آخر تم تنزيله بالفعل (مؤشر دالة معلق)، أو يتم استدعاؤه بشكل غير مباشر عبر مؤشر دالة غير صالح. غالبًا، إذا تمكن النظام من تحديد وحدة، فسترى اسمها على الشاشة الزرقاء نفسها، كما أنه محفوظ في KiBugCheckDriver، يمكن الوصول إليها باستخدام dx KiBugCheckDriver من WinDbg.
تفصيل عملي: في معظم D1/A، المشكلة الحقيقية ليست IRQL نفسها، بل عنوان الذاكرة المرجعية. لهذا السبب، تُعدّ المعلمات 1 و3 و4 أساسيةً لتركيز التشخيص.
التشخيص باستخدام WinDbg: الأوامر المفيدة وقراءة المعلمات
للعمل على هذه الحالات، WinDbg هي الأداة الرئيسيةوإذا ذكر BSOD NTOSKRNL.EXE تُوفر هذه المعلومات إرشاداتٍ قيّمة حول ما إذا كان الخلل في نظام النواة. ابدأ بـ !analyze -v للحصول على ملخص لفحص الأخطاء، والمكدس، وإذا حالفك الحظ، الوحدة المعنية. إذا تضمن التفريغ إطار التقاط، .trap يضعك في سياق وحدة المعالجة المركزية الفاشلة.
الكثير الأوامر من كومة كما k, kb, kc, kd, kp, kP, kv إنها تُظهر لك مستويات مختلفة من تفاصيل التتبع الخلفي. مع ln في المعلمة 4 يمكنك التخطي إلى التعليمات التي أشارت إلى الذاكرة واحصل على الرمز القريب. وإذا كنت تشك في أن مستوى الأولوية يعمل قبل المقاطعة، !irql يُظهر لك IRQL المحفوظ للمعالج المستهدف (على سبيل المثال DISPATCH_LEVEL).
لتحليل اتجاه المعلمة 1، !pool سيخبرك إذا كان ينتمي إلى مجموعة مقسمة إلى صفحات؛ !address y !pte التعمق في تخطيط الذاكرة لتلك المنطقة. يمكنك استخدام أوامر عرض الذاكرة لفحص المحتوى الذي تم محاولة الوصول إليه. وأخيرًا، u, ub, uu يسمح لك بالتفكيك حول عنوان المعلمة 4.
لا تنسى lm t n لإدراج الوحدات المحملة y !memusage للحالة العامة للذاكرة. إذا KiBugCheckDriver لديه شيئا ما dx KiBugCheckDriver سوف يقوم بإرجاع اسم وحدة Unicode: في مثال نموذجي، تم رؤية "Wdf01000.sys" باعتباره برنامج التشغيل المعني أثناء فحص الأخطاء.
أدوات النظام: التحقق من برنامج التشغيل، عارض الأحداث والتشخيصات
El التحقق من السائق يفحص سلوك برامج التشغيل في الوقت الفعلي ويفرض أخطاءً عند اكتشاف استخدام غير صحيح للموارد (مثل المجموعة)، ويثير استثناءً لعزل المنطقة المُشكلة في الكود. يتم تشغيله مع verifier من موجه الأوامر ومن المستحسن اختيار أصغر مجموعة ممكنة من برامج التشغيل لتجنب إضافة الكثير من النفقات العامة.
إذا كنت لا ترى نفسك مع WinDbg، تطبيق التدابير الأساسيةتحقق من سجل النظام في عارض الأحداث بحثًا عن أخطاء تشير إلى جهاز/برنامج تشغيل معين؛ حدّث أو عطّل برنامج التشغيل الذي تظهر عليه الشاشة الزرقاء؛ تحقق من توافق الأجهزة مع إصدار Windows لديك؛ واستخدم أداة تشخيص ذاكرة Windows إذا كنت تشك في وجود مشكلة في ذاكرة الوصول العشوائي (RAM). هذه الإجراءات، على الرغم من بساطتها، يقومون بحل عدد كبير من القضايا.
حالات واقعية: عندما تبدو شاشات الموت الزرقاء عشوائية
مستخدم يعمل بنظام التشغيل Windows 10 Pro (معالج AMD Ryzen 5 3400G، وحدة معالجة الرسوميات: NVIDIA بطاقة GeForce GTX 1660 Ti ولوحة Gigabyte B450 AORUS PRO WIFIكان جهازي (16 جيجابايت من ذاكرة الوصول العشوائي) يعاني من شاشات "IRQL_LESS_OR_NOT_EQUAL" المتقطعة. لقد قمتُ بالفعل بتحديث برامج التشغيل الأساسية (الشبكة والرسومات)، وثبّتُ جميع تحديثات Windows، وشغّلتُ أداة الذاكرة، وكل ذلك دون أي مشاكل.
في سيناريوهات مثل هذا، الخطوة التالية هي تحليل الملفات باستخدام WinDbg والبحث عن الأنماط: العمليات المتضمنة عند سقوطها (على سبيل المثال، explorer.exe), وحدات الواجهة الرسومية (win32kfull.sys) ووظائف مثل xxxProcessNotifyWinEvent تظهر في المكدس. على الرغم من أن هذه الوحدة تعمل بنظام Windows، إلا أن المُحفِّز غالبًا ما يكون برنامج تشغيل تابعًا لجهة خارجية (رسومات، إدخال، تراكب، بطاقات التقاط) يستخدم الذاكرة عند مستوى IRQL غير مناسب، وينشأ الخلل داخل win32k.
التوصية العملية هنا هي تعطيل برنامج التراكب مؤقتًا (التقاط، عرض رسومات على الشاشة)، وبرامج تشغيل ملحقاتية برمجية قوية (فئران/لوحات مفاتيح مزودة بوحدات ماكرو)، وإصدارات تجريبية من برامج تشغيل الرسومات، وتضييق نطاق البحث. استخدام Driver Verifier على الأجهزة المشتبه بها قد يساعد في تضييق نطاق المشكلة من خلال مجموعة بيانات أكثر وضوحًا.
نمط شبكة شائع جدًا: ndis.sys ليس هو السبب دائمًا
حالة نموذجية أخرى: لقطة شاشة باستخدام ndis.sys (طبقة شبكة ويندوز). على جهاز كمبيوتر حقيقي، كان النظام يتعطل فور بدء التشغيل. كان الحل العملي هو التمهيد إلى الوضع الآمن بدون وظائف الشبكة، افتح مدير الأجهزة وقم بتعطيل المحولات الموجودة ضمن "محولات الشبكة" لعزل المشكلة.
في ذلك الفريق كان هناك وحدة تحكم Realtek PCIe GBE Family وAtheros AR5007G. ومن خلال تعطيل كليهما، تم الكشف عن أن السبب الحقيقي هو athrx.sys (Atheros)، على الرغم من أن الشاشة الزرقاء المذكورة ndis.sysأكد التفريغ هذا: مرت المكدس من خلال ndis!NdisFreeTimerObject ولكن الوحدة المذنبة كانت athrx.sysالتصحيح النهائي كان قم بإلغاء تثبيت الجهاز وتثبيت برامج التشغيل الرسمية المحدثة من موقع الشركة المصنعة لـ Atheros. العبرة: قد تكون الوحدة المذكورة في شاشة الموت الزرقاء جزءًا من النظام الفرعي المتأثر، وليست المصدر.
استجابة الدعم النموذجية والخطوات السريعة للمستخدمين
في تبادل الدعم الحقيقي، رد أحد الفنيين: أعتذر عن الإزعاج. قد تكون المشكلة في برنامج التشغيل، أو الذاكرة، أو برنامج مكافحة الفيروسات. يُرجى تحديث برامج التشغيل، وإذا استمرت المشكلة، فقم بتشغيل تشخيص الذاكرة.هذه نصيحة أساسية ولكنها صحيحة؛ ومع ذلك، إذا استمرت الأخطاء، فمن الجيد أن تذهب أبعد من ذلك باستخدام Verifier وتحليل dump.
بالنسبة للمستخدمين غير الفنيين، سيكون البروتوكول المعقول هو: 1) التحقق من أحداث النظام، 2) تحديث برامج التشغيل الرئيسية (مجموعة الشرائح/الشبكة/الرسومات)، 3) التحقق من ذاكرة الوصول العشوائي (RAM) مع الأداة المتكاملة، 4) اختبار حذاء 5) قم بالتنظيف بدون برامج الطرف الثالث التي تقوم بإدراج خطافات في kernel/GUI، و5) استخدم Verifier على برامج التشغيل التابعة لجهات خارجية إذا لم يكن هناك شيء واضح.
أفضل الممارسات لمطوري برامج التشغيل
إذا كنت تقوم بالتطوير وتعثرت على D1/A، فتأكد من أن لم يتم وضع علامة على الروتين الجاري باعتباره قابلاً للترقيم لا تستدعي الدوال القابلة للتجزئة أثناء التشغيل بمستوى DISPATCH_LEVEL أو أعلى. يشمل ذلك تجنب الإشارة إلى البيانات في الأقسام المقسمة إلى صفحات، والالتزام بشروط IRQL لمساعدات النواة الموضحة في DDK.
لمزامنة البيانات المشتركة، تطبيق القاعدة "الوصول دائمًا إلى البيانات المشتركة بنفس مستوى IRQL المرتفع" استخدم أقفال الدوران عند الحاجة. في المعالجات متعددة المعالجات، لا يضمن IRQL وحده الاستبعاد بين وحدات المعالجة المركزية المختلفة؛ ترفع أقفال الدوران IRQL (إلى DISPATCH_LEVEL) وتُنسّق الوصول بين النوى. إذا كنت بحاجة إلى العمل على سجلات أجهزة حساسة، KeSynchronizeExecution يساعدك على تنفيذ الأقسام الحرجة في DIRQL الصحيح.
عندما تتطلب الخطة رفع IRQL، الولايات المتحدة الأمريكية KeRaiseIrqlToDpcLevel لـ DISPATCH_LEVEL أو KeRaiseIrql بحرص، حفظ IRQL السابق واستعادته تمامًا مع KeLowerIrql. انتقل إلى أسفل IRQL المدخل، حتى ولو للحظة واحدة، إنه خطأ مزامنة خطير.
العلاقة مع المقاطعات والأجهزة
IRQL هي الآلية التي يتم من خلالها تشغيل Windows تؤدي الأوامر إلى مقاطعة الأولويات وبعض المهام الداخليةعلى المستوى المعماري، يرتبط الأمر بمفاهيم مثل "المقاطعة" أو "معالج المقاطعة" أو "مستوى أولوية المقاطعة"، وعلى المنصات الكلاسيكية، مع وحدة تحكم المقاطعة القابلة للبرمجة (PIC)في الأنظمة الأخرى، يتم التعبير عن التحكم في الأولوية من خلال آليات مثل الاسكتلندي en يونكسالفكرة العامة هي نفسها: من يستطيع مقاطعة من.
نصائح متقدمة لتصحيح الأخطاء
في مكبات النفايات حيث تشير المكدس إلى win32kfull!xxxProcessNotifyWinEvent مع فحص الأخطاء 0xA/0xD1، افحص السياق باستخدام .process y .thread (إذا كان متاحًا)، انظر إلى العمليات مثل explorer.exe en !process 0 1 وتحقق من التراكبات وبرامج تشغيل تفاعل واجهة المستخدم الرسومية. في كثير من الأحيان، تكون المشكلة إنها ذاكرة فاسدة بسبب طرف ثالث يظهر على هذا الطريق.
لا تنسى التحقق من IRQL مع !irql، والتباين: إذا كنت في DISPATCH_LEVEL (2) ويشير المعامل 3 إلى القراءة/الكتابة/التنفيذ في صفحة قابلة للترقيم، لديك بالفعل دليل على سبب سقوطها. اربط هذا الدليل بـ ln في المعلمة 4 للحصول على الوظيفة المحددة.
فهم ما هو IRQL؟ وكيفية اندماجه في تنفيذ النواة يساعد على فصل الضوضاء عن الإشارات. إذا كنت مستخدمًا، ركز على برامج التشغيل والأجهزة (مع Verifier والأحداث والاختبارات افتراضيًا). إذا كنتَ تُطوّر، فاتبع بدقة قواعد IRQL والذاكرة غير المُصنَّفة والمزامنة مع أقفال الدوران. باستخدام الأدوات المناسبة (WinDbg وVerifier) والقراءة الدقيقة للمعلمات (1 و3 و4)، لم تعد عمليات التحقق من الأخطاء هذه لغزًا وتصبح هذه المشاكل قابلة للمعالجة بطريقة منهجية.
كاتب شغوف بعالم البايت والتكنولوجيا بشكل عام. أحب مشاركة معرفتي من خلال الكتابة، وهذا ما سأفعله في هذه المدونة، لأعرض لك كل الأشياء الأكثر إثارة للاهتمام حول الأدوات الذكية والبرامج والأجهزة والاتجاهات التكنولوجية والمزيد. هدفي هو مساعدتك على التنقل في العالم الرقمي بطريقة بسيطة ومسلية.