Forum Discussion
philippwree
Jul 09, 2020Copper Contributor
Limit Windows Defender CPU Usage
I have the problem that our Clients use too much CPU during a FullScan. Actually, the usage is limited to 20%, but the setting seems to have no effect. Whether I set it via Configuration Manager or G...
MAlv68
May 05, 2021Copper Contributor
I also have the same issue. I understand that the value set in -ScanAvgCPULoadFactor is not a "hard value" but is used as an average for the duration of the scan. (-ScanAvgCPULoadFactor Specifies the maximum percentage CPU usage for a scan. The acceptable values for this parameter are: integers from 5 through 100, and the value 0, which disables CPU throttling. Windows Defender does not exceed the percentage of CPU usage that you specify. The default value is 50.
Note: This is not a hard limit but rather a guidance for the scanning engine to not exceed this maximum on average.)
However, when the process utilizes 90% and above for several minutes, I find it hard to believe that the average will fall below my customized threshold of 30%. Is there a performance log that can be checked after a scan completes?
Thanks!
Note: This is not a hard limit but rather a guidance for the scanning engine to not exceed this maximum on average.)
However, when the process utilizes 90% and above for several minutes, I find it hard to believe that the average will fall below my customized threshold of 30%. Is there a performance log that can be checked after a scan completes?
Thanks!
AJP_UK
May 05, 2021Brass Contributor
MAlv68 I had a ticket open with Microsoft support for months about this but didn't get anywhere. The one useful comment was that a manually run scan will ignore any CPU limits like ScanAvgCPULoadFactor.
- Diego_AmorimOct 14, 2024Copper Contributor
I found a way to bypass this and finally fix the issue of high CPU utilisation on Defender for both manual and scheduled scans. I'll go through it step by step below for those who need it:
1. Open command prompt (search CMD in the search bar) and run as admin.
2. Type:
gpedit
and hit enter to open the local group policy editor. (If you have Windows Home Edition which does not have local group policy editor, follow this guide first to install it:
https://www.howtogeek.com/cannot-find-gpedit-msc-on-windows-11/
3. Go to: Computer Configuration/Administrative Templates/Windows Components/Microsoft Defender Antivirus/Scan.
4. On the right, double-click on the "Specify the maximum percentage of CPU utilization during a scan" policy.
5. Enable this policy and under Options, enter the desired CPU percentage limit.
6. Below, double-click on the "Configure local setting override for maximum percentage of CPU utilization" policy, and enable it (Not 100% sure how necessary this step is but it works for me).
7. Below that, double-click on the "Configure low CPU priority for scheduled scans" policy, and enable it.
8. Below that, double-click on the "CPU throttling type" policy and disable it (very important if you also want your manual scans throttled).
And that's that, let me know if it works for you guys, for me it worked mid scan and saw CPU usage drop from 70% to under my specified 30% value after initiating a manual full scan. - rahul_malgunFeb 19, 2024Copper Contributor
Hello is there any fix for the windows server 2016 , high cpu utilization as we are still facing the issue. antimalware service executable is taking more than 80 % for our production environment
- Rob NicholsonAug 07, 2021Brass Contributor>The one useful comment was that a manually run scan will ignore any CPU limits like ScanAvgCPULoadFactor.
I concur with this. I run a full scan of my client's file server manually each month. Normally do it over the weekend because despite having this value set to 10, a full scan flatlines the dual vCPU cores for about 30 hours.
This needs fixing! - AJP_UKMay 05, 2021Brass ContributorI've posted a change to the Microsoft Docs on this, hopefully they will confirm whether the Microsoft Support Expert was right. Very hard to test changes against scheduled full scans though.