Stop 0x000000f4 – как исправить ошибку синего экрана смерти BSOD в Windows XP или 7 при загрузке или в процессе работы

Stop 0x000000f4 – как исправить ошибку синего экрана смерти BSOD в Windows XP или 7 при загрузке или в процессе работы Техника

Bsod 0x000000f4 (0x00000003, параметр2, параметр3, параметр4) | компьютерная помощь

На днях повстречался BSOD (синий экран смерти) с ошибкой 0x000000F4 (0x00000003, …)

Ошибка может появиться как во время загрузки ОС Windows, так и во время ее работы. Ошибка может и не появляться в течение недели и больше. При этом в течение этого периода производительность компьютера заметно падает — сама система грузится дольше, программы также загружаются дольше.

Причем номер ошибки BSOD может меняться — иногда возникает ошибка 0x00000003 или 0xC0000221 (Unknown Hard Error)

Лечится судя по форумам по разному.

В моем случае причина была связана с работой Жесткого диска

Действия которые я проделал для ее устранения были следующие:

  1. Проверил компьютер на вирусы с помощью сканера CureIt. Вирусов в системе не оказалось
  2. Проверил жесткий диск на наличие ошибок (ПКМ на всех установленных в системе дисках — Свойства — Сервис — Проверка диска — поставить обе галочки и перезагрузить компьютер). После проверки диска — ошибок не было обнаружено
  3. Открыл корпус системного блока, продул плату, прочистил контакты, снял сата-кабель от материнской платы, поставил другой, поменял порт в который вставлялся этот кабель. После этих действий компьютер стал включаться нормально, скорость работы стала преждней.

Оставил так. Пока что не звонили 🙂

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

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

В случае если вы не устанавливали новое оборудование, то следует проверить напряжение сети. Оно должно быть не менее 210В.

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

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

Проверьте жесткий диск на наличие битых секторов и ошибок. По возможности восстановите ошибки и битые сектора стандартными средствами (Свойства диска – сервис – выполнить проверку).

Попробуйте восстановить систему из точки восстановления системы.

Если не удается войти в Windows, то попробуйте загрузиться с последней удачной конфигурации.

В случае самостоятельной настройки BIOS, попробуйте сбросить настройки по умолчанию.

Проверьте систему на наличие вирусов. Поверить можно бесплатной утилитой от DrWeb – скачать

В крайнем случае переустановите Windows.

Если стоп ошибка 0X00000003 INVALID_AFFINITY_SET появляется при установке системы, то возможно не хватает оперативной памяти. Добавьте.

BSOD 0X00000003 INVALID_AFFINITY_SET может быть вызвана:

А также обратил внимание на сообщение которой многим помогло:

у кого мать Gigabyte 965P S1 S2 или S3 как в моём случае и вылетает BSOD c …..F4 (…….x03) (при простой работе, интернет, отключение LAN, музыка, и подобные действия не загруж камп), то не стоит так сильно мучаться просто перепрошейте LAN. Именно из-за этого бага у меня такое же было примерно 4 мес не мог сделать! Нужно скачать прошивку Marvell Yukon 88e8056 pci-e… создать дискету загрузочную и работать намана! из-за этой штуки некорректно работает винчестер, и не в шлейфах дело и даже не в блоке питания

Вы можете оставить комментарий.

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 показало бы выгружаемые пулы.

Дополнительно:  LCD шрифты

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

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

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

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

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

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

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

lmvm

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

Windows 7

Для «Семёрки» справедливы абсолютно все перечисленные выше средства. Её механизмы диагностики более продвинутые, чем у ХР. Аналогичное справедливо и для следующих версий ОС.

Windows xp

Справедливы все инструменты. Но диагностику памяти лучше проводить используя стороннюю программу Memtest, встроенное в систему средство диагностики не совершенно и может упустить ошибку из виду или выдать ложное срабатывание. А для диагностики жёсткого диска лучше применить Victoria.

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

Анализ поля exitstatus

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

dt nt!_EPROCESS <Arg2> ExitStatus

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

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

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

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

!error <NTSTATUS>

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

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

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

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

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

Дополнительно:  Root проводник android что это

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

Звуки в жестком диске

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

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

Исправление проблем на разных ос

В зависимости от версии ОС ошибка появляется в разных ситуациях. Поэтому и инструменты для её решения будут отличаться.

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

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

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

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

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

Обновление windows

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

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

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

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

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

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

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

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

Дополнительно:  Ошибка 0x000000F4 на синем экране BSOD в Windows

Вот это всё великое множество полей нам, конечно же, не потребуется. При анализе любого дампа памяти интерес для нас представляет, в первую очередь, описание и аргументы критической ошибки, которые следуют, как правило, непосредственно за «шапкой» 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-строку с поясняющим сообщением, которое раскрывает характер ошибки. Для того, чтобы его посмотреть это сообщение, мы выводим дамп памяти по указанному в аргументе адресу:

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

Первое, на что нужно обратить своё внимание, если обнаружили синий экран 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. Переходим на вкладку «Загрузка» и отмечаем галочку «Сделать эти параметры загрузки постоянными».Конфигурация системы

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

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

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

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

Профилактика ошибки

Чтобы избежать появления ошибки следует проводить диагностические мероприятия каждые 6 месяцев. Речь идёт о проверке состояния жёсткого диска и оперативной памяти. Перепроверять работу антивируса контрольной утилитой и вообще следить за состоянием компьютера.

Процесс

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

!process <Arg2> 3

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

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

dc <Arg3>

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

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

Решение проблемы

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

Создатели critical_object_termination трудности

Проблемы с прошивкой, драйвером, оборудованием или программным обеспечением могут привести к ошибкам синего экрана, связанного с CRITICAL_OBJECT_TERMINATION. Они могут быть связаны либо с программным обеспечением Windows или аппаратным обеспечением Microsoft Corporation, но это не обязательно так.

В частности, ошибки, связанные с CRITICAL_OBJECT_TERMINATION, создаются:

Продукт Solvusoft

ЗагрузкаWinThruster 2021 — Проверьте свой компьютер на наличие ошибок.

Совместима с Windows 2000, XP, Vista, 7, 8, 10 и 11

Установить необязательные продукты — WinThruster (Solvusoft) | Лицензия | Политика защиты личных сведений | Условия | Удаление

Чистка вирусов

Прерывание работы компонента может быть спровоцировано вирусом. Поэтому следует запустить сканирование и проверку вирусов на компьютере. Если присутствуют сомнения относительно своего антивируса можно воспользоваться портативным антивирусом, например, DrWeb CureIt.

Это бесплатная программа, которая неплохо перепроверяет работу антивирусов. В сервисных центрах часто советуют делать профилактические чистки раз в 6 месяцев именно этой программой. Менять антивирус при этом не обязательно. На время проверки свой антивирус следует отключить, чтобы он не мешал утилите.

Оцените статью
Master Hi-technology
Добавить комментарий