IRQL (Interrupt Request Level) ใน Windows คืออะไร และเกี่ยวข้องกับ BSOD อย่างไร

หากคุณเคยเห็นหน้าจอสีฟ้าที่มีข้อความเช่น IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NOT_LESS_OR_EQUALคุณอาจเคยเจอแนวคิดที่ไม่ค่อยมีใครรู้จักนอกโลกของไดรเวอร์: IRQL (ระดับคำขอขัดจังหวะ) Windowsระดับความสำคัญของการขัดจังหวะนี้จะมีความสำคัญเหนือกว่าความสำคัญของเธรดเมื่อระบบอยู่เหนือเกณฑ์บางอย่าง และสิ่งนี้ส่งผลโดยตรงต่อความเสถียร

ในบรรทัดถัดไปคุณจะพบ ,es คู่มือที่สมบูรณ์ และภาษาสเปนจากสเปนเกี่ยวกับ IRQL คืออะไรและทำงานอย่างไร, ทำไมมันถึงทำให้เกิดหน้าจอสีฟ้า, วิธีวินิจฉัยปัญหาด้วย WinDbg และสิ่งที่ต้องทำไม่ว่าคุณจะเป็นผู้ใช้ที่พบข้อผิดพลาดหรือกำลังพัฒนาไดรเวอร์โหมดเคอร์เนล มาเริ่มลงมือทำกันเลย

IRQL (Interrupt Request Level) ใน Windows คืออะไร

ใน Windows IRQL กำหนดลำดับความสำคัญของ ฮาร์ดแวร์ ซึ่งโปรเซสเซอร์ทำงานอยู่ ในเวลาใดก็ตาม ภายใน Windows Driver Model (WDM) โค้ดที่ทำงานที่ IRQL ต่ำอาจถูกขัดจังหวะโดยโค้ดที่ทำงานที่ IRQL สูงกว่า อันที่จริงแล้ว บนคอมพิวเตอร์มัลติคอร์เครื่องเดียว CPU แต่ละตัวสามารถทำงานที่ IRQL ที่แตกต่างกันได้ ซึ่งทำให้การซิงโครไนซ์มีความซับซ้อน

มีกฎสำคัญอยู่ข้อหนึ่ง: เมื่อ CPU ทำงานที่ IRQL สูงกว่า PASSIVE_LEVEL จะสามารถถูกแย่งชิงโดยกิจกรรมที่ IRQL สูงกว่าเท่านั้นสิ่งนี้จัดระเบียบการอยู่ร่วมกันระหว่างโค้ดผู้ใช้ ฟังก์ชันเคอร์เนล ผู้เรียกที่เลื่อนออกไป (DPC) และรูทีนบริการขัดจังหวะอุปกรณ์ (ISR)

ระดับและลำดับความสำคัญ: 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) ครอบคลุมตัวกำหนดตารางเวลาเธรดและ DPC ด้านบนคือระดับ DISPATCH_LEVEL ที่สงวนไว้สำหรับการขัดจังหวะอุปกรณ์ (หรือที่เรียกว่า DIRQL) และการใช้งานภายในอื่นๆ เช่น HIGH_LEVEL

ในระบบนิเวศของผู้ขับขี่ กิจวัตรทั่วไปหลายอย่างทำงานที่ระดับ DISPATCH_LEVELตัวอย่างเช่น DPC และ StartIo การออกแบบนี้ช่วยให้มั่นใจได้ว่าในขณะที่ระบบใดระบบหนึ่งกำลังติดต่อกับคิวภายในหรือทรัพยากรที่ใช้ร่วมกันอื่นๆ รูทีนอื่นในระดับเดียวกันจะไม่แย่งชิงทรัพยากรนั้นบน CPU นั้น เนื่องจากกฎการแย่งชิงอนุญาตให้มีการขัดจังหวะในระดับที่สูงกว่าเท่านั้น

ระหว่าง DISPATCH_LEVEL และระดับการสร้างโปรไฟล์/ระดับสูง มีพื้นที่สำหรับ การขัดจังหวะฮาร์ดแวร์ของแต่ละอุปกรณ์ (DIRQL)IRQL ของอุปกรณ์จะกำหนดลำดับความสำคัญเหนืออุปกรณ์อื่น ไดรเวอร์ WDM จะรับ IRQL นี้ระหว่าง IRP_MJ_PNP ด้วย IRP_MN_START_DEVICE IRQL ของอุปกรณ์นี้ไม่ใช่ค่าคงที่แบบโกลบอล แต่เป็นค่าที่เชื่อมโยงกับสายอินเทอร์รัปต์เฉพาะ

IRQL เทียบกับลำดับความสำคัญของเธรด

ขอแนะนำไม่ให้สับสนแนวคิด: ลำดับความสำคัญของเธรดจะตัดสินใจว่าตัวกำหนดเวลาจะเข้ามาขัดจังหวะเมื่อใดและเธรดใดจะดำเนินการIRQL ควบคุมประเภทของกิจกรรมที่สามารถดำเนินการได้ และการขัดจังหวะใดที่ถูกปิดบังไว้ เหนือ DISPATCH_LEVEL จะไม่มีการสลับเธรด: IRQL เป็นผู้ควบคุม ไม่ใช่ลำดับความสำคัญของเธรด

IRQL และ Paging: สิ่งที่คุณไม่ควรทำ

ผลทันทีของการเพิ่ม IRQL คือระบบ ไม่สามารถจัดการกับข้อผิดพลาดของหน้าได้กฎทอง: โค้ดที่ทำงานที่ระดับ DISPATCH_LEVEL ขึ้นไปจะไม่ทำให้เกิดข้อผิดพลาดหน้าเพจ ในทางปฏิบัติ นั่นหมายความว่ารูทีนเหล่านั้นและข้อมูลที่มันสัมผัส ต้องอยู่ในหน่วยความจำแบบไม่แบ่งหน้านอกจากนี้ ตัวช่วยเคอร์เนลบางตัวยังจำกัดการใช้งานตาม IRQL เช่น KeWaitForSingleObject สามารถเรียก DISPATCH_LEVEL ได้เฉพาะในกรณีที่คุณไม่ได้บล็อกอยู่ (หมดเวลาเป็นศูนย์) และหากหมดเวลาไม่เป็นศูนย์ คุณต้องอยู่ต่ำกว่า DISPATCH_LEVEL

การควบคุม IRQL อย่างชัดแจ้งและโดยนัย

ส่วนใหญ่แล้ว, ระบบจะเรียกใช้งานรูทีนของคุณด้วย IRQL ที่ถูกต้อง สำหรับสิ่งที่พวกเขาควรทำ รูทีน Dispatch สำหรับ 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_ไม่น้อยหรือเท่ากัน (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)ทั้งสองกรณีบ่งชี้ถึงความพยายามในการเข้าถึงแอดเดรสแบบเพจได้ (หรือแอดเดรสที่ไม่ถูกต้อง) ที่ IRQL สูงเกินไป ซึ่งมักเกิดจากไดรเวอร์ใช้แอดเดรสที่ไม่ถูกต้อง การยกเลิกการอ้างอิงพอยน์เตอร์ที่ไม่ถูกต้อง หรือการรันโค้ดแบบเพจได้ในระดับที่ไม่เหมาะสม

ในกรณีเฉพาะของ ไดรเวอร์ IRQL_NOT_LESS_OR_EQUAL (0x000000D1)พารามิเตอร์เหล่านี้มีประโยชน์มาก: 1) ที่อยู่หน่วยความจำที่อ้างอิง; 2) IRQL ณ ขณะนั้น; 3) ประเภทการเข้าถึง (อ่าน 0, เขียน 1, ดำเนินการ 2/8); 4) ที่อยู่ของคำสั่งที่อ้างอิงหน่วยความจำ คุณสามารถใช้ดีบักเกอร์ ln บนพารามิเตอร์ 4 สำหรับ แสดงรายการสัญลักษณ์ที่ใกล้ที่สุดและทราบว่าฟังก์ชันใดกำลังทำงานอยู่.

สาเหตุทั่วไปที่ควรคำนึงถึง

นอกเหนือจากโค้ดเฉพาะแล้ว ยังมีรูปแบบที่เกิดซ้ำอีก การยกเลิกการอ้างอิงตัวชี้ที่ไม่ถูกต้องไปยัง DISPATCH_LEVEL หรือสูงกว่า นี่คือสูตรแห่งหายนะอย่างแน่นอน การเข้าถึงข้อมูลแบบเพจได้ในระดับนั้น หรือการรันโค้ดแบบเพจได้ (เช่น ฟังก์ชันที่ทำเครื่องหมายว่าเพจได้) จะเป็นการกระตุ้นการตรวจสอบบั๊กด้วยเช่นกัน

กรณีทั่วไปอื่นๆ ได้แก่ เรียกใช้ฟังก์ชันในไดร์เวอร์อื่นที่ดาวน์โหลดไว้แล้ว (ตัวชี้ฟังก์ชันที่ค้างอยู่) หรือถูกเรียกใช้งานโดยอ้อมผ่านตัวชี้ฟังก์ชันที่ไม่ถูกต้อง บ่อยครั้ง หากระบบสามารถระบุโมดูลได้ คุณจะเห็นชื่อโมดูลนั้นบนหน้าจอสีน้ำเงิน และจะถูกบันทึกไว้ใน KiBugCheckDriver, สามารถเข้าถึงได้ด้วย dx KiBugCheckDriver จาก WinDbg

รายละเอียดเชิงปฏิบัติ: ใน D1/A ส่วนใหญ่ ปัญหาที่แท้จริงไม่ได้อยู่ที่ IRQL เองแต่เป็นที่อยู่หน่วยความจำที่อ้างอิงมากกว่า นั่นคือเหตุผลที่พารามิเตอร์ 1, 3 และ 4 จึงมีความสำคัญอย่างยิ่งต่อการมุ่งเน้นการวินิจฉัย

การวินิจฉัยด้วย WinDbg: คำสั่งที่มีประโยชน์และการอ่านพารามิเตอร์

ในการทำงานในกรณีเหล่านี้ WinDbg เป็นเครื่องมือสำคัญและถ้า BSOD กล่าวถึง ntoskrnl.exe ข้อมูลนี้ให้คำแนะนำมากมายว่าข้อผิดพลาดอยู่ที่ระบบย่อยเคอร์เนลหรือไม่ เริ่มต้นด้วย !analyze -v เพื่อรับข้อมูลสรุปของการตรวจสอบบั๊ก สแต็ก และหากโชคดี คุณสามารถดูโมดูลที่เกี่ยวข้องได้ หากดัมพ์มีเฟรมจับภาพ .trap ทำให้คุณอยู่ในบริบทของ CPU ที่ล้มเหลว

ลอส คำสั่ง ของกองเป็น k, kb, kc, kd, kp, kP, kv พวกเขาแสดงรายละเอียด backtrace ในระดับที่แตกต่างกันให้คุณเห็น 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 ใช้มาตรการพื้นฐาน: ตรวจสอบบันทึกระบบใน Event Viewer เพื่อหาข้อผิดพลาดที่ชี้ไปยังอุปกรณ์/ไดรเวอร์เฉพาะ อัปเดตหรือปิดใช้งานไดรเวอร์ที่หน้าจอสีน้ำเงินระบุ ตรวจสอบความเข้ากันได้ของฮาร์ดแวร์กับ Windows เวอร์ชันของคุณ และใช้ Windows Memory Diagnostic หากคุณสงสัยว่ามี RAM การดำเนินการเหล่านี้แม้จะง่าย แต่ พวกเขาแก้ไขคดีจำนวนมาก.

กรณีในชีวิตจริง: เมื่อ BSOD ดูเหมือนสุ่ม

ผู้ใช้ที่ใช้ Windows 10 Pro (AMD Ryzen 5 3400G CPU, GPU NVIDIA บอร์ด GeForce GTX 1660 Ti และ Gigabyte B450 AORUS PRO WIFI(RAM 16 GB) มีปัญหาหน้าจอ "IRQL_LESS_OR_NOT_EQUAL" ขึ้นเป็นระยะๆ ฉันได้อัปเดตไดรเวอร์ที่จำเป็น (เครือข่าย, กราฟิก) แล้ว ติดตั้งการอัปเดต Windows ทั้งหมด และเรียกใช้เครื่องมือหน่วยความจำ ทั้งหมดนี้ไม่พบปัญหาใดๆ เลย

ในสถานการณ์เช่นนี้ ขั้นตอนต่อไปคือการวิเคราะห์ข้อมูลดัมพ์ด้วย WinDbg และมองหารูปแบบ: กระบวนการที่เกี่ยวข้องเมื่อมันตก (ตัวอย่างเช่น explorer.exe), โมดูลอินเทอร์เฟซกราฟิก (win32kfull.sys) และฟังก์ชั่นต่างๆ เช่น xxxProcessNotifyWinEvent ปรากฏในสแต็ก แม้ว่าโมดูลนี้จะเป็น Windows แต่ตัวกระตุ้นมักจะเป็นไดรเวอร์ของบุคคลที่สาม (กราฟิก อินพุต โอเวอร์เลย์ การ์ดจับภาพ) ที่ใช้หน่วยความจำที่ IRQL ที่ไม่เหมาะสม และข้อผิดพลาดเกิดขึ้นภายใน win32k.

คำแนะนำเชิงปฏิบัติที่นี่คือ ปิดใช้งานซอฟต์แวร์โอเวอร์เลย์ชั่วคราว (การจับภาพ, GPU OSD), ไดรเวอร์อุปกรณ์ต่อพ่วงซอฟต์แวร์ที่มีประสิทธิภาพสูง (เมาส์/คีย์บอร์ดพร้อมมาโคร) และไดรเวอร์กราฟิกเวอร์ชันเบต้า และจำกัดขอบเขตให้แคบลง การใช้ Driver Verifier กับผู้ต้องสงสัยสามารถช่วยจำกัดขอบเขตปัญหาให้แคบลงด้วยชุดข้อมูลที่ชัดเจนยิ่งขึ้น

รูปแบบเครือข่ายทั่วไป: ndis.sys ไม่ใช่ผู้ร้ายเสมอไป

อีกกรณีทั่วไป: ภาพหน้าจอพร้อม ndis.sys (เลเยอร์เครือข่าย Windows) บนคอมพิวเตอร์จริง ระบบจะหยุดทำงานทันทีเมื่อเริ่มต้นระบบ วิธีแก้ปัญหาที่ได้ผลคือการบูตเข้า เซฟโหมด หากไม่มีฟังก์ชั่นเครือข่าย ให้เปิด ตัวจัดการอุปกรณ์ และปิดใช้งานอะแดปเตอร์ภายใต้ “อะแดปเตอร์เครือข่าย” เพื่อแยกปัญหา

ในทีมนั้นมี ตัวควบคุม Realtek PCIe GBE Family และ Atheros AR5007G. โดยการปิดใช้งานทั้งสองอย่าง พบว่าสาเหตุที่แท้จริงคือ athrx.sys (Atheros) ถึงแม้ว่าหน้าจอสีฟ้าจะกล่าวถึง ndis.sysการถ่ายโอนข้อมูลยืนยันสิ่งนี้: สแต็กผ่านแล้ว ndis!NdisFreeTimerObject แต่โมดูลที่มีความผิดคือ athrx.sysการแก้ไขครั้งสุดท้ายคือ ถอนการติดตั้งอุปกรณ์และติดตั้งไดรเวอร์อย่างเป็นทางการที่อัปเดตแล้ว จากเว็บไซต์ของผู้ผลิต Atheros ข้อคิด: โมดูลที่อ้างถึงใน BSOD อาจเป็นส่วนหนึ่งของระบบย่อยที่ได้รับผลกระทบ ไม่ใช่แหล่งที่มา

การตอบสนองการสนับสนุนทั่วไปและขั้นตอนด่วนสำหรับผู้ใช้

ในการแลกเปลี่ยนการสนับสนุนที่แท้จริง ช่างเทคนิคตอบกลับ: ขออภัยในความไม่สะดวก อาจเป็นปัญหาที่ไดรเวอร์ หน่วยความจำ หรือโปรแกรมป้องกันไวรัส โปรดอัปเดตไดรเวอร์ของคุณ และหากยังคงมีปัญหาอยู่ ให้เรียกใช้การวินิจฉัยหน่วยความจำนี่เป็นคำแนะนำพื้นฐานแต่ก็มีประโยชน์ อย่างไรก็ตาม หากข้อผิดพลาดยังคงมีอยู่ ควรใช้ Verifier และการวิเคราะห์ข้อมูลทิ้งต่อไป

สำหรับผู้ใช้ที่ไม่ใช่ช่างเทคนิค โปรโตคอลที่เหมาะสมจะเป็นดังนี้: 1) ตรวจสอบเหตุการณ์ระบบ 2) อัปเดตไดรเวอร์หลัก (ชิปเซ็ต/เครือข่าย/กราฟิก) 3) ตรวจสอบ RAM ด้วยเครื่องมือแบบบูรณาการ 4) ทดสอบ รองเท้า ทำความสะอาดโดยไม่ต้องใช้ซอฟต์แวร์ของบริษัทอื่นที่แทรกฮุกเข้าไปในเคอร์เนล/GUI และ 5) ใช้ Verifier บนไดรเวอร์ของบริษัทอื่นหากไม่มีอะไรชัดเจน

แนวทางปฏิบัติที่ดีที่สุดสำหรับนักพัฒนาไดรเวอร์

หากคุณกำลังพัฒนาและพบ D1/A ให้ตรวจสอบว่า กิจวัตรการทำงานไม่ได้ถูกทำเครื่องหมายว่าสามารถแบ่งหน้าได้ อย่าเรียกใช้ฟังก์ชันแบบเพจได้ขณะทำงานที่ระดับ DISPATCH_LEVEL หรือสูงกว่า ซึ่งรวมถึงการหลีกเลี่ยงการอ้างอิงข้อมูลในส่วนที่แบ่งเพจ และปฏิบัติตามข้อจำกัด IRQL สำหรับตัวช่วยเคอร์เนลที่อธิบายไว้ใน DDK

เพื่อซิงโครไนซ์ข้อมูลที่แชร์ ใช้กฎ "เข้าถึงข้อมูลที่แชร์ด้วย IRQL สูงเท่ากันเสมอ" และใช้ spin lock เมื่อเหมาะสม สำหรับมัลติโปรเซสเซอร์ IRQL เพียงอย่างเดียวไม่ได้รับประกันการแยกกันระหว่าง CPU ที่แตกต่างกัน spin lock จะเพิ่ม 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 และตรวจสอบโอเวอร์เลย์และไดรเวอร์การโต้ตอบของ GUI หลายครั้งที่ปัญหา เป็นหน่วยความจำที่ถูกทำลายโดยบุคคลที่สามซึ่งปรากฏบนเส้นทางนั้น.

อย่าลืมตรวจสอบ IRQL ด้วย !irql, และความแตกต่าง: หากคุณอยู่ที่ DISPATCH_LEVEL (2) และพารามิเตอร์ 3 ระบุว่าอ่าน/เขียน/ดำเนินการ ในหน้าเพจ คุณมีเบาะแสแล้วว่าทำไมมันถึงตก ขีดเบาะแสนั้นด้วย ln ในพารามิเตอร์ 4 เพื่อรับฟังก์ชันเฉพาะ

เพื่อให้เข้าใจ IRQL คืออะไร? และวิธีที่มันเข้ากับการทำงานของเคอร์เนลช่วยแยกสัญญาณรบกวนออกจากสัญญาณ หากคุณเป็นผู้ใช้ ให้เน้นที่ ไดรเวอร์และฮาร์ดแวร์ (พร้อม Verifier, events และ tests เป็นค่าเริ่มต้น) หากคุณพัฒนา โปรดปฏิบัติตามกฎสำหรับ IRQL, หน่วยความจำแบบไม่เพจ และการซิงโครไนซ์ด้วย spin lock อย่างเคร่งครัด ด้วยเครื่องมือที่เหมาะสม (WinDbg, Verifier) ​​และการอ่านพารามิเตอร์ (1, 3 และ 4) อย่างละเอียด การตรวจสอบจุดบกพร่องเหล่านี้ไม่ใช่เรื่องลึกลับอีกต่อไป และมันกลายเป็นปัญหาที่สามารถแก้ไขได้อย่างเป็นระบบ