Ошибка Stop 0x0000007b при загрузке или установке Windows – как устранить?

Описание кода ошибки

Она описывает фатальную критическую ситуацию, возникающую при генерировании процессором исключения, необрабатываемого ядром операционной системы. Такой исключительной ситуацией может послужить связанное прерывание или, так называемая, двойная ошибка.
Bound trap (связанное прерывание) представляет вид прерывания, которое ядру Windows нельзя перехватывать для обработки. Такая исключительная ситуация не приводит к вызову системного обработчика исключений. Поэтому происходит крах системы, завершающийся синим экраном и STOP-ошибкой UNEXPECTED_KERNEL_MODE_TRAP. Тот же стоп-код генерирует система при возникновении двойной ошибки, когда попытка обработки возникшего исключения приводит к другой ошибке (double fault).

• Примером может послужить исключительная ситуация деления на ноль, описываемая последовательностью 0x00000000. Причиной такого исключения может стать, например, битая память.
• Выполнение процессором недопустимой операции (0x00000006) также может быть значением первого параметра.
• Двойное исключение (double fault) описывает код 0x00000008. Это попытка обработать возникшее исключение, которая также завершилась неудачей. Причиной двойного необрабатываемого исключения могут стать переполнение стека ядра Windows или проблемы с «железом».

Первый параметр может принимать и другие значения. Расшифровывать эти значения можно с помощью документации к архитектуре процессоров Intel.

Данный стоп-код характерен
для любой версии Windows
. Например, он замечен при установке Windows XP, возникает такая ситуация и при эксплуатации Windows 10. Описана данная ситуация и при работе с
Symantec Antivirus

0x0000007a

Exceptioncode: c0000006

Если поле ExceptionCode содержит значение c0000006 (In-page I/O error), а второй параметр Parameter[2]: c000009a (Insufficient system resources exist to complete the API), то полное описание ошибки выглядит следующим образом:

«Inpage operation failed at , due to I/O error c000009a», что переводится как «Ошибка страничной операции (ошибка подкачки страницы) в следствии ошибки ввода-вывода с кодом c000009a». Так же, статус завершения может содержаться в поле с именем ERROR_CODE, а полная комбинированный код ошибки в поле EXCEPTION_STR.

Статус c000009a, в свою очередь, указывает на недостаток системных ресурсов для завершения вызова API, а недостаток ресурсов, чаще всего, является следствием исчерпания памяти. Из всего этого следует, что мы имеем дело с утечкой памяти в одном из сторонних модулей режима ядра, которая привела к исчерпанию системных ресурсов (в данном случае памяти), а это, в свою очередь, вызвало ошибку ввода-вывода при подкачке страницы, поскольку некуда была эту страницу подгрузить.

Утечка памяти (memory leak) — процесс неконтролируемого уменьшения объёма свободной (оперативной/виртуальной) памяти системы, связанный с ошибками в коде выполняющихся в данный момент программ, вовремя не освобождающих ненужные уже участки памяти, или с ошибками системных служб контроля памяти.

Память это конечный системный ресурс, и хорошая практика состоит в том, что как только часть памяти (минимальная единица выделения) становится не нужной какому-либо исполняемому коду, она должна быть возвращена в общий пул посредством освобождения (маркировки как свободная).

К сожалению, так случается не всегда. А иногда бывает, что ошибка в коде приводит к тому, что память вовремя не освобождается, а только постоянно резервируется. Естественно, что утечка происходит не в самих системных процессах (csrss.exe, smss.exe и прочих), которые могут фигурировать в качестве «упавшего» объекта, а где то еще, в каких-то сторонних модулях, работающих в ядре, скорее всего сторонних драйверах.

обратите внимание, что в выводе отладчика я выделил поля с именами NonPagedPool Usage, NonPagedPool Max. Они относятся к такому важному системному ресурсу, как невыгружаемый и выгружаемый пулы.

Выгружаемый и невыгружаемый пулы — ресурсы памяти, которые ядро операционной системы (включая драйверы устройств) использует для хранения собственных структур данных.

Сразу отмечу, что выгружаемые пулы обычно не являются причиной аварийных ситуаций из-за утечек памяти, поскольку они могут быть выгружены на диск, в файл подкачки. Стоит обращать своё внимание именно на невыгружаемые пулы. В случае, когда значения невыгружаемых пулов NonPagedPool Usage ~= NonPagedPool Max, можно сделать вывод об наличии факта исчерпания пулов.

В дополнение, в выводе могут встретиться такие строки как Excessive NonPaged Pool Usage и ???? pool allocations have failed, которые так же являются характерными признаками исчерпания пулов. Теперь мы можем вывести список всех процессов, использующих невыгружаемые пулы:

!poolused 7

Расширение !poolused даёт сводку по использованию памяти, на основании тэгов, применяемых для каждого пула, то есть показывает использование памяти для каждого тэга. Сам тэг характеризует конкретный модуль в ядре. Таким образом, !poolused собирает данные из механизма маркируемых пулов (pool tagging, группируемые по тэгу пулы), которая постоянно включена в ядре только в версиях Windows 2003 и старше. В расширении используются флаги, которые регламентируют количество выводимых данных и метод сортировки:

• Bit 0 (0x1) — Включает детализированный вывод;
• Bit 1 (0x2) — Сортирует вывод по количеству невыгружаемой памяти;
• Bit 2 (0x4) — Сортирует вывод по количеству выгружаемой памяти;
• Bit 3 (0x8) — Отображает вместо стандартных пулов пулы сессии;

Флаг 2 команды используется для вывода объема использования невыгружаемых пулов, 4 показало бы выгружаемые пулы.

список обычно выдается просто огромный и приводить его тут целиком не имеет особого смысла, поэтому я показал лишь небольшую его часть, верхнюю. Конкретно в этом дампе у меня нет необходимой информации, однако обычно из подробного вывода видно, что у какой-то метки пула может присутствовать очень большое значение (обычно сотни тысяч) в столбце Diff у группировки NonPaged, которое говорит о том, что память, маркированная данным тэгом постоянно резервируется, но при этом мало освобождается.

Если в столбце Tag присутствует значение Irp, то имеются в виду IRP-пакеты (I/O request packet, пакеты запроса ввода-вывода), которые используются для обмена данными с драйверами. Поэтому, мы можем обратить своё внимание на пакеты драйверов (IRP), поскольку они могут дать нам подсказку по функциям, интенсивно использующим память. Для этого используем команду !irpfind отладчика:

Время выполнения команды !irpfind может быть ЧУДОВИЩНО БОЛЬШИМ! У меня последний раз при дампе размером в 4 гигабайта, операция выполнялась в течении нескольких часов.

Список, традиционно, не маленький, и я привел лишь небольшую его часть. По команде !pool (адрес из первой колонки) можно получить данные о принадлежности к выгружаемому или невыгружаемому пулу памяти:

По команде !irp (адрес из первой колонки) можно получить информацию о принадлежности пакета к определенному устройству:

Как мы можем видеть, в последних строках есть ссылка на драйвер устройства, которому предназначался IRP пакет: DriverAFD. У нас имя драйвера устройства было сразу видно в выводе команды !irpfind, приведенном выше, однако если Вам по каким-либо причинам необходимо узнать имя драйвера, то можно выполнить команду !devstack <Device> (адрес из колонки Device), которая получает информацию об устройстве, получившем IRP пакет:

При обнаружении стороннего драйвера, информацию по нему можно посмотреть командной

lmvm

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

Определение типа объекта

Весьма желательно, что бы у Вас к этому моменту на руках уже имелся полный дамп памяти.

Запускаем отладчик WinDbg из комплекта Debugging Tools for Windows, затем открываем через меню File — Open Crash Dump… имеющийся у нас на руках (желательно полный) дамп памяти.В интерфейсе отладчика, в командной строке выполняем команду !analyze -v:

Вот это всё великое множество полей нам, конечно же, не потребуется. При анализе любого дампа памяти интерес для нас представляет, в первую очередь, описание и аргументы критической ошибки, которые следуют, как правило, непосредственно за «шапкой» Bugcheck Analysis:

Проверка озу

Вторым источником ошибки синего экрана 0x000000f4 может служить некорректное взаимодействие компонентов системы и оперативной памяти. При наличии отклонений в последней её работа будет выполняться не корректно и системный процесс, вместо нужных данных получит неверное значение. Это и приведёт к его падению. В процессе проверки состояния ОЗУ компьютер потребуется перезапустить:

1. Открываем строку «Выполнить» («Ctrl R») и прописываем «msconfig».
2. Переходим на вкладку «Загрузка» и отмечаем галочку «Сделать эти параметры загрузки постоянными».

Это требуется для того, чтобы активировать «Тайм-аут» при запуске системы, чтобы после перезагрузки запустить диагностику памяти.

3. Перезагружаем компьютер и выбираем «Диагностика памяти» в окне выбора системы.

После этого выбираете настройки и запускаете процесс. Дело это не быстрое и отнимет определённое время. Пользоваться компьютером в это время не выйдет.

Способ справедлив для любой версии Windows. Альтернативным способом запуска диагностики является перезагрузка компьютера и нажатия F8 для отображения окна выбора загрузки. Такой способ больше подходит для Windows XP, поскольку там вместо «msconfig» используется текстовый файл «boot.ini».

Способ 6: восстановление системных файлов

Одной из причин, ведущей к ошибке 0x0000000a, является нарушение структуры файлов системы. Тогда необходимо произвести процедуру проверки и при необходимости восстановить проблемные элементы. Для выполнения указанной задачи запускаем ПК в «Безопасном режиме».

1. Щелкайте «Пуск». Нажмите «Все программы».



2. Войдите в директорию «Стандартные».



3. Отыскав название «Командная строка», нажмите по нему ПКМ. В отобразившемся перечне выберите «Запуск от имени администратора».



4. Активируется оболочка «Командной строки». Внесите туда такую запись:

   sfc /scannow

   Жмите Enter.



5. Запустится утилита, которая выполнит сканирование системных файлов на предмет потери их целостности. В случае обнаружения неполадок проблемные объекты будут восстановлены.

Способ 7: восстановление системы

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

1. С помощью меню «Пуск» перейдите в директорию программ «Стандартные». Алгоритм данного перехода был описан нами в предыдущем способе. Зайдите в каталог «Служебные».



2. Нажмите «Восстановление системы».



3. Запускается оболочка утилиты восстановления системных объектов и параметров. Нажмите «Далее».



4. Затем открывается окошко, где нужно выбрать конкретную точку, к которой будет восстановлена система. Если у вас заготовлено несколько вариантов, то выбирайте самый последний по дате, но сформированный перед тем, как возникла описываемая проблема. Для того чтобы иметь больший диапазон выбора, установите флажок возле «Показать другие…». После выделения наименования жмите «Далее».



5. Теперь откроется окно, в котором нам остается только проверить все введенные данные. Также не забудьте закрыть все активные приложения и сохранить документы в них, тем самым предотвращая потерю информации. Затем применяйте «Готово».



6. ПК будет перезагружен, а все системные файлы и настройки в нем будет сброшены к выбранной точке восстановления. Если она была создана до возникновения ошибки 0x0000000a и причиной сбоя была не аппаратная составляющая, то в этом случае с большим уровнем вероятности вы избавитесь от указанной проблемы.