Що таке IRQL (рівень запиту на переривання) у Windows і як він пов'язаний з BSOD?

Якщо ви коли-небудь бачили синій екран із повідомленнями, подібними до IRQL_NOT_LESS_OR_EQUAL DRIVER_IRQL_NOT_LESS_OR_EQUAL, ви, ймовірно, стикалися з концепцією, маловідомою поза світом драйверів: IRQL (рівень запиту на переривання). Windows, цей рівень пріоритету переривань має перевагу над пріоритетом потоків, коли система перевищує певний поріг, і це має прямі наслідки для стабільності.

У наступних рядках ви знайдете u повне керівництво та іспанською мовою з Іспанії про те, що таке IRQL, як він працює, чому це викликає сині екрани, як діагностувати проблему з WinDbg та що робити, незалежно від того, чи ви користувач, який стикається з помилкою, чи розробляєте драйвери режиму ядра. Давайте перейдемо до справи.

Що таке IRQL (рівень запиту на переривання) у Windows?

У Windows, IRQL визначає пріоритет апаратні засоби на якому працює процесор у будь-який момент часу. У моделі драйверів Windows (WDM) код, що виконується з низьким рівнем IRQL, може бути перерваний кодом, що виконується з вищим рівнем IRQL. Фактично, на одному багатоядерному комп'ютері кожен процесор може мати різний IRQL, що ускладнює синхронізацію.

Є одне головне правило: Коли процесор працює з 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. Така конструкція гарантує, що поки одна з них торкається внутрішніх черг або інших спільних ресурсів, інша процедура на тому ж рівні не витісняє її на цьому процесорі, оскільки правило витіснення дозволяє переривання лише на вищих рівнях.

Між DISPATCH_LEVEL та рівнями профілювання/високими рівнями є місце для апаратні переривання кожного пристрою (DIRQL)IRQL пристрою визначає його пріоритет над іншими пристроями. Драйвер WDM отримує цей IRQL під час IRP_MJ_PNP з IRP_MN_START_DEVICE. Цей 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_NOT_LESS_OR_EQUAL (0xA) y DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1)Обидва вказують на спробу доступу до сторінкуємої (або недійсної) адреси з занадто високим рівнем IRQL. Зазвичай це відбувається через те, що драйвери використовують неправильні адреси, розіменовують погані вказівники або виконують сторінкуємий код на неналежних рівнях.

У конкретному випадку о DRIVER_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 ставить вас у контекст несправного процесора.

L Команди купи як 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, якщо ви підозрюєте наявність оперативної пам’яті. Ці дії, хоча й прості, вони вирішують велику кількість справ.

Реальні випадки: коли BSOD здаються випадковими

Користувач з Windows 10 Pro (процесор AMD Ryzen 5 3400G, GPU NVIDIA Материнська плата GeForce GTX 1660 Ti та Gigabyte B450 AORUS PRO з Wi-Fi, 16 ГБ оперативної пам'яті) періодично виникали повідомлення "IRQL_LESS_OR_NOT_EQUAL". Я вже оновив необхідні драйвери (мережеві, графічні), встановив усі оновлення Windows і запустив інструмент пам'яті, і все це без виявлення жодних проблем.

У таких сценаріях, Наступний крок – аналіз дампів за допомогою WinDbg і шукайте закономірності: процеси, що відбуваються під час його падіння (наприклад, explorer.exe), модулі графічного інтерфейсу (win32kfull.sys) та такі функції, як xxxProcessNotifyWinEvent з'являються в стеку. Хоча цей модуль призначений для Windows, причиною часто є драйвер стороннього виробника (графічна карта, карта введення, накладання, плата захоплення), який використовує пам'ять з невідповідним рівнем IRQL, і помилка виникає всередині win32k.

Практична рекомендація тут така тимчасово вимкніть програмне забезпечення для накладання (захоплення, екранне меню графічного процесора), агресивні драйвери периферійних пристроїв (миші/клавіатури з макросами) та бета-версії драйверів графіки, і звузити коло пошуку. Використання засобу перевірки драйверів на підозрілих об'єктах може допомогти звузити коло проблем із чіткішим стеком.

Дуже поширена мережева схема: ndis.sys не завжди є винуватцем

Ще один типовий випадок: знімок екрана з ndis.sys (мережевий рівень Windows). На реальному комп’ютері система аварійно завершувала б роботу одразу після запуску. Практичним рішенням було завантажитися в Безпечний режим без мережевих функцій відкрийте Диспетчер пристроїв і вимкніть адаптери в розділі «Мережеві адаптери», щоб усунути проблему.

У тій команді був Контролер сімейства Realtek PCIe GBE та Atheros AR5007GДеактивувавши обидва, було виявлено, що справжньою причиною було athrx.sys (Atheros), хоча на синьому екрані згадувалося ndis.sysДамп підтвердив це: стек пройшов через ndis!NdisFreeTimerObject але винним модулем був athrx.sysОстаточна корекція була видаліть пристрій та встановіть оновлені офіційні драйвери З веб-сайту виробника Atheros. Мораль: Модуль, згаданий у BSOD, може бути частиною ураженої підсистеми, а не її джерелом.

Типова відповідь служби підтримки та швидкі кроки для користувачів

Під час щирого обміну підтримкою технік відповів: «Вибачте за незручності. Можливо, проблема з драйвером, пам’яттю або антивірусом. Оновіть драйвери та, якщо проблема не зникає, запустіть діагностику пам’яті».Це базова, але слушна порада; однак, якщо помилки не зникають, варто продовжити роботу з Verifier та аналізом дампу.

Для користувачів, які не мають технічних знань, розумним протоколом буде: 1) Перевірте системні події, 2) Оновіть ключові драйвери (чіпсет/мережа/відеокарта), 3) Перевірте оперативну пам'ять за допомогою інтегрованого інструменту, 4) тест завантаження очистити без стороннього програмного забезпечення, яке вставляє перехоплювачі в ядро/графічний інтерфейс, та 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, несторінкової пам'яті та синхронізації зі spin-locks. За допомогою правильних інструментів (WinDbg, Verifier) ​​та уважного читання параметрів (1, 3 та 4), Ці перевірки на наявність помилок більше не є загадкою. і вони стають проблемами, які можна вирішувати методично.