STOP 0x000000F4

Метки:  , , , , , ,

Критическая ошибка STOP 000000F4, символическое имя: CRITICAL_OBJECT_TERMINATION. Данная критическая ошибка говорит нам о том, что произошла ситуация, в которой объект (процесс/поток), критичный для функционирования операционной системы, был неожиданно завершен или прерван.

Параметры ошибки:
Нижеследующие параметры можно наблюдать на диагностическом "синем экране смерти" (BSOD), либо в полях дампа памяти.

Параметр Описание
1 Тип завершившегося объекта:
0x3: Процесс
0x6: Поток
2 Завершившийся объект
3 Имя файла образа процесса
4 Указатель на ASCII строку, содержащую поясняющее сообщение

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

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

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

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

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

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

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

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

Процесс

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

!process <Arg2> 3

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

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

dc <Arg3>

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

Как мы видим, поле под названием ImageFileName, содержащего имя образа, в структуре EPROCESS имеет смещение 0x2e0. Не стоит принимать это значение во внимание и тем более пытаться запомнить, поскольку структура EPROCESS может, в зависимости от версии операционной системы, меняться. Например когда-то (если я не ошибаюсь) было вроде как значение 0x174 (?), если я не ошибаюсь.
Если нас интересует, то мы можем получить дамп памяти по адресу, где хранится ASCII-строка (аргумент 4 сведений об ошибке):

Поток

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

!thread <Arg2>

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

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

dc <Arg3>

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

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

Не важно, виновником останова у нас был процесс или же поток, в любом случае, после определения типа вызвавшего сбой объекта, дальнейшее изучение приводит нас сюда. Само определение типа объекта (процесс/поток) и имени объекта (имя процесса) дают нам лишь минимально-необходимый набор информации для дальнейшего осмысления проблемы. Конечно случаются и исключения, но в большинстве случаев в критической ошибке 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], обычно содержащими дополнительные коды ошибок, и только после этого выстраивается логическая цепочка дальнейших действий.

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 и прочих), которые могут фигурировать в качестве "упавшего" объекта, а где то еще, в каких-то сторонних модулях, работающих в ядре, скорее всего сторонних драйверах. Исчерпание ресурсов можно диагностировать различными способами, но в данной статье мы будем рассматривать способ с применением техник отладчика WinDbg.
Выполняем команду !vm 2:

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

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

lmvm <имя_драйвера>

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

ExceptionCode: c0000005

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

EXCEPTION_RECORD отсутствует

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

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

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

Затем, из того же вывода команды !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 я специально сэмулировал на тестовой машине, произведя как раз описанные выше действия :) Конечно, вероятность возникновения подобного сферического BSOD в вакууме в дикой природе довольно мала, однако пример показывает нам, что процесс анализа дампа - это как правило творческое занятие.

Анализ поля ExitStatus

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

dt nt!_EPROCESS <Arg2> ExitStatus

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

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

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

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

!error <NTSTATUS>

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

Замечания

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

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

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

  • Поделиться:

8 комментариев:

  1. Михалыч

    STOP 0x000000F4 - CRITICAL_OBJECT_TERMINATION
    Image: csrss.exe
    ExceptionCode: c0000006 (In-page I/O error)
    Parameter[2]: 00000000c000000e
    Inpage operation failed at 000007fefd3fe8c0, due to I/O error 00000000c000000e
    Подскажите, пожалуйста, на что указывает в данном случае 2-ой параметр ?

    • einaare

      судя по всему значение второго параметра = C000000E, что есть STATUS_NO_SUCH_DEVICE.
      через analyze -v в подробностях нет подробного описания EXCEPTION_CODE (NTSTATUS) с расшифровкой?
      Судя по всему ошибка ввода-вывода при подкачке страницы случилась потому, что что-то произошло с устройством, с которого критический для системы файл "подкачивался". Устройство = какой-то из дисков (HDD/SSD) в системе.. Проверяйте контроллер, диск, кабель.. ну это так, по NTSTATUS, поскольку Вы вряд ли сможете предоставить полный дамп?

  2. Михалыч

    EXCEPTION_CODE: (NTSTATUS) 0xc0000006 - The instruction at 0x%p referenced memory at 0x%p. The required data was not placed into memory because of an I/O error status of 0x%x.
    В системе 1 hdd seagate 1ТБ (новая прошивка для него не выходила).
    Полного дампа нет (в списке нет данного типа в системе windows 7 pro x64), есть дамп ядра и мини дамп.
    HDD проверял различными программами: SeaTools, MHDD, Victoria, тест поверхности в норме, смарт атрибуты тоже в порядке.
    Также проверил RAM и сделал антивирусную проверку, также всё в порядке.
    BIOS последней версии, но от 2012 года.

    Тоже подумал, что какая-то проблема с hdd из-за таких упоминаний:
    IO_ERROR: (NTSTATUS) 0xc000000e - A device which does not exist was specified.
    MODULE_NAME: hardware_disk
    IMAGE_NAME: hardware_disk
    FAILURE_BUCKET_ID: X64_0xF4_csrss.exe_BUGCHECK_CRITICAL_PROCESS_3bab980_IMAGE_hardware_disk

    В стеке не смог разобраться, не знаю что это за функции.
    STACK_TEXT:
    fffff880`02e9b108 fffff800`02e0e292 : 00000000`000000f4 00000000`00000003 fffffa80`03b01060 fffffa80`03b01340 : nt!KeBugCheckEx
    fffff880`02e9b110 fffff800`02dcc68b : 00000000`00000001 fffffa80`03bab980 fffffa80`03b01060 00000000`001b1200 : nt!PspCatchCriticalBreak+0x92
    fffff880`02e9b150 fffff800`02d35684 : 00000000`00000001 ffffffff`ffffffff fffffa80`03b01060 00000000`00000008 : nt! ?? ::NNGAKEGL::`string'+0x26ea6
    fffff880`02e9b1a0 fffff800`02a7a093 : ffffffff`ffffffff fffffa80`03bab980 fffffa80`03b01060 00000000`001b0cb0 : nt!NtTerminateProcess+0x284
    fffff880`02e9b210 fffff800`02a76650 : fffff800`02ab7475 fffff880`02e9bb78 fffff880`02e9b8e0 fffff880`02e9b3e0 : nt!KiSystemServiceCopyEnd+0x13
    fffff880`02e9b3a8 fffff800`02ab7475 : fffff880`02e9bb78 fffff880`02e9b8e0 fffff880`02e9b3e0 fffff880`02e9bb78 : nt!KiServiceLinkage
    fffff880`02e9b3b0 fffff800`02a7a48e : fffff880`02e9bb78 00000000`c0000006 fffff880`02e9bc20 00000000`001b1328 : nt!KiDispatchException+0x534
    fffff880`02e9ba40 fffff800`02a78ffa : 00000000`00000000 000007fe`fd3fe8c0 00000000`00000001 00000000`00011c50 : nt!KiExceptionDispatch+0xce
    fffff880`02e9bc20 00000000`77798042 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x23a
    00000000`001b1270 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x77798042

    BSOD происходит редко примерно 1,2 раза в неделю.

    Спасибо за помощь.

  3. Михалыч

    Спасибо, в статье нашел, что можно изменить на полный дамп памяти, изменив значение в реестре.
    Есть шлейф, но смарт атрибут UltraDMA CRC Error Count в норме.
    К подозреваемым можно ещё БП добавить, но всё это проверить заменой пока нет возможности.

    • einaare

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

  4. Михалыч

    Да, поменял в настройках с дампа ядра на полный дамп.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *