Выявляем и устраняем причины BSOD с кодом остановки IRQL NOT LESS OR EQUAL

Хоть явление BSOD, само по себе, и не является чем-то редким, его точная диагностика, в практических реалиях, подчас может поставить в тупик даже опытных пользователей, по причине крайне большого многообразия триггерных факторов. И это лишь пол беды, ведь помимо этого неясная ситуация осложняется еще и тем, что порой даже сама Windows не оставляет юзеру необходимых зацепок и ссылок на первопричину, поиск которых потребует терпения и тщательного анализа дампов памяти. К слову, именно такая картина, весьма нередко случается в контексте BSOD сбоя IRQL NOT LESS OR EQUAL, предпосылки и лечение которого и станут сегодня главным объектом нашего внимания.

Немного о причинах

Если говорить в целом, то данная категория ошибок, в основном, возникает по причине конфликта драйвера со средой ОС. Поэтому в тех случаях, когда BSOD проявил себя именно после обновления драйвера или подключения нового оборудования, решение будет вполне традиционным – вернуть конфигурацию системы к прежнему состоянию (отключить новое устройство и(или) вернуться к прежней версии драйвера). К сожалению, в реальности, порой все оказывается не столь очевидно. Ведь, как уже было сказано, факторов может быть масса и они не всегда кроются лишь в программной плоскости, иногда, имея под собой физические неполадки, например, ошибки RAM, вызванные повреждением чипов. И это лишь частный случай из множества возможных вариантов.

Действия

Когда нет четкой картины происходящего, остается, в принципе, единственный разумный выход – пойти по порядку, постепенно сужая круг поисков.

Проверяем целостность компонентов

Первым делом, чтобы исключить любые проявления ошибок, вызванных сбоем в самой Windows, стоит проверить целостность ее внутренних файлов. Для этого, на главном экране, зажимаем сочетание Win+X, отмечая в меню командная строка (администратор).



В запустившемся окне вводим строку sfc /scannow и дожидаемся результатов.



Если по каким-то причинам sfc не удается исправить найденные ошибки или вообще завершить анализ. Стоит обратиться к такому системному инструменту, как DISM, который придется очень кстати в подобной ситуации. Для детальной проверки всего хранилища компонентов, в том же окне cmd вводим строчку: DISM /Online /Cleanup-Image /ScanHealth



Если по итогам сканирования утилита нашла поврежденные файлы, применяем строку:

DISM /Online /Cleanup-Image /RestoreHealth, которая исправит все, что сможет и, при необходимости, заменит необратимо поврежденные объекты новыми, с серверов Microsoft.

Выполняем чистую загрузку

Если действия из предыдущего пункта не принесли результатов, двигаемся дальше. И теперь исключим конфликт сторонних программ с системными службами.

Чтобы это сделать жмем сочетание Win+R и набираем в поле msconfig,



в появившемся окне переходим во вкладку служб, ставим галочку в пункте не отображать службы Microsoft



и жмем, справа, отключить все.



Применяем изменения, перезагружаемся и оцениваем результаты.

Используем точки восстановления

Также не лишним будет попробовать «откатить» ОС к раннему состоянию, даже, если проблема не имеет выраженной связи с подключением нового оборудования или обновлением. Конечно, все это имеет смысл, только, если в вашем распоряжении уже имеются сохраненные точки. Для доступа к службе жмем Win+R, набирая rstrui.



В ее окне, следуя указаниям мастера, выбираем желаемую точку



и ждем, пока служба завершит свою работу.

Отключаем быстрый запуск

Эта функция ускорения запуска на системах без SSD, появившись впервые в Windows 8.1, на практике, принесла больше хлопот, чем пользы. Так, в ряде случаев, было замечено, что она препятствовала корректному выключению питания, а также была виновницей в ряде других неисправностей, в том числе и IRQL NOT LESS OR EQUAL. Для выключения опции идем в раздел электропитания (Win+R, powercfg.cpl),



далее слева открываем раздел кнопок питания,



здесь жмем изменить параметры, доступные сейчас



и в следующем окне снимаем отметку с соответствующей опции.

Тестируем оперативную память

Принимая во внимание связь проблемы с ошибками RAM, на данном этапе воспользуемся ее диагностикой. Можно использовать, как встроенное средство mdsched,



так и специальные средства вроде TestMem5 и MEMTEST86+ (подробно об этом мы уже писали в одном из наших недавних материалах). Здесь. Скажем лишь то, что в случае выявления ошибок, попробуйте исключить из конфигурации проблемный модуль(и) и оценить эффект. Если причина была в этом, то вероятнее всего, BSOD больше вас не побеспокоит.

Используем BlueScreenView для анализа дампов памяти

Ну и напоследок рассмотрим более сложный случай, когда на экране ошибки нет ссылок на проблемный драйвер или службу. Как известно, все критические происшествия, Windows записывает в виде внутренних логов, хранящихся в аварийных дампах памяти. Их анализ не самое благодарное дело, даже для знающих пользователей, к счастью, существует программа, позволяющая упростить их чтение – BlueScreenView.

Скачать ее можно на официальном сайте:

https://www.nirsoft.net/utils/blue_screen_view.html#DownloadLinks



После распаковки и запуска, она автоматически отобразит список всех существующих малых дампов, соответствующих критическим событиям.



Опираясь на дату, можно довольно легко найти интересующий сбой. Для получения подробных сведений, выделяем его, после чего, в нижней части окна, в графе Filename увидим проблемный драйвер, подсвеченный розоватым цветом.



Если проблемный драйвер отсутствует в списке, можно получить сведения из кода ошибки, причем сделать это можно за пару кликов: выделяем нужный минидамп и вызываем меню правой кнопкой, где отмечаем пункт найти код + драйвер.



Опираясь на полученную таким образом информацию, вам будет гораздо легче найти контекст проблемы и ее решение.

На сегодня это все. Надеемся, что приведенная здесь тактика действий станет вашей путеводной нитью на пути к разрешению сбоя.

До новых встреч.