Что такое IRQL (уровень запроса на прерывание) в Windows и как он связан с BSOD?

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

В следующих строках вы найдете уна полное руководство и на испанском языке из Испании о том, что такое 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) управляет тем, какие типы действий могут быть выполнены, и какие прерывания маскируются. Выше уровня 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 помещает вас в контекст неисправного ЦП.

команды из кучи как 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 WIFI(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) тест Загрузка очистить без стороннего ПО, которое вставляет хуки в ядро/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)В других системах управление приоритетами осуществляется с помощью таких механизмов, как SPL 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), Эти проверки на наличие ошибок больше не являются загадкой и они становятся проблемами, которые можно решать методично.