Fix High CPU by Antimalware Service Executable (Win 11)
Your fans spin up out of nowhere. Task Manager shows Antimalware Service Executable sitting at 30-60% CPU, sometimes higher, and it won't let go. You didn't open anything heavy. You definitely didn't ask for this. This is one of the most common "why is my CPU pegged" tickets in Windows 11, and the fix depends entirely on which of three or four things is actually happening on your machine — so before you touch a single setting, spend two minutes confirming which one you've got.
Antimalware Service Executable is the process name for MsMpEng.exe, the scanning engine behind Microsoft Defender Antivirus, the antivirus built into every copy of Windows 11. It runs constantly by design. A spike to 100% for a minute or two during a scan is normal. A spike that sits there for ten, twenty, sixty minutes with no scan visibly running is not, and that's the version of this problem this article is for.
What does high CPU from Antimalware Service Executable actually mean?
In plain terms: Defender's real-time protection engine is doing more scanning work than your CPU can absorb quietly. That happens for one of four reasons, roughly in order of how often I run into them — a scheduled or on-demand scan is legitimately running; real-time protection is re-scanning the same files repeatedly because something (a build tool, a game launcher, a sync client, a VM) keeps touching them; Defender is processing a corrupted or half-applied security intelligence update; or, less often, a second antivirus is fighting with Defender over the same files. There's a fifth possibility worth naming honestly: actual malware posing as the process. It's rare, but it's the one check you do first because everything else assumes you're dealing with the real MsMpEng.exe.
Real Antimalware Service Executable runs fromC:\Program Files\Windows Defender\MsMpEng.exe(or theWindowsApps-based path on newer builds) and is owned by SYSTEM. Right-click the process in Task Manager, choose Open file location, and confirm it points into that folder. If it launches from anywhere else — Temp, a user profile folder, Downloads — stop here and run a full offline scan; that's not Defender.
Symptom, confirming check, and fix — the quick map
| What you're seeing | How to confirm it | Fix |
|---|---|---|
| Spike lasts under 15-20 minutes, then drops on its own | Task Scheduler shows Windows Defender Scheduled Scan as Running, or you just installed/updated something | Nothing needed — let it finish, or reschedule the scan |
| Spike is constant, no scan visible, coincides with a specific app (IDE, game launcher, backup client) | Process Monitor shows MsMpEng.exe repeatedly touching the same folder that app writes to | Targeted exclusion for that folder/process only |
| Started right after a Windows or definition update, otherwise idle machine | Get-MpComputerStatus shows an old or mismatched AntivirusSignatureVersion, or Defender's own update history shows failures | Force a clean signature update |
| You have a second antivirus installed (Avast, Norton, McAfee, Bitdefender, etc.) | Both products show up in Task Manager and Windows Security shows Defender as "off" but MsMpEng.exe is still hammering CPU | Fully uninstall one product using its vendor removal tool — don't run two real-time engines |
| Process runs from outside Program Files, or two processes share the name | Right-click → Open file location doesn't point to the Windows Defender folder | Stop, don't apply any fix below — run a full malware scan first |
How do I confirm a scan is actually running?
Open Task Scheduler (taskschd.msc), then navigate to Task Scheduler Library > Microsoft > Windows > Windows Defender, and check whether Windows Defender Scheduled Scan shows a status of Running. If it does, and CPU usage matches the timing, you don't have a bug — you have a full scan doing exactly what it's supposed to. The honest fix here isn't a registry tweak, it's rescheduling the scan to a time you're not sitting at the keyboard. Right-click the task, choose Properties, go to Triggers, and set a new daily trigger for something like 3 a.m. On the Conditions tab, leaving "Start the task only if the computer is idle" checked will stop it from firing mid-session even if your schedule slips.
I've had people skip this check and go straight to disabling real-time protection because "it's obviously broken" — then get hit by something nasty three days later because Defender was doing exactly its job the whole time. Confirm before you disable anything.
Isolating a repeated re-scan loop with Process Monitor
If there's no scan running and the CPU stays high anyway, the next step is finding out what MsMpEng.exe keeps scanning. Download Process Monitor (ProcMon) from Microsoft's Sysinternals site, run it as administrator, and let it capture for about five minutes while the spike is happening. Filter the process column for MsMpEng.exe and look at the Path column — if you see the same directory appear hundreds or thousands of times, that's your loop. This is extremely common with build directories (node_modules, .git, target/), Steam or Xbox game folders during downloads, Docker Desktop's WSL2 virtual disk, and Hyper-V or VMware VM files, since each of those generates constant file writes that real-time protection has to inspect.
Once you know the folder, add a targeted exclusion — not a blanket "disable everything" fix. Open an elevated PowerShell prompt and run:
Set-MpPreference -ExclusionPath "C:\Users\YourName\source\repos"
Set-MpPreference -ExclusionProcess "C:\Program Files\Docker\Docker\resources\dockerd.exe"You can list current exclusions with Get-MpPreference | Select-Object -ExpandProperty ExclusionPath to confirm they took. The same thing is available through the GUI at Windows Security > Virus & threat protection > Manage settings > Add or remove exclusions, if you'd rather not touch PowerShell. Either way, exclude the narrowest path that solves the problem — excluding your entire user profile "just in case" defeats the point of having real-time protection at all.
Why would this happen right after an update?
Defender pulls new security intelligence (virus definition) updates multiple times a day, and Antimalware Service Executable does a burst of extra work reprocessing its detection database whenever that happens. Normally this is quick. Occasionally an update lands half-applied — a flaky connection, a forced reboot mid-download — and Defender gets stuck retrying the same update cycle, which shows up as sustained high CPU with no obvious scan running. You can check your current signature state with:
Get-MpComputerStatus | Select-Object AntivirusSignatureVersion, AntivirusSignatureLastUpdatedIf the last-updated timestamp is stale or clearly out of sync with today's date, force a clean update from an elevated Command Prompt:
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdateIf that fails or the process is still stuck afterward, remove the current definitions and pull them fresh — this is the Microsoft-documented recovery path for a corrupted signature set, not a workaround someone made up:
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -RemoveDefinitions -All
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdateGive it a few minutes, then recheck Task Manager. In my experience this clears the vast majority of "started right after Patch Tuesday and never calmed down" cases, because it forces Defender to stop retrying whatever broke and start clean.
What if I have another antivirus installed too?
Windows only fully disables Defender's real-time engine when it detects another registered antivirus product taking over that role — and even then, MsMpEng.exe stays resident and can still get invoked for scheduled or on-demand scans, plus some background telemetry. Running two real-time engines side by side, even if one is "mostly off," routinely causes exactly this symptom: both products fighting over file locks on the same files. If you're intentionally running third-party AV, the fix isn't an exclusion, it's picking one. Uninstall the other using the vendor's dedicated removal tool (Norton, McAfee, and Avast all publish standalone removal utilities because a normal uninstall often leaves driver remnants behind), reboot, and confirm in Windows Security that Defender's real-time protection is either fully active or fully and intentionally handed off to the other product with no leftover services running.
Does adding an exclusion for MsMpEng.exe itself help?
No — and you'll see this suggested constantly. Excluding Defender's own executable from Defender's own scanning doesn't reduce its CPU usage; the engine's CPU load comes from the files it's inspecting, not from scanning itself. At best this does nothing. At worst it's one more entry that could theoretically be abused if malware ever managed to plant a file at that exact path. Skip it.
My exclusion isn't sticking — what's going on?
If you add an exclusion through PowerShell and it disappears, or the GUI won't let you save it, the most likely explanation is Tamper Protection. It's on by default in Windows 11 and it deliberately blocks changes to Defender's security settings — including exclusions — made outside the Windows Security app, specifically to stop malware from whitelisting itself. Check its state with Get-MpComputerStatus | Select-Object IsTamperProtected. If it comes back true and you're trying to set exclusions from PowerShell, add them through Windows Security > Virus & threat protection > Manage settings > Add or remove exclusions instead, where Tamper Protection allows the change through the intended UI path. Don't turn Tamper Protection off just to make a script work; that's solving a two-minute inconvenience by removing a real security control.
A second reason exclusions don't stick: on a managed work laptop, your organization's Intune or Group Policy configuration may push its own exclusion list on a schedule, overwriting anything you set locally. There's no local fix for that — it needs to go through whoever manages the device, since local changes to a centrally managed policy get reverted on the next sync by design.
Ruling out a hardware explanation
Every so often what looks like Defender is actually a laptop thermal-throttling under a completely unrelated load, with MsMpEng.exe simply being the most visible process in Task Manager at the moment you looked. Before you spend an hour chasing exclusions, sort Task Manager's Details tab by CPU and watch it for thirty seconds — if the percentage attributed to Antimalware Service Executable jumps around erratically alongside other processes rather than holding a steady, sustained number, you may be looking at general system load rather than a Defender-specific issue. Check Task Manager's Performance tab for CPU temperature-adjacent clues (clock speed dropping under load is a giveaway on supported CPUs) or run powercfg /energy for a broader diagnostic report. This matters because the fix is completely different: cleaning dust from vents and reapplying thermal paste solves a heat problem; PowerShell exclusions do nothing for one.
One more pattern worth knowing: Defender's Potentially Unwanted Application (PUA) protection and cloud-delivered protection features can both add extra scanning overhead on systems with a lot of small files being written quickly — think node_modules-heavy JavaScript projects or Python virtual environments with thousands of tiny package files. This isn't a bug, it's cloud lookups taking longer than a purely local signature check would, and it's a good candidate for the targeted exclusion approach above rather than anything more drastic.
What I would not do
- Permanently disable real-time protection via Group Policy or the registry (DisableAntiSpyware). This leaves the machine with no active malware protection at all unless you've deployed a fully managed alternative, and Microsoft doesn't support running Windows with no antivirus engaged. It also doesn't fix the underlying cause — it just hides the symptom while removing your safety net.
- Set the process affinity to one CPU core. I've seen this suggested repeatedly. It doesn't reduce total work done, it just concentrates the same load onto a smaller slice of your CPU, which usually makes the stall feel worse, not better.
- Kill the process in Task Manager. You'll get Access Denied, or Windows will silently relaunch it within seconds, because it's a protected system process. It wastes time and teaches you nothing about the actual cause.
- Reinstall Windows because "Defender is broken." This is a last resort for corruption that SFC, DISM, and a clean signature reset can't touch, and in practice that's rare for this specific symptom.
- Exclude your entire C: drive "to be safe." That's not an exclusion, that's turning Defender off with extra steps, and it defeats the point of running it at all.
When none of this works
If you've ruled out an active scan, confirmed the process is genuine, added exclusions for anything ProcMon flagged as a repeat offender, forced a clean signature update, and you're still seeing sustained 30%+ usage with no clear trigger — check for Group Policy or Intune-managed Defender settings if this is a work machine, since a managed CPU throttle policy (Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Scan > "Specify the maximum percentage of CPU usage during a scan") set too high or absent entirely can push scan-related load higher than expected. On an unmanaged home PC, run sfc /scannow followed by DISM /Online /Cleanup-Image /RestoreHealth to rule out corrupted system files feeding bad data into Defender's scanning logic, then a full offline scan (Windows Security > Virus & threat protection > Scan options > Microsoft Defender Antivirus (offline scan)) to rule out something actively working to look like Defender. Microsoft's own troubleshooting mode and Process Monitor guidance for exactly this scenario is documented at Troubleshooting mode scenarios in Microsoft Defender for Endpoint, which is worth a read if you manage more than one machine and want the enterprise-grade version of this same workflow.
Quick checklist before you close this tab
- Confirmed the process path is genuinely Windows Defender's, not a lookalike
- Checked Task Scheduler for an active scheduled scan before touching any settings
- Captured five minutes of Process Monitor if the spike has no obvious trigger
- Added narrow, specific exclusions only for folders/processes ProcMon actually flagged
- Forced a signature update (and reset if needed) if this started right after Patch Tuesday
- Verified you're running exactly one real-time antivirus engine, not two
- Ran
sfc /scannowand DISM only if the above didn't resolve it