«Antimalware Service Executable» — високе завантаження CPU: виправити без відключення захисту

Що таке Antimalware Service Executable (і чому він спричиняє піки)

Antimalware Service Executable — це двигун Windows Defender Antivirus, що працює як служба. Зазвичай у списку процесів ви побачите назву MsMpEng.exe. Він виконує сканування в реальному часі, сканування за запитом, заплановані сканування та фонові завдання обслуговування — наприклад оновлення сигнатур і керування кешем.

Високе завантаження CPU виникає, коли Defender виконує дорогі операції:

• Сканує велику кількість дрібних файлів (папки розробників, кеші пакетів, сховища пошти).
• Сканує великі стиснуті/віртуалізовані контейнери (ZIP, ISO, VHD/VHDX, шари контейнерів).
• Перехоплює «гарячі» шляхи вводу/виводу файлів, де файли постійно створюються/змінюються (вихідні каталоги збірки, тимчасові папки).
• Конфліктує з іншим засобом безпеки (подвійне сканування, конфлікт драйверів фільтра файлів).
• Після оновлення або зміни сигнатур, що спричиняє повторну переоцінку файлів.
• Низькопотужний CPU + навантажений диск, через що все здається «CPU», хоча насправді це очікування вводу/виводу і перемикання контексту.

Мета не в тому, щоб «зупинити сканування». Мета — зробити сканування цільовим, запланованим і передбачуваним, а також усунути марні повторні перевірки папок з високим обігом файлів.

Одна закономірність у продакшені: якщо ви не контролюєте, де ваш засіб безпеки витрачає CPU, він обере найневигідніший момент. Наче кіт, але з підключеннями до ядра.

Швидкий план діагностики (перші/другі/треті перевірки)

Перше: підтвердіть, що це Defender і знайдіть тригер

1. Диспетчер завдань: перевірте, що процес — Antimalware Service Executable і що завантаження CPU тривале (а не 5-секундний сплеск).
2. Монітор ресурсів: подивіться, чи це обчислювальне навантаження CPU, чи хвилинна буря файлового вводу/виводу.
3. Windows Security → Захист від вірусів і загроз: перевірте, чи запущене сканування, або чи не відбулося нещодавнє оновлення сигнатур.

Друге: знайдіть, що саме сканується

1. Перевірте журнал операцій Defender на наявність інформації про нещодавні сканування й шляхи.
2. Зіставте з тим, що змінилося: новий інструментарій розробника, нове репозиторій, нові віртуальні машини, синхронізація OneDrive, оновлення Windows.
3. Якщо ви на корпоративному кінцевому пристрої: перевірте наявність другого агента AV/EDR. Два стеки фільтрів файлової системи можуть перетворити «безпеку» на «перформанс-арт».

Третє: оберіть найменш ризиковий важіль продуктивності

1. Планування: перемістіть важкі сканування поза робочими годинами; зменшіть інтенсивність сканування, якщо політика дозволяє.
2. Винятки: додайте вузькі, обґрунтовані винятки для папок з високим обігом (кеші збірки), а не «C:\», бо ви любите ризикувати.
3. Оновлення/відновлення: виправте пошкоджений стан сигнатур; очистіть проблемні кеші; оновіть платформу Defender.
4. Вирішення конфліктів: якщо є інший AV, налаштуйте взаємні винятки або дотримуйтесь політики організації, щоб уникнути подвійного сканування.

Цікаві факти та історичний контекст

• Defender не завжди був «тим» антивірусом. Ранні версії були окремими завантаженнями й «достатньо добрим» базовим рішенням; тепер він глибоко інтегрований і керується як компонент ОС.
• MsMpEng.exe — це лише користувацький інтерфейс. Справжня важка робота задіює драйвери фільтра в режимі ядра, які перехоплюють операції з файлами, щоб сканувати контент до його виконання/використання.
• Сканування в реальному часі — це, по суті, податок на обіг файлів. Якщо ваше навантаження створює 200 000 дрібних файлів, Defender помітить це. Голосно.
• «Високе CPU» часто приховує «звʼязане з диском». Коли процес чекає на сховище, Windows все одно може показувати високе CPU через перемикання контексту, DPC/ISR-активність та черги.
• Стиснуті архіви — дорогі в обробці. Сканування великого ZIP фактично означає логічне сканування розпакованого контенту, що потребує значних обчислювальних ресурсів і може спричинити тривалі сплески одного процесу.
• Оновлення сигнатур можуть викликати повторну оцінку. Нова інтелектуальна база може зробити кешовані рішення сканера застарілими, спричинивши повторні перевірки.
• Машини розробників — найгірший вхідний кейс. Node-модулі, Python wheels, кеші NuGet, репозиторії Maven — це фактично «стреси для дрібних файлів».
• Віртуальні диски множать проблеми. Сканування VHDX під час того, як гість також сканує всередині, створює дурний зворотний звʼязок.

Практичні завдання: команди, виходи та рішення (12+)

Ці завдання покликані відповісти на одне питання: що робить Defender, і який важіль найменш ризиковий? Більшість команд використовують PowerShell. Блоки коду відображені з bash-підказкою для узгодженості форматування; запускайте їх у піднятому вгору вікні PowerShell, якщо інше не зазначено.

Завдання 1: Підтвердити процес і його навантаження на CPU

cr0x@server:~$ tasklist /fi "imagename eq MsMpEng.exe"
Image Name                     PID Session Name        Session#    Mem Usage
========================= ======== ================ =========== ============
MsMpEng.exe                   4128 Services                   0    312,456 K

Що це означає: MsMpEng.exe присутній і у вас є PID для кореляції з іншими інструментами.

Рішення: Якщо MsMpEng.exe відсутній, ви розслідуєте не ту причину (часто служба Microsoft Defender Antivirus вимкнена або замінена стороннім AV; високе навантаження може йти від агента EDR).

Завдання 2: Зробити знімок використання CPU і перевірити, чи тривале воно

cr0x@server:~$ powershell -NoProfile -Command "Get-Process MsMpEng | Select-Object Id,CPU,WorkingSet,StartTime | Format-List"
Id         : 4128
CPU        : 1842.53
WorkingSet : 328232960
StartTime  : 02/05/2026 08:41:12

Що це означає: Поле CPU — кумулятивні секунди з початку процесу. Перезапустіть через 30 секунд, щоб побачити різницю.

Рішення: Якщо CPU швидко зростає і залишається високим під час звичайної роботи, переходьте до виявлення тригера сканування і «гарячих» шляхів.

Завдання 3: Перевірити, чи відбувається сканування зараз

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMRunningMode,RealTimeProtectionEnabled,OnAccessProtectionEnabled,AntispywareEnabled,AntivirusEnabled"
AMRunningMode              : Normal
RealTimeProtectionEnabled  : True
OnAccessProtectionEnabled  : True
AntispywareEnabled         : True
AntivirusEnabled           : True

Що це означає: Defender активний. Це не підтверджує, що зараз іде повне сканування, але підтверджує, що рушій увімкнений і перехоплює доступ до файлів.

Рішення: Якщо Defender тут вимкнений, але MsMpEng все одно завантажений, можлива корупція платформи або конфлікт політик — переходьте до перевірок відновлення/оновлення.

Завдання 4: Подивитися часи останніх сканувань і індикатори

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object QuickScanEndTime,FullScanEndTime,FullScanStartTime,QuickScanStartTime,AntivirusSignatureLastUpdated"
QuickScanEndTime              : 02/05/2026 09:05:31
FullScanEndTime               : 
FullScanStartTime             : 02/05/2026 09:06:10
QuickScanStartTime            : 02/05/2026 09:03:02
AntivirusSignatureLastUpdated : 02/05/2026 08:59:44

Що це означає: Повне сканування почалося кілька хвилин тому. Оце і є «чому зараз».

Рішення: Якщо повне сканування йде в робочі години, спочатку виправляйте планування/політику. Не засмічуйте список винятків бездумно.

Завдання 5: Перевірити поточні винятки Defender (шляхи, процеси, розширення)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object -ExpandProperty ExclusionPath"
C:\ProgramData\Docker
C:\Users\dev\AppData\Local\Temp

Що це означає: Defender уже пропускає ці шляхи. Добре знати перед додаванням нових.

Рішення: Якщо бачите надто широкі винятки (наприклад весь профіль користувача або корінь диска), це проблема безпеки під соусом «підгонки продуктивності». Звужуйте їх.

Завдання 6: Знайти конфігурацію запланованого сканування, яка може бути неправильно запланована

cr0x@server:~$ powershell -NoProfile -Command "Get-MpPreference | Select-Object ScanScheduleDay,ScanScheduleTime,DisableCatchupFullScan,DisableCatchupQuickScan"
ScanScheduleDay        : 0
ScanScheduleTime       : 02:00:00
DisableCatchupFullScan : False
DisableCatchupQuickScan: False

Що це означає: Заплановані сканування встановлені (день 0 часто означає щодня залежно від контексту політики), і дозволені надолужувальні сканування.

Рішення: Якщо ноутбуки сплять о 2:00, надолужувальні сканування запустяться о 9:00 — саме коли починається робочий день. Розгляньте керування поведінкою надолуження через політику.

Завдання 7: Перевірити журнал операцій Defender на активність сканування

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -AutoSize"
TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
2/5/2026 9:06:11 AM 1000 Information      Scan started.
2/5/2026 9:06:12 AM 1001 Information      Scan type: Full Scan
2/5/2026 9:06:13 AM 1116 Warning          Malware detected: ... (remediated)

Що це означає: Ви можете підтвердити початок сканування, його тип і чи спричинили виявлення додаткову роботу (виправлення також може спричинити сплеск CPU).

Рішення: Якщо журнал показує повторні стартови сканувань або помилки, можливо, завдання застрягло або стан пошкоджений. Виправляйте основну причину; не лише переплановуйте.

Завдання 8: Виміряти, чи є вузьке місце в накопичувачі (швидка перевірка)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk Queue Length','\PhysicalDisk(_Total)\Disk Bytes/sec' -SampleInterval 1 -MaxSamples 5 | Select-Object -ExpandProperty CounterSamples | Select-Object Path,CookedValue | Format-Table -AutoSize"
Path                                           CookedValue
----                                           -----------
\\DESKTOP\physicaldisk(_total)\\avg. disk queue length   9.2
\\DESKTOP\physicaldisk(_total)\\disk bytes/sec    84539212

Що це означає: Висока довжина черги вказує на насиченість диска. Defender може інтенсивно читати, а все інше чекає в черзі.

Рішення: Якщо черга диска висока, орієнтуйтеся на зменшення обігу файлів і винятки для безпечних кешів з високим обігом. Налаштування CPU самі по собі мало допоможуть.

Завдання 9: Виявити активність файлів, повʼязану з MsMpEng, через Resource Monitor (CLI-замінник)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process -Id (Get-Process MsMpEng).Id | Select-Object Id,Threads,Handles,Path"
Id Threads Handles Path
-- ------- ------- ----
4128     64    1750 C:\ProgramData\Microsoft\Windows Defender\Platform\4.18.24090.11-0\MsMpEng.exe

Що це означає: Ще не список файлів, але підказка: вибух підпроцесів/хендлів часто корелює з масивним перерахунком файлів.

Рішення: Якщо кількість хендлів/потоків аномально висока і машина під свопом, розглядайте це як «занадто широкий обʼєм сканування» або «вибух шляхів». Використовуйте журнали й стратегію винятків.

Завдання 10: Перевірити версію платформи Defender (старі двигуни можуть поводитися некоректно)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select-Object AMEngineVersion,AMProductVersion,AMServiceVersion,AntivirusSignatureVersion"
AMEngineVersion           : 1.1.24090.11
AMProductVersion          : 4.18.24090.11
AMServiceVersion          : 4.18.24090.11
AntivirusSignatureVersion : 1.409.1123.0

Що це означає: Ви бачите, чи ваша платформа застаріла чи відносно актуальна. Деякі проблеми продуктивності залежать від конкретної версії двигуна.

Рішення: Якщо платформа відстає від корпоративного базового рівня, оновіть/застосуйте патчі спочатку. Налаштовувати продуктивність на багованій версії — як полірувати пробите колесо.

Завдання 11: Примусити оновлення сигнатур (безпечний та часто ефективний крок)

cr0x@server:~$ powershell -NoProfile -Command "Update-MpSignature"

Що це означає: Зазвичай відсутність виводу означає успіх (або кероване оновлення). Перевірте стан після виконання.

Рішення: Якщо оновлення постійно падають, можуть бути проблеми з мережею/проксі/політикою. Це треба виправити; застарілі сигнатури подовжують сканування і підвищують кількість хибних спрацьовувань.

Завдання 12: Запустити цільове сканування замість повного (контролювати площу ураження)

cr0x@server:~$ powershell -NoProfile -Command "Start-MpScan -ScanType CustomScan -ScanPath 'C:\Users\dev\Downloads'"

Що це означає: Ви вказуєте Defender, що саме сканувати зараз, замість дозволяти йому блукати по всьому диску.

Рішення: Корисно на машинах розробників: частіше скануйте точки входу ризикованого контенту (Downloads, USB, вкладення), а повні сканування тримайте у позаробочий час.

Завдання 13: Додати вузький виняток для кешу з високим обігом (тільки після доказів)

cr0x@server:~$ powershell -NoProfile -Command "Add-MpPreference -ExclusionPath 'C:\Users\dev\AppData\Local\npm-cache'"

Що це означає: Defender пропускатиме цей шлях під час перевірки при доступі (політика може перекривати). Це може різко зменшити навантаження CPU на системах із сильною залежністю від Node.

Рішення: Винятки додавайте тільки для відтворюваних кешів, куди рідко запускають виконувані файли. Якщо користувачі запускають з цих місць бінарні файли, не додавайте виняток.

Завдання 14: Додати виняток процесу для інструмента збірки (використовуйте обережно)

cr0x@server:~$ powershell -NoProfile -Command "Add-MpPreference -ExclusionProcess 'C:\Program Files\Git\usr\bin\bash.exe'"

Що це означає: Файли, відкриті цим процесом, можуть бути виключені зі сканування. Це потужний і ризиковий крок.

Рішення: Віддавайте перевагу виняткам шляхів над винятками процесів. Виняток процесу може стати «не скануй нічого, коли цей процес торкається файлів», що занадто широко.

Завдання 15: Видалити поганий виняток, що успадкований

cr0x@server:~$ powershell -NoProfile -Command "Remove-MpPreference -ExclusionPath 'C:\'"

Що це означає: Якщо команда спрацює, ви щойно закрили серйозну діру в захисті.

Рішення: Якщо в організації реально потрібні широкі винятки, має бути процес винятків — не випадкова самовільна правка.

Завдання 16: Перевірити заплановані завдання, що можуть повторно запускати сканування

cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask -TaskPath '\Microsoft\Windows\Windows Defender\' | Select-Object TaskName,State | Format-Table -AutoSize"
TaskName                          State
--------                          -----
Windows Defender Cache Maintenance Ready
Windows Defender Cleanup          Ready
Windows Defender Scheduled Scan   Ready
Windows Defender Verification     Ready

Що це означає: Defender використовує планувальник завдань для обслуговування. Якщо одне з них застрягло у стані «Running», це підказка.

Рішення: Якщо завдання застряглі, перегляньте їхню історію і розгляньте відновлення платформи Defender замість постійного вбивання MsMpEng.

Кореневі причини, що створюють високе CPU (і як їх підтвердити)

1) Повне сканування у найневідповідний час

Класика. Хтось запланував сканування на 2:00. Ноутбуки сплять о 2:00. Defender терпляче чекає, а потім запускає надолужувальне сканування о 9:07, коли всі відкривають Teams і IDE.

Підтвердити: Get-MpComputerStatus показує нещодавній старт сканування; журнал операцій Defender показує «Scan started» і тип сканування.

Виправити: Підкоригуйте розклад сканувань і поведінку надолуження через політику; забезпечте вікно обслуговування, коли пристрої підключені і увімкнені, або заплануйте під час обідньої перерви.

2) Папки розробки або CI з високим обігом файлів

Якщо машина весь час генерує об’єктні файли, підвантажує залежності і розпаковує архіви в тисячі файлів, сканування в реальному часі множить кожен крок збірки.

Підтвердити: Пік співпадає зі збірками (dotnet build, npm install, mvn package), і підвищується довжина черги диска. Журнали Defender часто показують високу активність у цей час, навіть якщо не перераховують кожний файл.

Виправити: Виключіть конкретні кеші/вихідні каталоги збірки (не каталоги з вихідним кодом); залиште сканування для джерел і точок входу завантажень.

3) Віртуалізація і «подвійне сканування»

Хост сканує VHDX. Гість сканує свою файлову систему. Обидва правильні окремо, але разом — абсурд.

Підтвердити: Піки CPU під час активності віртуальних машин; висока пропускна здатність диска; VHDX-файли активно читаються; у гостьовій ОС також видно активність антивірусу.

Виправити: Надавайте перевагу скануванню всередині гостьової ОС для контенту гостя і розгляньте виняття дисків VM на хості (за чіткою політикою і компенсуючими контролями). Аналогічно для Docker/WSL2, якщо організація дозволяє.

4) Інший продукт безпеки конфліктує з Defender

Деякі середовища запускають Defender разом з EDR-агентом або стороннім AV, який нібито «перекриває» Defender. Якщо конфігурація неправильна, отримаєте конфлікт драйверів фільтра, подвійне сканування і загадкові сплески CPU.

Підтвердити: Установлені програми показують інший AV/EDR; журнали показують, що обидва торкаються тих самих шляхів; проблеми з продуктивністю зберігаються, навіть коли заплановані сканування Defender не йдуть.

Виправити: Дотримуйтесь вказівок вендора щодо взаємних винятків і переконайтеся, що лише один AV-двигун виконує сканування в реальному часі (якщо політика дозволяє). Не робіть цього на корпоративних кінцевих пристроях без узгодження.

5) Пошкоджений стан або застрягле обслуговування

Інколи Defender потрапляє в петлю: повторні сканування, перевірки кешу або спроби оновлень сигнатур. Це трапляється рідше, ніж «у вас мільйон файлів», але трапляється.

Підтвердити: Журнал операцій Defender показує повторні події, помилки або життєві цикли оновлень; платформа застаріла; заплановані завдання застрягли у стані «Running».

Виправити: Оновіть платформу/сигнатури Defender; відновіть системні файли; перезавантажте систему (так, дійсно) щоб очистити застряглі драйвери/завдання; ескалюйте до відновлення ОС, якщо журнали вказують на корупцію компонентів.

Жарт #1: Вимкнути Defender, щоб вирішити високий CPU — як перерізати пасок безпеки, щоб схуднути. Легше буде до того моменту, поки не вступлять у дію закони фізики.

Виправлення, що зберігають безпеку ввімкненою

Не ставте винятки в ролі фічі продуктивності

Винятки — це рішення в області безпеки. Вони мають бути:

• Вузькими (конкретна папка, не весь диск).
• Обґрунтованими (ви можете пояснити, чому сканування там має мало цінності або дублюється).
• Компенсованими (ви скануєте входи до тієї папки або артефакти перед публікацією).
• Аудитованими (періодично переглядаються і скасовуються, коли потреба зникає).

Зробіть сканування нудними: плануйте й уникайте сюрпризів надолуження

На кінцевих пристроях найбільший виграш — перемістити повні сканування поза інтерактивні години. Якщо ноутбуки не залишаються увімкненими вночі, потрібна політика для надолужувальних сканувань або вікно обслуговування, коли пристрої підключені і активні.

У корпоративному середовищі це зазвичай рішення групової політики / MDM, а не індивідуальна правка. Правильно — це нудно, повторювано й документовано — тому й працює.

Виключайте кеші з високим обігом, а не те, що виконується

Приклади, що часто мають сенс виключати у контексті розробки після перевірки:

• Кеші менеджерів пакетів: npm/yarn/pnpm кеші, глобальні пакети NuGet, кеші Maven/Gradle.
• Вихідні каталоги збірки, які відтворюються: bin/obj (на рівні проєкту), target, dist.
• Тимчасові сандбокси компіляції.

Приклади, які зазвичай не варто виключати:

• Downloads, кеші вкладень пошти, каталоги браузерного кешу, які використовуються для завантажень.
• Корені профілів користувачів.
• Весь корінь репозиторію, де виконуються скрипти та інструменти.
• Будь-що, що отримує контент з інтернету і потім виконується.

Контролюйте «точки входу», замість сканувати все весь час

Якщо доводиться міняти щось, міняйте обсяг, а не безпеку. Залишайте сильне сканування для:

• Папок завантажень і вкладень
• USB/знімних носіїв
• Вхідних точок браузера і клієнтів пошти

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

Відновіть здоровʼя оновлень і рівень платформи

Несподівано велика кількість випадків «Defender розплавлює мій CPU» — це просто «Defender хворий». Помилки оновлень викликають повторні спроби; застарілі платформи можуть мати баги продуктивності, які вже виправлено.

Що я роблю на практиці:

• Перевіряю версії через Get-MpComputerStatus.
• Запускаю Update-MpSignature.
• Перевіряю загальний стан Windows Update (бо Defender у багатьох середовищах покладається на цю інфраструктуру).

Знати, коли ескалювати: файлові сервери та сервери збірки потребують політик

Для серверів, що містять код, артефакти або великі набори даних, конфігурація Defender має бути в системі керування конфігурацією. Випадкові винятки на кожному сервері призведуть до кошмару відповідності.

На серверах збірки/CI зазвичай роблять винятки для:

• Кешів робочих просторів, які відтворюються
• Зберігання шарів контейнерів (коли образи скануються в іншому місці)
• Кешів артефактів

Але робіть це з урахуванням моделі загроз: звідки надходять артефакти і де їх сканують перед релізом?

Одна цитата про надійність, щоб тримати себе в дисципліні

«Надія — не стратегія.» — Генерал Гордон Р. Салліван

Планування сканувань, обмеження винятків і перевірка здоровʼя оновлень — це стратегії. Надія, що користувачі не будуть натискати на невідоме, — ні.

Три корпоративні історії з поля бою

Міні-історія 1: Інцидент через неправильне припущення

У середній компанії з типовим парком Windows розробники скаржилися, що збірки ставали повільнішими щотижня. Диспетчер завдань показував MsMpEng.exe, тому негайним припущенням було «Defender сканує наш репозиторій і вбиває продуктивність».

Команда десктопу додала широкі винятки для кореня репозиторію. CPU впав. Усі святкували. Потім внутрішній аудит позначив виняток як надто широкий, і безпека поставила незручне питання: «Навіщо нам виключати виконувані скрипти і інструменти, що запускаються з репозиторію?»

Коли ми розібралися, виявилося, що репозиторій насправді не був головним винуватцем. Проблемою був кеш пакетів, який лежав під профілем користувача і постійно змінювався під час збірок. Репозиторій мав великі, але відносно стабільні файли; кеш же створював ураган дрібних записів.

Вирішили звузити винятки: виключили лише кеші і вихідні папки збірки, лишили сканування для самого репозиторію й додали цільове сканування Downloads. Часи збірки відновилися без розширення поверхні атаки.

Урок: не гадати. Підтвердіть, які шляхи дійсно мають високий обіг, і виключайте їх — не «корона».

Міні-історія 2: Оптимізація, що відгукнулася боковим ефектом

Інша організація мала кілька Windows-агентів збірки, що створювали підписані артефакти. Агенти були «занадто повільні», тож хтось вирішив пришвидшити їх, виключивши весь робочий простір і директорію для стадіювання артефактів. Агентам стало швидше одразу.

Через два місяці компрометація залежності в екосистемі призвела до того, що агент завантажив отруєний пакет у кеш робочого простору. Через виняток Defender ніколи не перевірив його при доступі. У пайплайні був інший сканер, але він запускался після пакування і не досліджував шляхи інструментів збірки глибоко.

Наслідків для клієнтів не було — хтось спіймав проблему перед релізом — але відповідь була дорогою: перегляд пайплайну, перевстановлення агентів, екстрене прибирання політик і некомфортна нарада «чому ми так зробили».

Проблема не в існуванні винятків. Проблема в тому, що виняток застосували до шляху, що приймає недовірений вхід, без компенсаторних контролів. Продуктивність покращилась; ризик тихцем виріс.

Урок: винятки мають супроводжуватися перевіркою точок входу і тим, де сканують артефакти. Інакше проблему просто переміщено в чергу інцидентів.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

В одній доволі великій компанії кінцеві пристрої були строго керовані: політики Defender через MDM, стандартизовані вікна сканувань і формальний процес запиту винятків. Розробникам, звісно, подобалася не вся ця бюрократія.

Потім оновлення Windows супало з оновленням платформи Defender, і частина машин почала бачити ранкові піки CPU. Ключова відмінність: у цієї організації вже була базова конфігурація і телеметрія. Вони могли швидко зіставити «здорові» і «спікні» конфігурації.

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

За тиждень кількість інцидентів упала, скарги на продуктивність зникли. Позиція безпеки не послабшала; вона стала більш послідовною.

Урок: нудна практика — централізована політика, маленькі затверджені винятки, послідовне планування — краща за героїчне дебагування на окремих машинах.

Поширені помилки: симптом → корінь → виправлення

1) «MsMpEng.exe на 80–100% CPU відразу після входу в систему»

Корінь: Надолужувальне сканування або обслуговування, що відбувається після сну пристрою в заплановане вікно.

Виправлення: Підкоригуйте графік сканувань на часи, коли пристрої зазвичай увімкнені, або керуйте поведінкою надолуження. Підтвердіть через часи початку сканування і журнали Defender.

2) «CPU піки під час збірок або встановлення залежностей»

Корінь: Сканування в реальному часі папок з високим обігом (кеші/вихідні збірки з тисячами дрібних файлів).

Виправлення: Додайте вузькі винятки тільки для кешів/виходів збірки (наприклад, кеш npm, NuGet, obj/bin) і зберігайте сканування для Downloads та коренів репозиторіїв.

3) «Defender високо завантажує CPU, але диск теж зашкалює»

Корінь: Вузьке місце сховища; читання/метадані Defender заповнюють диск і спричиняють загальну затримку системи.

Виправлення: Зменште обсяг сканування (винятки), заплануйте повні сканування в позаробочий час і розгляньте модернізацію накопичувача (HDD → SSD). Підтвердіть через лічильники довжини черги диска.

4) «Defender ніколи не заспокоюється; він постійно сканує»

Корінь: Застрягле заплановане завдання, повторні невдачі оновлень або проблема зі станом платформи, що викликає повторні спроби.

Виправлення: Перевірте стан запланованих завдань, журнали Defender і оновлення сигнатур. Відновіть стан оновлень; перезавантаження може очистити застряглі драйвери/завдання.

5) «Ми додали виняток і тепер десь зʼявилися дивні виявлення»

Корінь: Виключено директорію, що містила інструменти або скрипти; шкідливе ПЗ перейшло в «сліпу» зону.

Виправлення: Приберіть широкі винятки; виключайте лише кеші. Забезпечте сканування точок входу і перевірку артефактів у CI.

6) «Високе CPU почалося після встановлення іншого агента безпеки»

Корінь: Подвійне сканування і конфлікт драйверів фільтра файлової системи.

Виправлення: Підтвердьте, який продукт відповідає за захист у реальному часі, налаштуйте взаємні винятки згідно з політикою та уникайте одночасного запуску двох повноцінних AV-двигунів.

Жарт #2: Два антивіруси, що сканують один файл — це як два менеджери, що переглядають одну таблицю. Єдине, що гарантовано зросте — це час на наради.

Контрольні списки / покроковий план

Покроковий план для окремого ПК (15–45 хвилин)

1. Підтвердити винуватця: перевірте, що MsMpEng.exe — «гарячий» процес; повторно перевірте через 30 секунд, чи зростає CPU кумулятивно.
2. Перевірити стан сканування: перегляньте часи початку/закінчення останніх сканувань; підтвердіть, чи йде повне сканування.
3. Зіставити з активністю користувача: збірки, завантаження, запуск VM, синхронізація OneDrive, розпакування великих архівів.
4. Перевірити затримки диска: зібрати швидкий зразок довжини черги диска; вирішити, чи це обчислювальне навантаження чи трясіння накопичувача.
5. Переглянути винятки: перелічити поточні винятки; видалити надто широкі (після належного погодження).
6. Додати один вузький виняток за раз: обрати найпевніший кеш з високим обігом і виключити його; виміряти повторно.
7. Відновити здоровʼя оновлень: оновити сигнатури; підтвердити актуальність платформи; перезавантажити, якщо завдання застрягли.
8. Запланувати сканування: упевнитися, що повні сканування відбуваються у позаробочий час (або в контрольований вікно) і не атакують користувачів після входу.
9. Документувати зміну: зафіксувати, що саме виключили і чому; поставити нагадування переглянути через 30–90 днів.

Контрольний список для робочих станцій розробників (практичний і безпечний)

• Виключайте лише відтворювані кеші/вихідні збірки, а не корені репозиторіїв.
• Тримайте сканування увімкненим для Downloads і папок з вкладеннями.
• Надавайте перевагу цільовим скануванням ризикових папок замість частих повних сканувань.
• Уникайте винятків процесів, якщо не можете чітко оцінити площу ураження.
• Якщо використовуєте Docker/WSL2/VM, визначте, де має відбуватися сканування: на хості чи у гості — не в обох для одного й того ж контенту.

Контрольний список для IT/SRE команд, що керують парком

• Централізуйте політику Defender (MDM/GPO), включно з розкладами сканувань і затвердженими винятками.
• Підтримуйте каталог затверджених винятків для поширених інструментів розробки (npm, NuGet, Maven) з чітким охопленням.
• Моніторте наявність широких винятків і відхилення від політики.
• Визначте власність, якщо існує кілька агентів безпеки (Defender AV vs EDR моніторинг поведінки).
• Тестуйте великі оновлення реалістичними робочими навантаженнями розробників (шторм дрібних файлів) перед розгортанням.

Часті запитання (FAQ)

1) Чи є Antimalware Service Executable вірусом?

Зазвичай ні. Це легітимний двигун Microsoft Defender Antivirus (MsMpEng.exe). Якщо файл знаходиться поза директорією платформи Defender або має дивний підпис, тоді варто перевірити на маскування.

2) Чи можу я просто вимкнути захист в реальному часі, щоб зупинити навантаження CPU?

Можна, але не варто. Це обмін проблемою продуктивності на інцидент безпеки. Спочатку виправляйте планування, обсяг і обіг файлів; вимикайте лише за явної політики і в короткі контрольовані вікна для налагодження.

3) Чому CPU піки після оновлень Windows?

Оновлення можуть змінювати компоненти системи, сигнатури і версії платформи. Це може спричинити інвалідизацію кешів і повторні сканування, плюс фонове обслуговування, що не відбувалося, поки пристрій перезавантажувався або був офлайн.

4) Які винятки безпечні для розробників?

Безпечніші винятки — це кеші з високим обігом і згенеровані вихідні дані, що відтворюються і не є типовими точками запуску: кеші пакетів і вихідні папки збірки. Небезпечні винятки — Downloads, корені профілів користувачів або корені репозиторіїв, де виконуються скрипти.

5) Чи означає виняток папки, що Defender ніколи її не сканує?

Винятки зазвичай зменшують або припиняють сканування в реальному часі/при доступі для цього шляху, залежно від політики. Це не гарантує, що ніхто ніколи більше не торкнеться файлів (заплановані сканування або інші засоби захисту можуть застосовуватися), але вважайте цей шлях «сліпою зоною».

6) Чому на HDD високий CPU здається гіршим, ніж на SSD?

Бо сканування інтенсивно читає й працює з метаданими. HDD погано справляються з випадковими операціями вводу/виводу та роботою з дрібними файлами; черги ростуть і все чекає. SSD краще обробляють такі шаблони.

7) Я додав винятки, але CPU все ще високий — що далі?

Перевірте, чи іще виконується повне сканування, чи зашкалює довжина черги диска, і чи не виконує інший інструмент подвійне сканування. Також перевірте здоровʼя платформи/сигнатур Defender; застрягла спроба оновлення може тримати його зайнятим незалежно від винятків.

8) Чи варто виключати VHDX-файли на хості, якщо я сканую всередині VM?

Часто так в керованих середовищах, бо інакше одні й ті ж байти скануються двічі. Але це політичне рішення: потрібно впевнитися, що AV у гості здоровий, і що на хості є компенсуючі контролі для захисту ОС хоста.

9) Який найменш ризиковий «швидкий виграш», якщо мені потрібно, щоб машина була працездатною сьогодні?

Переплануйте повні сканування поза робочими годинами і додайте один вузький виняток для найбільшого відомого кешу з високим обігом. Потім вимірюйте. Не додавайте широкі шляхи в паніці.

Висновок: практичні наступні кроки

Якщо Defender «спалює» CPU, зазвичай він робить щось раціональне в ірраціональному середовищі — наприклад, сканує 400 000 дрібних файлів, створених інструментами. Ваше завдання — зробити цю роботу обмеженою й передбачуваною, не перетворюючи безпеку на факультативний атрибут.

Зробіть наступне:

1. Підтвердити, чи йде повне або надолужувальне сканування (стан + журнал операцій).
2. Перевірити, чи система насправді обмежена сховищем (довжина черги диска).
3. Виправити планування сканувань, щоб вони не підкрадалися до користувачів.
4. Додати вузькі, обґрунтовані винятки для кешів з високим обігом і згенерованих виходів.
5. Оновити сигнатури/платформу Defender і перевірити стан.
6. Якщо у вас кероване середовище, запровадити зміни через політику, щоб вони залишилися стабільними.

Тримайте Defender увімкненим. Зробіть його дешевшим. Спіть спокійніше.