Синий экран с надписью SYSTEM_SERVICE_EXCEPTION и набором цифр 0x0000003B выглядит как единая строка тарабарщины, и большинство людей вбивают в поиск именно её целиком, вместе со случайными адресами в памяти. Результат обычно один и тот же: десятки сайтов с почти одинаковым текстом про переустановку Windows и универсальные утилиты для очистки реестра. Проблема не в поиске, а в том, что сама строка на экране это не одно значение, а несколько разных по природе данных, склеенных в одну надпись, и каждое из них ищется по-своему.
Синий или чёрный экран показывает четыре независимых слоя информации, а не единый код ошибки
С 2025 года в Windows 11 вместо привычного синего фона появляется чёрный экран с тем же набором данных, но без грустного смайлика и QR-кода: это часть Windows Resiliency Initiative, программы Microsoft по ускорению диагностики после массового сбоя, вызванного обновлением стороннего антивирусного драйвера в июле 2024 года. Изменился цвет и оформление, но структура самого сообщения осталась прежней и состоит из нескольких слоёв. Первый слой это символьное имя ошибки вроде SYSTEM_SERVICE_EXCEPTION или CRITICAL_PROCESS_DIED, второй это шестнадцатеричный код вроде 0x0000003B, третий это до четырёх дополнительных параметров в скобках, и четвёртый, который показывается не всегда, это имя конкретного драйвера или файла, ставшего непосредственной причиной сбоя.
Символьное имя и шестнадцатеричный код это по сути одно и то же значение в двух формах: разработчики Windows называют такие ошибки bug check, и у каждой из них есть постоянный числовой код и человекочитаемое имя, которые всегда соответствуют друг другу один к одному. Параметры в скобках, наоборот, у каждого конкретного случая разные: это не часть кода ошибки, а конкретные адреса в памяти и внутренние коды исключений именно этого сбоя на этом компьютере, и искать их в интернете почти всегда бессмысленно, потому что у другого человека они будут другими даже при абсолютно той же причине неполадки.
Наиболее частые коды bug check закреплены за определённой категорией проблем и стоит помнить их на память
Из нескольких сотен официально задокументированных кодов на практике встречается лишь небольшой повторяющийся набор, и уже по одному символьному имени можно примерно понять, в какую сторону копать ещё до всякого поиска:
- IRQL_NOT_LESS_OR_EQUAL, код 0x0000000A, почти всегда указывает на драйвер, который обратился к памяти на слишком высоком уровне приоритета прерываний, и чаще всего связан с сетевыми адаптерами или устаревшими антивирусными фильтрами;
- PAGE_FAULT_IN_NONPAGED_AREA, код 0x00000050, обычно говорит о повреждённой оперативной памяти либо о драйвере, который пытается читать данные из области, уже выгруженной из физической памяти;
- CRITICAL_PROCESS_DIED, код 0x000000EF, означает, что аварийно завершился один из ключевых системных процессов, и причиной чаще становится повреждение системных файлов или стороннее вмешательство в защищённые процессы, а не отдельный драйвер;
- WHEA_UNCORRECTABLE_ERROR, код 0x00000124, приходит напрямую от аппаратной подсистемы контроля ошибок процессора и почти никогда не лечится программно, указывая на перегрев, нестабильный разгон или неисправность самого железа.
Держать в голове хотя бы эти четыре категории полезно потому, что они сразу подсказывают, в какую сторону формулировать поисковый запрос: для WHEA бессмысленно искать драйвер и переустанавливать систему, а для IRQL_NOT_LESS_OR_EQUAL почти всегда стоит начинать именно с сетевого оборудования и антивируса.
Разбор на примере 0x0000003B показывает, что означает каждый конкретный параметр из журнала событий или дампа
На современном экране, будь то синий фон старых версий или чёрный экран Windows 11 после обновления 2025 года, видны обычно только три вещи: символьное имя ошибки, шестнадцатеричный код bug check и, если повезёт, имя виновного модуля. Начиная с Windows 8 Microsoft намеренно упростила сам экран сбоя и убрала с него список из четырёх дополнительных параметров, которые раньше выводились прямо под кодом ошибки в старых версиях вроде Windows 7 и XP. Сфотографировать эти параметры с современного монитора уже не получится, их нужно доставать отдельно из журнала событий или файла дампа, о которых пойдёт речь дальше.
Возьмём типичную запись именно оттуда: SYSTEM_SERVICE_EXCEPTION (0x0000003B) с параметрами вроде 0x00000000c0000005, 0xfffff802328375b0, 0xffff9c0a746c2330 и 0x0000000000000000. Первое число в скобках, 0x0000003B, это и есть код bug check, по нему официальная документация Microsoft однозначно определяет саму категорию сбоя: исключение произошло во время перехода от непривилегированного пользовательского кода к привилегированному коду ядра, чаще всего из-за обращения к освобождённому участку памяти или повреждённой структуры данных.
Первый параметр после кода, в примере 0x00000000c0000005, это отдельный код исключения в формате NTSTATUS, и именно его стоит гуглить отдельно от всего остального: 0xc0000005 расшифровывается как STATUS_ACCESS_VIOLATION, попытка обратиться к недоступной области памяти. Второй параметр это конкретный адрес инструкции в памяти, на которой произошёл сбой, третий это адрес служебной структуры для отладчика, а четвёртый в этом конкретном случае равен нулю и не несёт дополнительной информации. Из всей этой строки для обычного поиска в интернете полезны буквально два фрагмента: код bug check 0x0000003B и код исключения 0xc0000005, всё остальное это адреса, уникальные для конкретного запуска системы.
Правильный поисковый запрос строится из кода ошибки и имени виновного драйвера, а не из всей строки целиком
Из этого разбора следует практическое правило: в поисковую строку нужно вписывать не всю фразу с экрана, а короткую комбинацию из двух-трёх устойчивых элементов. Хорошо работает связка вида "SYSTEM_SERVICE_EXCEPTION 0x0000003B" вместе с названием конкретного драйвера, если оно показано на экране или найдено в дампе памяти, например ntoskrnl.exe, nvlddmkm.sys или ig9icd64.dll: такие имена файлов однозначно указывают на подсистему, обычно видеодрайвер, антивирус или контроллер накопителя, и резко сужают круг статей до действительно похожих случаев.
Отдельно стоит держаться подальше от адресов памяти вроде fffff802328375b0 в самом поисковом запросе: такие числа уникальны для конкретного компьютера и конкретного момента времени, поэтому поиск по ним либо не находит вообще ничего, либо выдаёт случайные форумные темы без реальной связи с проблемой. То же самое касается кода NTSTATUS без контекста, поиск одного лишь 0xc0000005 возвращает миллионы результатов сразу по десяткам разных программ, потому что нарушение доступа к памяти это одна из самых частых и общих категорий сбоев в принципе, и без имени конкретного драйвера или bug check рядом с ней такой запрос слишком расплывчат.
Официальная документация Microsoft для разработчиков даёт более точный разбор кода, чем большинство статей для пользователей
У каждого кода bug check есть страница в официальной документации Windows Driver Kit на сайте Microsoft Learn, изначально написанная для разработчиков драйверов, но полезная и для диагностики на обычном компьютере. Там перечислены точные названия и порядок всех параметров именно для этого кода, а не общее описание вроде "ошибка системной службы", которое повторяется на десятках сайтов с рекламой платных утилит очистки. Для поиска такой страницы обычно достаточно вбить в запрос слова bug check вместе с шестнадцатеричным кодом, например bug check 0x3b, вместо расплывчатого симптома вроде "синий экран после обновления".
Полезно также искать не сам факт ошибки, а её точную комбинацию с версией системы: часть кодов bug check исторически связана с конкретными редакциями Windows, например одна из известных причин 0x0000003B на Windows 7 и Server 2008 R2 была привязана к драйверу контроллера IEEE 1394, для которой Microsoft в своё время выпустила отдельное точечное исправление именно под эту версию системы. Такая же ошибка на современной Windows 11 почти наверняка вызвана уже другим драйвером, и старая статья про исправление десятилетней давности здесь просто неприменима, даже если код на экране совпадает буквально. Дописывать номер версии и разрядности системы к запросу, например Windows 11 24H2 или Windows 10 22H2, стоит почти всегда: одна и та же символьная ошибка на разных поколениях системы нередко имеет совершенно разных типичных виновников.
Файл минидампа содержит точную причину сбоя и позволяет проверить версию, полученную из поиска, а не гадать
Строка на экране это лишь верхушка того, что система записывает при сбое. Каждый раз при появлении синего или чёрного экрана Windows сохраняет в папку C:\Windows\Minidump небольшой файл с полным содержимым памяти на момент краха, включая список загруженных драйверов и точный стек вызовов, приведший к ошибке. Бесплатная утилита WinDbg от Microsoft умеет открывать такой файл и командой !analyze -v автоматически определять наиболее вероятный виновный модуль, часто указывая на конкретное имя файла драйвера прямо в первых строках отчёта, без необходимости гадать по формулировкам с форумов.
Это отличает диагностику по дампу от простого поиска по коду ошибки: поиск в интернете подсказывает список вероятных причин конкретного кода bug check в целом, а анализ собственного дампа показывает, какая из этих причин сработала именно на этом компьютере. Разумная стратегия поэтому такая: сначала быстро прочитать общее описание кода на странице Microsoft Learn, чтобы понять категорию проблемы, затем открыть свежий минидамп в WinDbg и получить имя конкретного драйвера, и только после этого искать в интернете уже точную комбинацию кода ошибки и имени этого драйвера, а не абстрактный симптом. Такой порядок экономит часы блуждания по одинаковым статьям про очистку реестра и почти всегда приводит либо к конкретному обновлению драйвера, либо к столь же конкретному выводу, что проблема лежит в оборудовании, а не в программной части системы.
Просмотр событий Windows дублирует часть информации с экрана сбоя и добавляет к ней историю предыдущих случаев
Помимо самого дампа, каждый bug check оставляет запись в журнале событий системы, в разделе Windows Logs и категории System, с источником события BugCheck. Именно там, а не на самом экране, находится полный набор из четырёх параметров вроде того же 0xc0000005, в удобном для копирования текстовом виде, без необходимости фотографировать монитор в момент сбоя. Это особенно полезно, если синий или чёрный экран исчезает слишком быстро, что как раз характерно для нового оформления в Windows 11, показывающего диагностику буквально пару секунд перед перезагрузкой.
Журнал событий также хранит историю: если один и тот же код bug check с одним и тем же виновным драйвером повторяется раз за разом на протяжении недель, это куда более сильный сигнал для поиска и для последующего решения проблемы, чем единичный случай. Разовый сбой с кодом 0x0000003B может быть случайным сочетанием обстоятельств вроде перегрева или разового сбоя оперативной памяти, тогда как регулярное повторение одного и того же кода вместе с одним и тем же драйвером почти всегда означает конкретную несовместимость или баг в этом драйвере, который стоит искать и обновлять целенаправленно, а не пытаться вылечить систему переустановкой целиком.
Начиная с Windows 11 версии 24H2 к этой картине добавился ещё один источник данных: функция Quick Machine Recovery, часть той же инициативы по повышению устойчивости системы. Если компьютер не может загрузиться из-за критического сбоя, среда восстановления теперь способна сама подключиться к сети, обратиться к серверам Windows Update и применить готовое исправление для уже известной проблемы без участия человека, в том числе временно отключить конкретный драйвер, ставший причиной массового сбоя. Для рядового пользователя это означает, что часть кодов ошибок, особенно вызванных широко растиражированным багом в популярном стороннем драйвере, теперь может быть закрыта автоматически ещё до того, как человек успеет открыть браузер и что-либо туда вписать, а поиск в интернете остаётся нужен именно для тех случаев, которые оказались достаточно редкими или локальными, чтобы не попасть в базу автоматических исправлений Microsoft.