Defender CPU Problembehandlung & Optimierung

Defender Hohe CPU-Auslastung – Problembehandlung & Optimierung

Welches Problem löst dieses Skill?

Auf Windows-Entwicklungsrechnern scannt der Echtzeitschutz von Microsoft Defender jeden Dateizugriff. Wenn ein Prozess viele Dateien liest (IDEA-Indizierung, Codex-Projektdurchsuchung, find /-Festplatten-Scan, Maven-Abhängigkeiten, WSL/Docker interner I/O), wird Defender zu einer nie endenden Scan-Pipeline – MsMpEng.exe CPU steigt auf 50%+, der gesamte Rechner ruckelt.

Die Kern-Erkenntnis ist: Hohe CPU durch Defender ist fast nie ein Defekt von Defender, sondern ein I/O-intensiver Prozess, der ständig den Echtzeitschutz auslöst. Daher liegt der Schlüssel nicht darin, Defender-Parameter zu ändern, sondern den Auslöser zu identifizieren und ihn mit präzisen Ausschlüssen aus dem Scan-Pfad zu entfernen – so wird das Ruckeln beseitigt, ohne die gesamte Sicherheitslage zu gefährden.

Vorgehen bei der Fehlersuche

Schritt 0: Bestätigen, ob es Defender ist und den richtigen CPU-Wert ermitteln

Die CPU-Spalte im Task-Manager und der Leistungsindikator \Process(*)\% Processor Time haben unterschiedliche Maßstäbe: Der Zähler kann auf Mehrkern-Rechnern über 100% pro Prozess liegen (100% pro Kern summiert), der Task-Manager teilt diesen Wert durch die Anzahl der Kerne. Daher können 61,2% im Task-Manager 766% im Zähler entsprechen (20-Kern-Rechner). Beide Werte sind korrekt, ziehen Sie nicht die falschen Schlüsse.

Schnelle Bestätigung der tatsächlichen MsMpEng-Auslastung (Task-Manager-Maßstab):

$cores = $env:NUMBER_OF_PROCESSORS
$c = (Get-Counter '\Process(MsMpEng*)\% Processor Time').CounterSamples | Where-Object { $_.InstanceName -like 'msmpeng*' } | Select-Object -First 1
"MsMpEng: Zähler=$([math]::Round($c.CookedValue,1))%  Äquivalent Task-Manager=$([math]::Round($c.CookedValue/$cores,1))%  (Rechner $cores Kerne)"

Wenn der Task-Manager einen hohen Wert anzeigt, der Zähler aber konstant 0 ist, handelt es sich um einen veralteten Anzeigewert – Task-Manager einfach neu starten, nicht an Defender herumstellen.

Schritt 1: Identifizieren des Auslösers (durch Korrelation, nicht Bauchgefühl)

Hohe Defender-CPU hat drei Hauptursachen, die unterschiedlich identifiziert werden:

Ursache	Merkmal	Wie bestätigen
Echtzeitschutz wird durch externen Prozess ausgelöst (häufigster Fall)	MsMpEng CPU pulsiert, externer Prozess hat gleichzeitig hohen I/O	Kontinuierlich messen: Finde den Prozess, dessen I/O steigt, wenn MsMpEng hochgeht
Geplanter/Hintergrund-Scan	CPU konstant hoch, geringe Schwankung; ScanRunning hat einen Wert oder geplante Tasks laufen	Get-MpComputerStatus auf ScanRunning prüfen; Get-ScheduledTask -TaskPath '\Microsoft\Windows\Windows Defender\*'
Defender-interne Hintergrundaufgaben (Definition-Update-Prüfung, Cloud-Sampling etc.)	MsMpEng hat selbst den höchsten Read-I/O, kein externer hoher I/O-Prozess	Messen: Liegt der I/O von MsMpEng weit über dem anderer Prozesse?

Schlüssel-Diagnose: Führen Sie scripts/diag-mpcpu.ps1 aus. Es misst über einige Sekunden kontinuierlich die MsMpEng-CPU sowie die IO Data Bytes/sec aller Prozesse. Interpretation:

• Wenn der I/O eines Prozesses steigt und gleichzeitig MsMpEng hochgeht → dieser Prozess ist der Auslöser, gehen Sie zu Schritt 2 für die Ursachenbehebung
• Wenn MsMpEng selbst den höchsten Read hat, kein externer hoher I/O → gehen Sie zu Schritt 3 (Hintergrund-Scan/-Task)
• Wenn MsMpEng durchgehend nahe 0 ist → Das Problem liegt nicht mehr an Defender, suchen Sie woanders (der Benutzer sieht eventuell veraltete Werte im Task-Manager)

Schritt 2: Ursachenbehebung – Ausschluss für den Auslöser hinzufügen

Es gibt zwei Arten von Ausschlüssen, deren Unterschied Sie verstehen sollten:

• Prozessausschluss (ExclusionProcess): Gibt den Prozessnamen an (z. B. idea64.exe). Dieser Prozess löst beim Lesen einer Datei keinen Scan aus, aber die Datei wird gescannt, wenn ein anderer Prozess darauf zugreift. Präzise, sicher, bevorzugt verwenden.
• Pfadausschluss (ExclusionPath): Gibt ein Verzeichnis an. Jeder Prozess (auch Browser, EDR) greift auf Dateien in diesem Verzeichnis zu, ohne dass sie gescannt werden. Geeignet für Cache-/Virtuell-Disk-Ordner, die „nur Daten enthalten und von niemandem gescannt werden sollten“; nicht für Projektquellcode-Verzeichnisse verwenden – diese sollten durch Prozessausschluss geschützt werden (nur das Entwicklungswerkzeug selbst liest ohne Scan, Browser-Downloads in das gleiche Verzeichnis werden weiterhin gescannt). Aus diesem Grund generiert gen-exclusions.ps1 auch nur Pfade für Cache/Virtuell-Disk/Installationsroot und niemals automatisch Projektverzeichnisse.

Warum Prozessausschluss bevorzugt wird: Ein Pfadausschluss deaktiviert den Echtzeitschutz für alle Prozesse in diesem Verzeichnis; ein Prozessausschluss deaktiviert ihn nur für ein bestimmtes Werkzeug – die Angriffsfläche ist viel kleiner. Wenn Sie z. B. den Prozess codex.exe ausschließen, wird Codex beim Lesen Ihrer Projektdateien nicht mehr gescannt, aber ein Browser-Download in dasselbe Verzeichnis wird weiterhin gescannt – genau das ist gewünscht.

Führen Sie das Skript scripts/gen-exclusions.ps1 aus – es scannt laufende Entwicklerprozesse, gleicht sie mit bekannten Tool-Mustern ab und generiert automatisch empfohlene Prozess- und Pfadausschlüsse. Standardmäßig im DryRun-Modus (zeigt Vorschläge mit Begründung an). Nach Bestätigung mit -Apply werden sie in Defender geschrieben. Es ist idempotent und sichert vor dem Schreiben die aktuellen Ausschlüsse.

Schritt 3: Behandlung von Hintergrund-Scans

Wenn ein geplanter Scan / automatische Wartung läuft (ScanRunning hat einen Wert, geplanter Task State=Running), sollte er in der Regel einfach zu Ende laufen – nicht gewaltsam beenden. Defender erledigt hier notwendige Sicherheitswartung. Wenn es zu ungünstigen Zeiten wiederholt startet, passen Sie den Zeitplan an:

# Geplante Scans anzeigen
Get-ScheduledTask -TaskPath '\Microsoft\Windows\Windows Defender\*'
# Schnellscan-Zeit anpassen (Beispiel: jeden Morgen um 3 Uhr) – überschreibt die vorhandene Konfiguration
Set-MpPreference -ScanScheduleQuickScanTime 03:00:00

Wenn eine vollständige Überprüfung nach einem Definitions-Update gelegentlich stattfindet, läuft sie in der Regel einmalig durch.

Schritt 4: Validierung

Nachdem die Ausschlüsse hinzugefügt wurden, lösen Sie die ursprüngliche hohe I/O-Last erneut aus (IDE neu indizieren, find erneut ausführen, Codex das Projekt scannen lassen) und führen Sie diag-mpcpu.ps1 erneut aus. Das Erfolgskriterium: Bei gleicher I/O-Last sinkt MsMpEng von seinem vorherigen hohen Wert auf nahe 0. Wenn nicht, haben die Ausschlüsse den eigentlichen Auslöser nicht erfasst – gehen Sie zurück zu Schritt 1 und prüfen Sie im diag-Output, welcher Prozess weiterhin gleichzeitig hochgeht.

Sicherheitsgrenzen – Diese dürfen niemals ausgeschlossen werden

Ausschlüsse reduzieren den Echtzeitschutz für den entsprechenden Pfad/Prozess – daher gibt es strikte Grenzen. Folgende Elemente dürfen niemals ausgeschlossen werden, egal wie viel „CPU sparen“ sie versprechen (die vollständige und autoritative Liste finden Sie in scripts/gen-exclusions.ps1 unter $denyProcs und $denyPathPrefix; diese Dokumentation ist nur zur Erläuterung):

• Systemprozesse: svchost.exe, dllhost.exe, smartscreen.exe, conhost.exe, lsass.exe, csrss.exe usw.
• Browser und deren WebView: msedge.exe, chrome.exe, msedgewebview2.exe – Browser-Downloads sind die Hauptquelle für Malware, daher muss der Scan erhalten bleiben
• Sicherheits-/Verwaltungsclients: EDR, VPN-Clients, die vom Unternehmen installiert wurden (z. B. Sangfor ECAgent, CrowdStrike, SentinelOne) – diese zu ändern könnte Compliance-Warnungen auslösen und ist Teil der Sicherheitskette
• Gesamtes Benutzerverzeichnis / Systemlaufwerksstamm: Zu grobkörnig – das wäre wie ohne Schutz zu arbeiten
• Ausführbare Datei-Erweiterungen wie *.jar, *.exe, *.dll, *.ps1: Ausführbare Dateien müssen gescannt werden. Erweiterungsausschlüsse sind nur für reine Build-Artefakte (*.class) oder Logs (*.log) sinnvoll, die nicht ausführbar sind

Entscheidungsprinzip: Ausschlüsse sollten auf „vertrauenswürdige Entwicklerwerkzeuge abzielen, die beim Ausführen ihrer normalen Arbeit Dateien lesen“ – nicht auf „ausschließen, was immer möglich ist, um CPU zu sparen“.

Erweiterte Diagnose: Performance Recorder

Wenn das diag-Skript die Ursache nicht genau eingrenzen kann, verwenden Sie den offiziellen Defender-Performance-Recorder (benötigt Administratorrechte). Er erstellt einen genauen Bericht, auf welche Pfade/Prozesse MsMpEng die meiste Zeit verwendet:

New-MpPerformanceRecord -RecordTo C:\perf.mpdr   # 60 Sekunden sammeln (währenddessen die hohe CPU reproduzieren)
# Der Bericht zeigt die CPU-intensivsten Pfade und Prozesse – darauf basierend präzise Ausschlüsse hinzufügen

Referenzdateien

• references/common-exclusions.md – Empfohlene Ausschlusskategorien für gängige Entwicklungswerkzeuge (IDE/Java/Node/WSL/Docker/AI-Assistenten/Build-Caches), mit Sicherheitskompromiss-Hinweisen pro Kategorie. Wird bei der Generierung von Ausschlüssen zur Überprüfung der Abdeckung verwendet.
• scripts/diag-mpcpu.ps1 – Diagnose-Sampling-Skript
• scripts/gen-exclusions.ps1 – Automatische Generierung und Anwendung von Ausschlüssen (Standard: Vorschau)