В отчёте синего экрана, в WhoCrashed или в первых строках минидампа часто видят BugCheck 0x0000003b и следом Arg1: 0x00000000c0000005. Это не «двойной код ошибки» и не секретная комбинация Microsoft. 0x0000003b - SYSTEM_SERVICE_EXCEPTION. Первый аргумент - код исключения; 0xc0000005, записанный с ведущими нулями, есть STATUS_ACCESS_VIOLATION. Отдельного bug check 0x00000000c0000005 в списке стоп-кодов нет.

Почему это происходит

Как устроен дамп. У SYSTEM_SERVICE_EXCEPTION четыре параметра. Первый - exception code. Второй и третий указывают, где исключение поймали. Четвёртый - контекст. Люди копируют в поиск первые два шестнадцатеричных столбика и получают запрос «0x0000003b 0x00000000c0000005». Поиск честный, толкование часто нет: второй столбик не стоп-код.

Кто обычно в Arg2/модуле. Драйвер видео, сети, диска, антивируса. Имя .sys важнее, чем сам 0xc0000005. Параметр только подтверждает: обратились не туда в памяти. Без имени модуля вы лечите «нарушение доступа вообще».

Память путает картину. Битая планка подсовывает разные модули при одном и том же Arg1 0xc0000005. Тогда карусель имён - довод в пользу mdsched, не в пользу третьего пакета NVIDIA.

Путаница с приложением. Код 0xc0000005 в окне запуска программы - то же STATUS_ACCESS_VIOLATION, другой мир: процесс пользовательский, синего экрана нет. Код 0x0000003b без синего экрана в журнале приложений почти не живёт.

Не открывайте дамп утилитой «починить 0x3b одним кликом» и не применяйте её .reg. Не выдёргивайте из стека имя ntoskrnl.exe и не меняйте это ядро файлом с форума: ядро почти всегда есть в стеке, это не виновник. Не отключайте проверку подписей, чтобы подложить «исправленный» драйвер из темы 2014 года.

Искажение запроса именно в склеивании: 0x00000000c0000005 принимают за самостоятельный стоп. Число реальное, роль другая. Пишите оба значения латиницей. Кириллическая «с» в «0хс0000005» ломает поиск по журналу.

Как читать и что делать пошагово

  1. Разберите строку дампа. BugCheck 0x3B - имя стопа. Arg1 0xc0000005 - тип исключения. Дальше ищите MODULE_NAME или «Probably caused by». Это рабочее имя, не первые два числа.
  2. Сохраните минидамп как есть. C:\Windows\Minidump. Не редактируйте файл блокнотом. Для дома достаточно WhoCrashed или BlueScreenView, чтобы увидеть модуль. WinDbg нужен, если имени нет и стопы разные.
  3. Откатите названный драйвер. Диспетчер устройств, сайт вендора, не драйвер-пак. Если модуль антивируса - снимите продукт на неделю.
  4. Проверьте память, если модуль каждый раз новый. mdsched.exe, планки по одной, сток XMP. Один и тот же Arg1 при разных .sys - почти учебник по плохой RAM.
  5. Проверьте диск. CrystalDiskInfo. Битые сектора тоже роняют драйвер хранилища в 0x0000003b с параметром 0xc0000005.
  6. Снимите разгон и оверлеи. MSI Afterburner, XMP на пределе. Параметр 0xc0000005 от этого не «лечится ключом», он перестаёт возникать, когда железо снова стабильно.
  7. Не импортируйте готовые ключи TDR и DPC. Они меняют таймауты, не драйвер. Дамп будет тем же 0x0000003b с тем же Arg1, только реже.

Если в дампе пусто, а на экране только два числа - фото экрана всё равно полезно: подтверждает, что это SYSTEM_SERVICE_EXCEPTION, а не 0x0000001A и не 0x00000050. Лечение «по двум числам без модуля» всегда начинается с отката последних драйверов и теста памяти.

На ноутбуке после сна тот же Arg1 часто приходит вместе с видео- или сетевым .sys. Быстрый запуск снимите на проверку.

WhoCrashed иногда пишет «probably caused by ntoskrnl.exe». Это почти никогда не значит «замените ядро». Ядро просто поймало исключение, которое пришло из драйвера ниже по стеку. Смотрите следующий модуль в том же отчёте. Если утилита не даёт второго имени - откройте дамп в BlueScreenView или сохраните файл и несите так. Замена ntoskrnl с форума после такого отчёта как раз и делает систему не загружаемой.

Часто задаваемые вопросы

Что такое 0x00000000c0000005 в дампе? Это 0xc0000005, первый параметр 0x0000003b. Не второй стоп-код.

Можно ли искать лечение по двум числам без имени файла? Можно начать с памяти и отката драйверов. Точнее - с модуля из дампа.

0x0000003b выдуман? Нет. Это SYSTEM_SERVICE_EXCEPTION.

Нужен ли WinDbg дома? Нет, если BlueScreenView уже показал .sys. Да, если стопы разные и имени нет.

Поможет ли замена ntoskrnl.exe? Нет. И сломает загрузку. Ядро в стеке почти всегда.

Смотрите также