Восемнадцатого августа тысячи владельцев Windows обнаружили одну и ту же картину. Быстрая проверка запускается, идёт несколько секунд, а затем система сообщает: служба защиты остановлена, требуется перезапуск. Перезапуск не помогает, следующая проверка обрывается в том же месте. Полное сканирование ведёт себя так же, а автономная проверка Microsoft Defender Offline застревает на отметке 90-93 процента и не двигается дальше. Для встроенного антивируса, который работает по умолчанию на сотнях миллионов компьютеров с Windows 10 и Windows 11, а также в корпоративных парках через Defender for Endpoint, это не рядовая мелкая ошибка, а массовый сбой базовой функции защиты.
Что происходило внутри процесса MsMpEng.exe при попытке запустить проверку
Антивирусный процесс MsMpEng.exe отвечает за координацию сканирования, а фактическую работу с файлами выполняет модуль mpengine.dll, ядро Microsoft Malware Protection Engine. Именно в этом модуле возникало исключение с кодом 0xC0000005, классическая ошибка обращения к недопустимой области памяти, access violation. Процесс аварийно завершался, служба защиты Windows перезапускалась автоматически через тысячу миллисекунд, но следующая попытка сканирования повторяла тот же сбой. Проблема прослеживалась до двух версий движка, 1.1.26070.7 и 1.1.26080.2, в связке с обновлениями баз угроз в диапазоне от 1.457.222.0 до 1.457.235.0. Часть пользователей отмечала интересную деталь: полная проверка отдельно взятого системного диска иногда завершалась без ошибок, тогда как запланированное или быстрое сканирование ломалось стабильно. Это указывало на то, что дефект сидел именно в пути обработки запланированных и быстрых проверок, а не в каждом акте чтения файла целиком.
Как читать журнал событий, чтобы найти точный код сбоя движка
Для диагностики стоит открыть Просмотр событий и перейти в раздел Приложения и службы, далее Microsoft, Windows, Windows Defender, Operational. В журнале Приложение фиксируется классическая запись о падении процесса: имя приложения MsMpEng.exe, имя модуля mpengine.dll, код исключения 0xc0000005, смещение сбоя и путь к процессу вида C:\ProgramData\Microsoft\Windows Defender\Platform. Отдельного внимания заслуживает событие с идентификатором 5008, символьное имя MALWAREPROTECTION_ENGINE_FAILURE. Оно означает, что движок защиты завершился из-за непредвиденной ошибки, и в теле события указываются тип отказа, код исключения и конкретный ресурс, в данном случае mpengine.dll. Именно связка исключения 0xC0000005 с событием 5008 и является главным диагностическим признаком того, что перед пользователем не заражение, а сбой обновлённого движка сканирования.
Как отличить падение движка сканирования от реального заражения системы
Резкое прекращение работы антивируса пугает само по себе, потому что многие вредоносные программы намеренно останавливают защитные службы, чтобы закрепиться в системе. Разница видна по нескольким признакам. Во-первых, при реальном заражении вредонос обычно отключает службу целиком и не даёт ей перезапуститься штатными средствами, тогда как в случае с багом движка служба перезапускается автоматически, просто падает заново при следующей попытке проверки. Во-вторых, при программном сбое движка событие 5008 появляется практически сразу после старта проверки и на разных машинах указывает один и тот же модуль mpengine.dll с одним и тем же кодом исключения, что нетипично для целенаправленной атаки. В-третьих, у части пользователей защита в реальном времени, компонент Real-Time Protection, продолжала работать даже тогда, когда ручные проверки обрывались, а значит фоновый контроль файлов при открытии и запуске сохранялся. Проверить статус можно командой Get-MpComputerStatus в PowerShell с правами администратора, она покажет версию движка, версию баз сигнатур и состояние компонентов защиты в реальном времени. Если антивирус для конечных точек, встроенный в корпоративное решение Defender for Endpoint, не поднимает тревожных оповещений по индикаторам компрометации на затронутых машинах, а падение сопровождается событием 5008 сразу на нескольких независимых устройствах, это веский аргумент в пользу версии о дефектном обновлении, а не о вторжении. Полностью исключать заражение по одному лишь совпадению кода ошибки нельзя, поэтому при малейших сомнениях стоит прогнать систему альтернативным сканером или воспользоваться автономной загрузочной средой, не зависящей от повреждённого движка.
Какие события в журнале Defender стоит держать под наблюдением при мониторинге
Чтобы отслеживать состояние антивируса не вручную, а по конкретным идентификаторам, полезно свериться со следующим списком основных событий раздела Windows Defender Operational:
- 1000, антивирусная проверка началась, фиксируется тип проверки и её параметры;
- 1001, проверка завершена штатно, без прерываний;
- 1002, проверка остановлена или отменена пользователем либо системой;
- 1005, проверка прервана из-за ошибки, часто требует настройки исключений;
- 5000, защита в реальном времени включена и активно сканирует файловую систему;
- 5007, изменилась конфигурация платформы антивируса, полезно при откате настроек;
- 5008, движок защиты завершился из-за непредвиденной ошибки, ключевой признак сбоя mpengine.dll.
Регулярная выборка этих идентификаторов через диспетчер событий или через PowerShell командой Get-WinEvent с фильтром по журналу Microsoft-Windows-Windows Defender/Operational позволяет быстро увидеть, что происходит на десятках машин одновременно, без ручного открытия консоли на каждой из них.
Как обновить сигнатуры вручную через MpCmdRun в обход центрального распространения
Автоматическое исправление приходит вместе с обновлением сигнатур Microsoft Defender Antivirus версии 1.457.236.0 или новее, оно устанавливается через обычный канал Центра обновления Windows и применяется без участия пользователя. Но на практике распространение прошло неравномерно, часть систем действительно избавилась от сбоев после версии 1.457.236.0, а другим потребовалась более новая версия 1.457.238.0 или последующая. Если система застряла на дефектном наборе сигнатур и не подтягивает новую версию сама, есть ручной путь через утилиту командной строки MpCmdRun.exe, которая лежит в каталоге установки Defender. Сначала стоит убрать проблемные динамические сигнатуры точечной командой:
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -RemoveDefinitions -DynamicSignatures
Параметр DynamicSignatures важен именно потому, что затрагивает только динамически загруженные дополнения к базам угроз и не трогает основной инсталляционный набор, в отличие от более грубого параметра -All, который откатывает движок и сигнатуры к встроенному заводскому состоянию и годится лишь как крайняя мера для целого парка машин. После очистки динамических сигнатур запрашивается свежее обновление:
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdate
Проверить итоговую версию баз и движка помогает всё та же команда Get-MpComputerStatus, в выводе которой видны поля AntivirusSignatureVersion и AMEngineVersion. Администраторам, управляющим большим количеством конечных точек через Defender for Endpoint, стоит выбирать целью не конкретно версию 1.457.236.0, раз она помогла не всем, а самую свежую версию сигнатур, доступную в канале управления на момент проверки, и затем подтверждать успешную проверку на контрольной группе устройств прежде, чем считать инцидент закрытым по всему парку.
Почему версия 1.457.236 не сработала у всех сразу и при чём тут уязвимость ShieldBreak
Хронология подсказывает вероятную причину появления бага. Двенадцатого августа, сразу после августовского вторника обновлений, был опубликован приём обхода патча для уязвимости повышения привилегий в движке Malware Protection Engine, получившей внутреннее имя ShieldBreak и идентификатор CVE-2026-69414. Эта уязвимость представляла собой обход июльского исправления другой проблемы, зафиксированной как CVE-2026-50656, для которой Microsoft уже выпускала патч в версии движка 1.1.26060.3008. ShieldBreak позволял локальному пользователю с ограниченными правами получить привилегии уровня SYSTEM при условии, что защита Defender включена и активна, что делало уязвимость особенно неприятной именно из-за широкого охвата установленного по умолчанию антивируса. По времени публичного разбора и по срокам появления дефектных сигнатур совпадение выглядит слишком точным, чтобы списать его на случайность, поэтому среди специалистов возникло предположение, что сбойные обновления баз стали следствием поспешной попытки закрыть брешь через сигнатурный, а не платформенный механизм. Прямых официальных подтверждений этой связи опубликовано не было, компания ограничилась указанием на то, что фикс поставляется через обновление сигнатур, без развёрнутого объяснения первопричины самого дефекта. Независимо от истинной причины, практический вывод для администраторов один: после исправления критической уязвимости в защитном программном обеспечении стоит внимательнее следить за стабильностью работы самого защитного механизма в течение нескольких дней, а не считать инцидент закрытым сразу после установки патча.
Что делать администраторам корпоративных парков компьютеров с Defender for Endpoint
Первый шаг для управляемой среды, это инвентаризация версий. На каждой конечной точке стоит зафиксировать текущую версию Security Intelligence и версию движка через Get-MpComputerStatus или через консоль Defender for Endpoint, и сравнить с целевой версией 1.457.236.0 и выше, помня, что часть устройств потребует более новой версии вплоть до 1.457.238.0. Второй шаг, это избегать радикальных мер вроде переустановки операционной системы только из-за отказа сканирования: часть пользователей действительно шла на переустановку Windows целиком, хотя проблема лежала на уровне сигнатур и решалась их обновлением без потери данных и настроек. Третий шаг, это точечное применение команды -RemoveDefinitions с параметром DynamicSignatures вместо широкого параметра -All на массиве устройств, потому что широкий откат меняет больше состояния антивируса, чем нужно для устранения конкретного дефекта, и затем требует более долгой повторной синхронизации баз. Четвёртый шаг, это контроль за реальным состоянием защиты в реальном времени в период инцидента: даже когда ручные проверки падали, у многих машин фоновая защита оставалась активной, и это стоит подтвердить через событие 5000 и статус RealTimeProtectionEnabled в выводе Get-MpComputerStatus, чтобы верно оценить фактический уровень риска на затронутом парке, а не полагаться только на факт сбоя сканирования. Пятый шаг, это документирование инцидента с привязкой к версиям движка и сигнатур, поскольку подобные истории с Defender случаются не впервые: ранее в этом же году фиксировалось ошибочное определение корневых сертификатов DigiCert как вредоносного объекта Trojan:Win32/Cerdigent.A!dha, что приводило к массовым ложным срабатываниям и удалению сертификатов из доверенного хранилища Windows, а ещё раньше происходил сбой портала Defender XDR, ограничивавший доступ к части возможностей охоты за угрозами. Каждый такой случай подтверждает практическую пользу заранее выстроенного процесса проверки версий движка и сигнатур перед тем, как считать обновление безопасности полностью развернутым и стабильным.
Итоговая последовательность действий для быстрого восстановления защиты
Для рядового пользователя порядок действий укладывается в несколько шагов без глубокого погружения в журналы событий. Сначала стоит открыть Центр обновления Windows и вручную проверить наличие новых обновлений, поскольку исправление ставится именно через канал обновления сигнатур, а не через отдельный патч операционной системы. Затем через приложение Безопасность Windows нужно убедиться, что установлена версия Security Intelligence не ниже 1.457.236.0, а лучше самая свежая из доступных на момент проверки. Если обновление не подтягивается автоматически, помогает связка команд MpCmdRun с параметрами RemoveDefinitions DynamicSignatures и SignatureUpdate из административной командной строки. После этого стоит запустить быструю проверку и убедиться, что она доходит до конца без сообщения об остановке службы защиты. Если сбои продолжаются даже на свежих сигнатурах, разумно временно опереться на защиту в реальном времени, которая в большинстве описанных случаев продолжала функционировать, и подождать следующего обновления баз, не прибегая к радикальным шагам вроде переустановки системы. Такой подход экономит время и избавляет от лишнего риска потери данных, а сама история с падением MsMpEng.exe в очередной раз показывает, что даже встроенный и максимально автоматизированный защитный механизм требует периодической проверки версий и внимательного чтения журнала событий, а не слепой веры в то, что автоматическое обновление всегда срабатывает одинаково быстро на каждой отдельной машине.