Ошибка 0x000000f4 Windows 7 (BSoD): причины появления и методы исправления

0x000000f4 windows 7 – как исправить | инструкция

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

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

Анализ поля exitstatus

Ну если уж при анализе дампа другими методами вообще никакой полезной информации получить не удалось, то можно попытаться получить хоть какую-то информацию по коду завершения из структуры EPROCESS, воспользовавшись следующей командой:

dt nt!_EPROCESS <Arg2> ExitStatus

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

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

ExitStatus представлен в десятичном формате, поэтому для вычисления выражения (перевод в 16-ричную систему), можно использовать следующую команду:

А затем уже, имея шестнадцатеричное представление, можно найти общую информацию по коду ошибки посредством команды:

!error <NTSTATUS>

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

Анализ стека вызовов

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

Затем, из того же вывода команды !analyze -v получаем стек момента падения:

Обратите внимание на выделенные строки 5 и 7. Поскольку разбор стека идет снизу вверх, то вызов функции в строке 7 произошел ранее, и здесь мы видим функцию nt!DbgkpCloseObject, а что у неё в одном из аргументов?

Значение 86933020, которое является идентификатором прерванного процесса smss.exe (обратите внимание на параметр 2 (Arg2) сбоя). Далее, по цепочке вызовов движемся вверх и доходим до строки 5, видим там вызов функции nt!

PspTerminateAllThreads, среди агрументов которой опять обнаруживаем знакомый идентификатор процесса 86933020, а заодно и параметр c0000354. Этот параметр есть ни что иное, как код NTSTATUS, то есть статус завершения операции.

Вероятно, функция nt!PspTerminateAllThreads принудительно завершает все потоки процесса с идентификатором 86933020 и со статусом c0000354, который по описанию интерпретируется как STATUS_DEBUGGER_INACTIVE, а расшифровывается как Попытка произвести действие с отладочным портом не удалась, порт находится в процессе удаления.

Кто-то просто-напросто закрыл отладчик, который был подключен в разрушающем (агрессивном, invasive) режиме к системному процессу smss.exe. История кажется фантастической? Отнюдь, поскольку именно этот STOP я специально сэмулировал на тестовой машине, произведя как раз описанные выше действия 🙂

Замечания

Однако в некоторых случаях, из дампа мы не можем получить ни кода исключения, ни кода ошибки, а видим примерно такой вот результат:

то есть автоматика Windbg данных кодов из дампа получить не смогла, быть может это связано с тем, что во время сбоя логика формирования дампа, по какой-то причине, не смогла заполнить структуру, либо заполнила её на основании каких-либо некорректных данных, попавших туда ошибочно. Выполнение команды по запросу статуса выхода

выдает вообще какой-то фантастический код 0n-1 (0xFFFFFFFF)!! Могу ошибаться, но может быть это вызвано тем, что при конкретный дамп представляет собой минидамп и не содержит в себе необходимых структур?

Как исправить ошибку 0x000000f4 в windows 7

1. Если у нас неисправен жесткий диск, можно его проверить с помощью программ таких как:

Есть еще множество программ, но я вам показал самые доступные и простые программы для проверки жестких дисков.

При проверки всегда будьте внимательны и смотрите описание и тома жестких дисков.

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

3. Компьютер заражен вирусами, можно будет проверить специальными программами для удаления вирусов, можете прочитать на нашем блоге статью Удаление вредоносных программ.

4. Установлены несовместимы драйвера или они не имели цифровую подпись, нужно их удалить, и установить более подходящие или более свежие версии драйверов.

На windows 7

Чаще всего неприятность 0x000000f4 Windows 7 показывает непосредственно сразу при включении ПК или после входа в систему из спящего режима. Если это происходит, то, вероятней всего, проблема кроется в неисправности какой-либо планки оперативной памяти.

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

Причина может скрываться в проблемах с определенным системным файлом, мешающем «семерке» беспрепятственно работать. В любом случае для устранения ошибки следует рассмотреть все вышеописанные причины.

Низкий уровень

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

К тому же, в случае общего похода к решению, нет погружения в детали инцидента, из-за этого даже в случае устранения причин сбоя, модуль, виновный в возникновении ошибки, остается не выявленным. Сбой STOP 000000F4, как и многие другие критические сбои, относится к той категории, которая не является легкой в изучении, поскольку отсутствует прямая связь с причиной «падения». Практика показывает, что зачастую даже при наличии полного дампа довольно сложно докопаться до настоящей причины.

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

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

Обновление системы

И еще одна ситуация. Как ни парадоксально это звучит, но ошибка с кодом 0x000000f4 Windows 7 может выскакивать даже в случае отсутствия необходимых пакетов обновления самой системы. А вот тут этот сбой, пока пакеты не будут инсталлированы, продолжит появляться снова и снова.

Как поступить в этом случае? Нет ничего проще, чем зайти в раздел Центра обновлений и убедиться, что установка выставлена на автоматический режим. Если по какой-то причине обновление не происходит, можно самостоятельно задать ручной поиск, и, после того как пакеты апдейтов будут найдены, интегрировать их в систему посредством скачивания и установки.

Обновления ос

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

Нерегулярное обновление

Например, после установки «винды» прошло много времени, были установлены драйвера и программы, а затем был произведен апдейт. Новые системные файлы могут конфликтовать с уже установленными, что приводит к сбоям. Решить проблему можно двумя способами:

Очередное или автоматическое обновление

Ошибки могут возникать и непосредственно во время инсталляции пакетов. Причины могут быть разные – от ограничений, наложенных сторонним антивирусным софтом до того же конфликта. Отсутствие предыдущих версий апдейтов также может повлиять на корректное завершение процесса. Варианта исправления такой ситуации два: восстановить систему, как в предыдущем варианте, или установить «обновы» вручную.

Общая проверка пк

Если проблем со звуком нет, то, возможно, Вам поможет замена термопасты. О процессе её замены мы писали в теме «Замена термопасты на процессоре». Переходите по ссылке и ознакамливайтесь с тем, как это делать.

Второе, что может повлиять на появление синего экрана 0x000000f4 – это накопившаяся пыль на аппаратных составляющих: протрите внутренности системного блока от пыли.

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

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

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

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

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

Очистка системного диска

Рассмотрим еще одну ситуацию, когда появляется сбой такого типа (код ошибки 0x000000f4 Windows 7). Решение проблемы может быть связано с банальной очисткой системного диска (на котором установлена «Винда») от мусора. Сразу же обратите внимание на то, что для нормальной работы системы, как правило, требуется не менее 10% свободного места от общего объема тома (например, если диск «С» имеет объем 100 Гб, для корректного функционирования системы свободно должно быть не менее 10 Гб).

Тут можно поступить двояко: либо использовать встроенные средства системы, вызываемые через меню свойств при правом клике на литере раздела в «Проводнике», либо обратиться за помощью к сторонним утилитам вроде CCleaner.

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

Поток

Помимо процесса, упавшим объектом может быть и поток в контексте процесса. Опять же, выяснить это можно по значению первого аргумента (Arg1) критической ошибки, если в нем содержится указание на поток (значение 6, именование Thread), то мы имеем дело с потоком внутри некоего процесса. Поскольку упавший объект является потоком, то мы выполняем соответствующую команду:

!thread <Arg2>

Получаем структуру целевого процесса:

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

dc <Arg3>

И аргумент 4 критической ошибки указывает на ASCII-строку с поясняющим сообщением, которое раскрывает характер ошибки. Для того, чтобы его посмотреть это сообщение, мы выводим дамп памяти по указанному в аргументе адресу:

Причина ошибки

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

Такое поведение жесткого диска является признаком того, что в компьютере есть проблемы с питанием, что нужно исправить в первую очередь.

Если подобных звуков от винчестера Вы не слышите, но Вы видите ошибку STOP 0x000000f4 в Windows 7 при загрузке, то также нужно проверить другие детали: общую загрязненность, наличие термопасты на процессоре и правильно ли установлена планка с оперативной памятью.

Причины появления ошибки 0x000000f4

На официальном сайте Microsoft в качестве причины возникновения ошибки «stop 0x000000f4» указывается: «вызов приложения, создающего перекрёстный вызов с компонентами системы и аварийное завершение его работы». Из текста описания следует, что пользователем запускается и сразу закрывается программа, которая обладает функционалом, совпадающим с системным.

Звучит сложно, но проблема знакома геймерам. Некоторые игры запускаются вместе с некоторыми приложениями, обеспечивающими взаимодействие с сервером или защиту ввода пароля. Аналогичные действия выполняются и самой Windows. Обычно после установки соединения программа прекращает работу, а при должной производительности компьютера это происходит мгновенно. В следствии чего и возникает BSOD с указанным кодом.

Не только игры, но и серьёзные программы обладают такой спецификой. А чаще всего ошибка встречается на Windows 7 и XP. При этом следует отметить также исключительную редкость этого синего экрана. Ведь вызвать завершение работы системного компонента способны единичные программ.

Проверка и чистка hdd

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

Чтобы проверить состояние диска можно воспользоваться сторонними программами MHDD или Victoria или воспользоваться средствами самой системы. Рассматривается второй случай, потому как об использовании специфического программного обеспечения можно прочесть у нас на сайте:

1. Открываете «Проводник» и нажимаете правой кнопкой мыши на локальном диске. Процедуру потребуется повторить несколько раз (по разу для каждого локального диска). Выбираете пункт «Свойства».
2. Переходите в «Свойствах» на вкладку «Сервис» и выбираете «Проверить».
3. Читаете предупреждение и выбираете необходимые галочки: «Исправлять ошибки» и «Сканировать том». После чего запускаете процедуру.

Важно! Этот способ актуален для Windows 7 и выше. Для Windows XP подобный инструмент не предусмотрен, поэтому потребуется прибегнуть к использованию упомянутых выше программ.

Проверка озу

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

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

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

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

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

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

Процесс

Если в Аргументе 1 ошибки содержится указание на процесс (значение 3, именование Process), то мы имеем дело с падением процесса. Поскольку упавший объект является процессом, то выполняем следующую команду:

!process <Arg2> 3

Получаем структуру целевого процесса:

информация содержит детализацию по выбранному процессу. Среди прочих параметров мы можем наблюдать в строке 6 и имя образа в виде поля с именем Image, содержащим значение csrss.exe.Имя исполняемого образа процесса так же содержится в аргументе 3, поэтому мы можем получить его и другим способом, например выведя дамп памяти с адреса, хранящегося в аргументе 3:

dc <Arg3>

В дополнение к этому, то же имя исполняемого образа можно получить из структуры EPROCESS:

Как мы видим, поле под названием ImageFileName, содержащего имя образа, в структуре EPROCESS имеет смещение 0x2e0. Не стоит принимать это значение во внимание и тем более пытаться запомнить, поскольку структура EPROCESS может, в зависимости от версии операционной системы, меняться.

Сбой 0x000000f4 windows 7: как исправить при помощи антивируса

Действительно, вирусы могут воздействовать на систему избирательно, блокируя некоторые важные службы или вмешиваясь в их работу. Таким образом, самое первое, что нужно сделать, — произвести проверку системы на наличие угроз.

При этом даже при установленном штатном антивирусе, его использовать не рекомендуется, ведь они и так уже пропустил угрозу. Тут лучше применять портативные антивирусные утилиты вроде Dr. Web CureIt! или KVRT «Лаборатории Касперского». Впрочем, такой подход может ничего не дать, если вирус засел глубоко в оперативной памяти или в загрузочном секторе.

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