IRQL (Mức yêu cầu ngắt) trong Windows là gì và nó liên quan như thế nào đến BSOD?

Nếu bạn đã từng thấy màn hình xanh với các thông báo như IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_KHÔNG_ÍT_HAY_BẰNG, bạn có thể đã bắt gặp một khái niệm ít được biết đến bên ngoài thế giới trình điều khiển: IRQL (Mức yêu cầu ngắt). Trong Cửa sổmức độ ưu tiên ngắt này sẽ được ưu tiên hơn mức độ ưu tiên của luồng khi hệ thống vượt quá một ngưỡng nhất định và điều này có hậu quả trực tiếp đến tính ổn định.

Trong các dòng tiếp theo bạn sẽ tìm thấy một hướng dẫn đầy đủ và bằng tiếng Tây Ban Nha từ Tây Ban Nha về IRQL là gì, nó hoạt động như thế nào, tại sao nó gây ra màn hình xanh, cách chẩn đoán sự cố với WinDbg và phải làm gì dù bạn là người dùng gặp lỗi hay đang phát triển trình điều khiển chế độ hạt nhân. Hãy cùng bắt tay vào việc.

IRQL (Mức yêu cầu ngắt) trong Windows là gì?

Trong Windows, IRQL xác định mức độ ưu tiên của phần cứng tại đó bộ xử lý hoạt động tại bất kỳ thời điểm nào. Trong Mô hình Trình điều khiển Windows (WDM), mã chạy ở IRQL thấp có thể bị ngắt bởi mã chạy ở IRQL cao hơn. Trên thực tế, trên một máy tính đa lõi, mỗi CPU có thể có IRQL khác nhau, điều này làm phức tạp quá trình đồng bộ hóa.

Có một quy tắc quan trọng: Khi CPU chạy ở IRQL cao hơn PASSIVE_LEVEL, nó chỉ có thể bị chiếm quyền bởi hoạt động ở IRQL cao hơn nữa.Điều này tổ chức sự cùng tồn tại giữa mã người dùng, hàm hạt nhân, trình gọi bị trì hoãn (DPC) và các chương trình dịch vụ ngắt thiết bị (ISR).

Mức độ và mức độ ưu tiên: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL và DIRQL

Trong các điều khoản chung, Trên x86, các giá trị IRQL từ 0 đến 31 được sử dụng; trên x64, từ 0 đến 15Ý nghĩa thực tế cũng giống nhau: IRQL 0 (PASSIVE_LEVEL) là nơi mã người dùng thông thường và nhiều hàm trình điều khiển được thực thi; APC và lỗi trang Chúng thường được ánh xạ đến IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) bao gồm bộ lập lịch luồng và DPC. Phía trên DISPATCH_LEVEL là các mức dành riêng cho ngắt thiết bị (được gọi là DIRQL) và các mục đích sử dụng nội bộ khác như HIGH_LEVEL.

Trong hệ sinh thái trình điều khiển, Nhiều thói quen chung chạy ở DISPATCH_LEVEL: ví dụ, DPC và StartIo. Thiết kế này đảm bảo rằng khi một trong số chúng chạm đến hàng đợi nội bộ hoặc các tài nguyên dùng chung khác, một chương trình con khác ở cùng cấp sẽ không chiếm quyền sử dụng nó trên CPU đó, vì quy tắc chiếm quyền chỉ cho phép ngắt ở cấp cao hơn.

Giữa DISPATCH_LEVEL và mức độ lập hồ sơ/cao có chỗ cho ngắt phần cứng cho mỗi thiết bị (DIRQL)IRQL của một thiết bị xác định mức độ ưu tiên của nó so với các thiết bị khác. Trình điều khiển WDM lấy IRQL này trong quá trình IRP_MJ_PNP với IRP_MN_START_DEVICE. IRQL của thiết bị này không phải là một giá trị cố định toàn cục, mà là giá trị được liên kết với một đường ngắt cụ thể.

IRQL so với Ưu tiên luồng

Nên tránh nhầm lẫn các khái niệm: Mức độ ưu tiên của luồng quyết định khi nào trình lập lịch chiếm quyền trước và luồng nào sẽ thực thi; IRQL kiểm soát loại hoạt động nào có thể được thực thi và ngắt nào được che dấu. Trên DISPATCH_LEVEL, không có chuyển đổi luồng: IRQL kiểm soát, chứ không phải mức độ ưu tiên của luồng.

IRQL và Phân trang: Những điều bạn không nên làm

Một tác động tức thời của việc nâng cao IRQL là hệ thống không thể xử lý lỗi trangNguyên tắc vàng: mã chạy ở mức DISPATCH_LEVEL trở lên không thể gây ra lỗi trang. Trên thực tế, điều này có nghĩa là các chương trình con và dữ liệu mà chúng chạm đến phải nằm trong bộ nhớ không phân trang. Ngoài ra, một số trình trợ giúp hạt nhân hạn chế việc sử dụng dựa trên IRQL: ví dụ, KeWaitForSingleObject DISPATCH_LEVEL chỉ có thể được gọi nếu bạn không chặn (thời gian chờ bằng không) và đối với thời gian chờ khác không, bạn cần phải ở dưới DISPATCH_LEVEL.

Kiểm soát ngầm định và rõ ràng của IRQL

Hầu hết thời gian, hệ thống tự nó gọi các thói quen của bạn ở IRQL chính xác để biết chúng nên làm gì. Các chương trình điều phối cho IRP chạy ở PASSIVE_LEVEL (chúng có thể chặn hoặc gọi bất kỳ trình trợ giúp nào), StartIo và DPC chạy ở DISPATCH_LEVEL để bảo vệ hàng đợi dùng chung và ISR chạy ở DIRQL.

Nếu bạn cần kiểm soát nó một cách rõ ràng, Bạn có thể tăng và giảm IRQL bằng KeRaiseIrql y KeLowerIrqlCó một phím tắt rất hữu ích: KeRaiseIrqlToDpcLevel() trả về IRQL trước đó và giữ nguyên trạng thái DISPATCH_LEVEL. Quan trọng: Không bao giờ hạ IRQL xuống dưới giá trị khi hệ thống gọi bạn; việc phá vỡ sự đồng bộ hóa đó có thể mở ra tình trạng chạy đua rất nghiêm trọng.

Lỗi màn hình xanh liên quan đến IRQL: IRQL_NOT_LESS_OR_EQUAL và DRIVER_IRQL_NOT_LESS_OR_EQUAL

Hai kiểm tra lỗi cổ điển liên quan đến những vấn đề này là IRQL_KHÔNG_ÍT_HAY_BẰNG (0xA) y DRIVER_IRQL_KHÔNG_ÍT_HAY_BẰNG (0xD1)Cả hai đều chỉ ra nỗ lực truy cập một địa chỉ có thể phân trang (hoặc không hợp lệ) ở IRQL quá cao. Điều này thường do trình điều khiển sử dụng địa chỉ không chính xác, hủy tham chiếu các con trỏ lỗi hoặc thực thi mã có thể phân trang ở cấp độ không phù hợp.

Trong trường hợp cụ thể của DRIVER_IRQL_KHÔNG_ÍT_HOẶC_BẰNG (0x000000D1), các tham số rất hữu ích: 1) địa chỉ bộ nhớ được tham chiếu; 2) IRQL tại thời điểm đó; 3) kiểu truy cập (0 đọc, 1 ghi, 2/8 thực thi); 4) địa chỉ của lệnh đã tham chiếu đến bộ nhớ. Với trình gỡ lỗi, bạn có thể sử dụng ln trên tham số 4 cho liệt kê ký hiệu gần nhất và biết chức năng nào đang chạy.

Những nguyên nhân phổ biến cần lưu ý

Ngoài mã cụ thể, còn có những mẫu được lặp lại. Hủy tham chiếu một con trỏ không hợp lệ tới DISPATCH_LEVEL hoặc cao hơn Đây chắc chắn là một công thức dẫn đến thảm họa. Việc truy cập dữ liệu có thể phân trang ở cấp độ đó hoặc thực thi mã có thể phân trang (ví dụ: một hàm được đánh dấu là có thể phân trang) cũng sẽ kích hoạt kiểm tra lỗi.

Các trường hợp phổ biến khác bao gồm gọi một hàm trong trình điều khiển khác đã được tải xuống (con trỏ hàm treo), hoặc được gọi gián tiếp thông qua một con trỏ hàm không hợp lệ. Thông thường, nếu hệ thống có thể xác định một mô-đun, bạn sẽ thấy tên của nó trên chính màn hình xanh lam và nó cũng được lưu trong KiBugCheckDriver, có thể truy cập bằng dx KiBugCheckDriver từ WinDbg.

Một chi tiết thực tế: Trong hầu hết các D1/A, vấn đề thực sự không phải là IRQL, mà là địa chỉ bộ nhớ được tham chiếu. Đó là lý do tại sao các tham số 1, 3 và 4 rất quan trọng để tập trung chẩn đoán.

Chẩn đoán bằng WinDbg: Các lệnh hữu ích và đọc tham số

Để giải quyết những trường hợp này, WinDbg là công cụ chínhvà nếu BSOD đề cập đến ntoskrnl.exe Thông tin này cung cấp nhiều hướng dẫn về việc liệu lỗi có nằm ở hệ thống con hạt nhân hay không. Bắt đầu bằng !analyze -v để có được bản tóm tắt về kiểm tra lỗi, ngăn xếp và, nếu bạn may mắn, cả mô-đun liên quan. Nếu bản dump bao gồm một khung chụp, .trap đưa bạn vào bối cảnh CPU bị lỗi.

Các lệnh của đống như k, kb, kc, kd, kp, kP, kv Chúng cho bạn thấy các mức độ chi tiết khác nhau của backtrace. Với ln ở tham số 4 bạn có thể bỏ qua đến hướng dẫn tham chiếu đến bộ nhớ và lấy biểu tượng gần đó. Và nếu bạn nghi ngờ mức độ ưu tiên đang chạy trước khi ngắt, !irql hiển thị cho bạn IRQL đã lưu cho bộ xử lý đích (ví dụ: DISPATCH_LEVEL).

Để phân tích hướng của tham số 1, !pool Nó sẽ cho bạn biết liệu nó có thuộc nhóm được phân trang hay không; !address y !pte đi sâu vào bản đồ bộ nhớ của khu vực đó. Bạn có thể sử dụng các lệnh hiển thị bộ nhớ để kiểm tra nội dung đã được cố gắng truy cập. Cuối cùng, u, ub, uu cho phép bạn phân tách xung quanh địa chỉ của tham số 4.

Đừng quên lm t n để liệt kê các mô-đun đã tải y !memusage cho trạng thái chung của bộ nhớ. Nếu KiBugCheckDriver có cái gì đó, dx KiBugCheckDriver Nó sẽ trả về tên của mô-đun Unicode: trong một ví dụ điển hình, “Wdf01000.sys” được coi là trình điều khiển liên quan trong quá trình kiểm tra lỗi.

Công cụ hệ thống: Trình xác minh trình điều khiển, Trình xem sự kiện và Chẩn đoán

El Trình xác minh trình điều khiển Kiểm tra hành vi của trình điều khiển theo thời gian thực và buộc lỗi khi phát hiện việc sử dụng tài nguyên không chính xác (chẳng hạn như nhóm), đưa ra ngoại lệ để cô lập khu vực có vấn đề của mã. Nó được khởi chạy với verifier từ nhắc lệnh và nên chọn bộ trình điều khiển nhỏ nhất có thể để tránh phát sinh quá nhiều chi phí.

Nếu bạn không thấy mình có WinDbg, áp dụng các biện pháp cơ bản: Kiểm tra nhật ký hệ thống trong Trình xem Sự kiện để tìm lỗi chỉ ra thiết bị/trình điều khiển cụ thể; cập nhật hoặc tắt trình điều khiển được trích dẫn bởi màn hình xanh; xác minh tính tương thích của phần cứng với phiên bản Windows của bạn; và sử dụng Chẩn đoán Bộ nhớ Windows nếu bạn nghi ngờ RAM. Những thao tác này, mặc dù đơn giản, họ giải quyết một số lượng lớn các vụ án.

Các trường hợp thực tế: Khi BSOD có vẻ ngẫu nhiên

Người dùng sử dụng Windows 10 Pro (CPU AMD Ryzen 5 3400G, GPU NVIDIA Bo mạch chủ GeForce GTX 1660 Ti và Gigabyte B450 AORUS PRO WIFI, 16 GB RAM) thỉnh thoảng gặp lỗi "IRQL_LESS_OR_NOT_EQUAL". Tôi đã cập nhật các trình điều khiển thiết yếu (mạng, đồ họa), cài đặt tất cả các bản cập nhật Windows và chạy công cụ kiểm tra bộ nhớ mà không phát hiện ra bất kỳ sự cố nào.

Trong những tình huống như thế này, Bước tiếp theo là phân tích bản dump với WinDbg và tìm kiếm các mẫu: các quá trình liên quan khi nó rơi (ví dụ, explorer.exe), các mô-đun giao diện đồ họa (win32kfull.sys) và các chức năng như xxxProcessNotifyWinEvent xuất hiện trong ngăn xếp. Mặc dù mô-đun này là Windows, trình kích hoạt thường là trình điều khiển của bên thứ ba (đồ họa, đầu vào, lớp phủ, thẻ ghi) sử dụng bộ nhớ ở IRQL không phù hợp và lỗi phát sinh trong win32k.

Khuyến nghị thực tế ở đây là tạm thời vô hiệu hóa phần mềm lớp phủ (ghi hình, GPU OSD), trình điều khiển thiết bị ngoại vi phần mềm mạnh (chuột/bàn phím có macro) và phiên bản beta của trình điều khiển đồ họa, và thu hẹp phạm vi. Sử dụng Trình xác minh Trình điều khiển trên các thiết bị nghi ngờ có thể giúp thu hẹp vấn đề bằng cách xác định rõ ràng hơn.

Một mô hình rất phổ biến trong mạng: ndis.sys không phải lúc nào cũng là thủ phạm

Một trường hợp điển hình khác: ảnh chụp màn hình với ndis.sys (lớp mạng Windows). Trên một máy tính thực tế, hệ thống sẽ bị sập ngay khi khởi động. Giải pháp thực tế là khởi động vào Chế độ an toàn không có chức năng mạng, hãy mở Trình quản lý thiết bị và vô hiệu hóa bộ điều hợp trong “Bộ điều hợp mạng” để xác định vấn đề.

Trong đội đó có một Bộ điều khiển Realtek PCIe GBE Family và Atheros AR5007G. Bằng cách vô hiệu hóa cả hai, người ta phát hiện ra rằng nguyên nhân thực sự là athrx.sys (Atheros), mặc dù màn hình xanh đã đề cập ndis.sysBản dump đã xác nhận điều này: ngăn xếp đã đi qua ndis!NdisFreeTimerObject nhưng mô-đun có tội là athrx.sysSự sửa chữa cuối cùng là gỡ cài đặt thiết bị và cài đặt trình điều khiển chính thức đã cập nhật Từ trang web của nhà sản xuất Atheros. Bài học rút ra: Mô-đun được trích dẫn trong BSOD có thể là một phần của hệ thống con bị ảnh hưởng, chứ không phải là nguồn.

Phản hồi hỗ trợ điển hình và các bước nhanh chóng dành cho người dùng

Trong một cuộc trao đổi hỗ trợ chân thực, một kỹ thuật viên đã trả lời: "Tôi xin lỗi vì sự bất tiện này. Có thể do lỗi trình điều khiển, bộ nhớ hoặc phần mềm diệt vi-rút. Vui lòng cập nhật trình điều khiển và nếu vẫn còn lỗi, hãy chạy chẩn đoán bộ nhớ."Đây là lời khuyên cơ bản nhưng hợp lý; tuy nhiên, nếu lỗi vẫn tiếp diễn, bạn nên sử dụng Verifier và phân tích dump.

Đối với người dùng không am hiểu kỹ thuật, một giao thức hợp lý sẽ là: 1) Kiểm tra sự kiện hệ thống, 2) Cập nhật trình điều khiển chính (chipset/mạng/đồ họa), 3) Kiểm tra RAM với công cụ tích hợp, 4) kiểm tra khởi động sạch mà không cần phần mềm của bên thứ ba chèn móc vào hạt nhân/GUI và 5) sử dụng Verifier trên trình điều khiển của bên thứ ba nếu không có gì rõ ràng.

Thực hành tốt nhất cho nhà phát triển trình điều khiển

Nếu bạn đang phát triển và bạn tình cờ gặp D1/A, hãy kiểm tra xem thói quen chạy không được đánh dấu là có thể phân trang Không gọi các hàm phân trang khi chạy ở cấp độ DISPATCH_LEVEL hoặc cao hơn. Điều này bao gồm việc tránh tham chiếu đến dữ liệu trong các phần phân trang và tuân thủ các hạn chế IRQL đối với các trình trợ giúp kernel được mô tả trong DDK.

Để đồng bộ hóa dữ liệu được chia sẻ, áp dụng quy tắc "luôn truy cập dữ liệu được chia sẻ ở cùng IRQL cao" và sử dụng khóa xoay khi cần thiết. Trên các bộ xử lý đa lõi, IRQL đơn thuần không đảm bảo tính loại trừ giữa các CPU khác nhau; khóa xoay sẽ nâng IRQL (lên DISPATCH_LEVEL) và điều phối truy cập giữa các lõi. Nếu bạn cần thao tác trên các thanh ghi phần cứng nhạy cảm, KeSynchronizeExecution giúp bạn thực hiện các phần quan trọng ở DIRQL chính xác.

Khi kế hoạch yêu cầu nâng cao IRQL, Hoa Kỳ KeRaiseIrqlToDpcLevel cho DISPATCH_LEVEL hoặc KeRaiseIrql cẩn thận, lưu IRQL trước đó và khôi phục nó chính xác bằng KeLowerIrql. Đi xuống dưới IRQL đầu vào, ngay cả chỉ trong chốc lát, Đây là lỗi đồng bộ hóa nghiêm trọng.

Mối quan hệ với ngắt và phần cứng

IRQL là cơ chế mà Windows lệnh làm gián đoạn các ưu tiên và một số nhiệm vụ nội bộỞ cấp độ kiến ​​trúc, nó liên quan đến các khái niệm như "Ngắt", "Trình xử lý ngắt" hoặc "Mức độ ưu tiên ngắt" và trên các nền tảng cổ điển, với Bộ điều khiển ngắt có thể lập trình (PIC)Trong các hệ thống khác, quyền kiểm soát ưu tiên được thể hiện thông qua các cơ chế như tách en Unix; ý tưởng chung là như nhau: ai có thể ngắt lời ai.

Mẹo gỡ lỗi nâng cao

Trong các bản dump nơi ngăn xếp trỏ tới win32kfull!xxxProcessNotifyWinEvent với kiểm tra lỗi 0xA/0xD1, kiểm tra ngữ cảnh với .process y .thread (nếu có), hãy xem các quy trình như explorer.exe en !process 0 1 và kiểm tra lớp phủ và trình điều khiển tương tác GUI. Nhiều lần vấn đề Đó là bộ nhớ bị hỏng bởi một bên thứ ba xuất hiện trên tuyến đường đó.

Đừng quên kiểm tra IRQL với !irqlvà tương phản: nếu bạn đang ở DISPATCH_LEVEL (2) và tham số 3 chỉ ra đọc/ghi/thực thi trên một trang có thể phân trang, bạn đã có manh mối về lý do tại sao nó đã rơi. Hãy kết nối manh mối đó với ln trong tham số 4 để có được chức năng cụ thể.

Hiểu IRQL là gì? và cách nó phù hợp với việc thực thi kernel giúp tách nhiễu khỏi tín hiệu. Nếu bạn là người dùng, hãy tập trung vào trình điều khiển và phần cứng (với Verifier, sự kiện và kiểm tra theo mặc định). Nếu bạn phát triển, hãy tuân thủ nghiêm ngặt các quy tắc về IRQL, bộ nhớ không phân trang và đồng bộ hóa với khóa spin. Với các công cụ phù hợp (WinDbg, Verifier) ​​​​và việc đọc kỹ các tham số (1, 3 và 4), Những kiểm tra lỗi này không còn là điều bí ẩn nữa và chúng trở thành những vấn đề có thể được giải quyết một cách có phương pháp.