Как исправить синий экран смерти 0x000000F4 CRITICAL OBJECT TERMINATION

Exception_record отсутствует

Встречаются ситуации, когда структуры EXCEPTION_RECORD просто нет! Если автоматизированный анализ Windbg не смог получить структуру EXCEPTION_RECORD из дампа, и нет никакого упоминания о возникшем в процессе/потоке исключении, то у нас есть несколько вариантов.

Exceptioncode: c0000005

Если поле ExceptionCode содержит значение c0000005 (Access Violation), то мы, скорее всего, имеем дело с нарушением доступа, возможно возникшим по причине отсутствия необходимой страницы в физической (оперативной) памяти. Вероятно, проблема кроется в контроллере/жестком диске.

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

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

How to fix the critical_object_termination error

Анализ поля 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)!! Могу ошибаться, но может быть это вызвано тем, что при конкретный дамп представляет собой минидамп и не содержит в себе необходимых структур?

Как сбросить windows 10 к исходному состоянию

Как сбросить windows 10, 8, 7 если компьютер не загружается

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

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

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

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

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

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

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

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

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

Поиск ключевых структур

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

Конечно случаются и исключения, но в большинстве случаев в критической ошибке STOP 000000F4 участвует один из системных процессов, что усложняет дальнейший анализ. К примеру, виновником может запросто оказаться такой системный процесс, как csrss.exe или smss.exe, и что прикажете с этим фактом делать?

Обновлять/заменять системные процессы не имеет смысла, поскольку если исключить явную подмену модуля (вследствие вирусной активности), что случается довольно редко, то обычно в системе присутствует самая актуальная версия. В этом случае вопрос ЧТО именно упало заменяется на вопрос ПОЧЕМУ данный процесс/поток упал?

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

Все это подталкивает нас к мысли о необходимости дальнейшего исследования инцидента. В самом начале исследования ошибки STOP 000000F4, мы выполняли в отладчике Windbg команду !analyze -v, а в выводе этой команды, в большинстве случаев, могут присутствовать дополнительные параметры, такие как код исключения в контексте процесса/потока. Попытайтесь найти в выводе структуру с именем EXCEPTION_RECORD, она может быть в такой форме:

а может быть и в такой:

..именно эта структура, в контексте данного сбоя, представляет особый интерес, поскольку имеет ряд значимых для дальнейшего изучения инцидента полей. Если структура присутствует в выводе, то обращаем внимания на поля ExceptionCode / EXCEPTION_CODE и Parameter[x] / ERROR_CODE, поскольку дальнейшее ориентирование будет происходить именно по их комбинациям.

Поле ExceptionCode указывает на код исключения (возможно с кратким описанием), а один из параметров Parameter[x] может содержать уточняющую информацию о характере возникшего исключения. Итак, значение поля ExceptionCode анализируется в совокупности с полями Parameter[x], обычно содержащими дополнительные коды ошибок, и только после этого выстраивается логическая цепочка дальнейших действий.

Поток

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

!thread <Arg2>

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

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

dc <Arg3>

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

Процесс

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

!process <Arg2> 3

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

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

dc <Arg3>

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

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

Похожее:

Как посмотреть установленные сертификаты windows 10 Как работает REST API: что это простыми словами и примеры использования Настройка переключения клавиатуры centos Внутреннее устройство памяти Microsoft Hyper-V