SCCM 2012 Agent and high CPU utilization.
We have numerous Windows workstations and servers running with very high CPU utilization. Services are slow to start and login can take an hour. The service running with high CPU is svchost.exe, we determined that it is Windows Management Instrumentation
that is causing high CPU in svchost.exe.
If we stop or uninstall the SCCM 2012 Agent, everything calms down on the computer.
Any ideas as to way this would be?
August 21st, 2012 6:40pm
A shot in the dark :-D
Have you reviewed client log files? Have you enabled software inventory ?
August 21st, 2012 6:58pm
Software inventory is not enabled.
Nothing stands out in the logs; however, is there log I should give more attention to?
I do not know if it is related, I am find a large file named corrupted.rec in C:\Windows\System32\wbem\repository
August 21st, 2012 7:49pm
As it turns out software inventory was enabled, I have now disabled software inventory. However, Windows Management Instrumentation continues to run with high CPU utilization.
The only way we have found to fix this, is to uninstall the Configuration Manager 2012 agent.
We have come to the belief that there must be a bug in the Configuration Manager 2012 agent.
August 24th, 2012 7:27pm
If that is your belief and you have evidence, please contact CSS so that they can review and coordinate a fix.
August 24th, 2012 8:58pm
We take client performance seriously and try to engineer the client to be as minimally impacting on system performance as possible. Even features that are naturally more demanding such as software inventory are designed to "back off" when someone is active
on the workstation to prevent impacting the user's experience.
If you're observing what you believe to be a performance bug in the client, I echo Jason's sentiment to please involve CSS to troubleshoot the issue to determine if it's a product bug or not.
August 24th, 2012 9:24pm
We have the exact same issue here! Please let us know if you found a fix for this!
August 27th, 2012 11:04am
The please call CSS. The more evidence and information that they have about the issue the more they can do about it. Who's to say that your issue is even caused by the same thing? The best way that you can be helped is to call them and let them help you.
Note that if it is truly a bug or some issue not your fault, you are typically not charged for the call.
August 27th, 2012 4:27pm
Our contract does not include support. We are hoping someone else found and solved this issue.
August 28th, 2012 8:08pm
As mentioned, if its a bug, you will not get charged. Also, CSS charges on a per-incident basis -- $250 I think -- which is pretty small if you are having issues that aren't the result of a bug. Compared to the amount of time you've probably already wasted
troubleshooting this and the amount you've spent on the software, that's pretty small.
August 28th, 2012 10:17pm
Hi, has there been any update on this issue?
I have the same problem in our SCCM environment. If I uninstall or disable the sccm client the problem goes away but starts again when the client is reinstalled.
- Edited by
FreyrGauti
Thursday, September 20, 2012 11:01 AM
September 20th, 2012 2:01pm
Hi, has there been any update on this issue?
I have the same problem in our SCCM environment. If I uninstall or disable the sccm client the problem goes away but starts again when the client is reinstalled.
-
Edited by
FreyrGauti
Thursday, September 20, 2012 11:01 AM
September 20th, 2012 2:01pm
Hi !
Does anyone has found any solution for the svchost process increasing bug ? I have the same probleme on 60 clients, which do not bug in the time (2 clients by day).
I've tried to kill the process, reboot the clients, modify the client settings with excluding Hardware inventory and software inventory...no change ! :-(
We have installed SCCM 2012 version 5.0.7711.0
Thks
September 27th, 2012 11:46am
As it turns out this is caused by expired updates, in software update deployments. Mostly, it is caused by expired definition updates for Endpoint Protection. Expired updates make WBEM run wild and unstable.
To stop this, remove all software update deployments especially those for Endpoint Protection; the WBEM should calm down in an hour or so. If the WBEM repository is corrupt, it may take hours for WBEM to calm down. WBEM needs to detect the corruption and
run a repair. Deleting the WBEM repository should be avoided.
WBEM is a subcomponent of WMI, which in turn is contained in svchost.exe.
We currently have Endpoint Protection updating directly from Microsoft Windows Update.
Our software update deployments are free of any expired or superseded updates. Computer a now running correctly.
I hope this help you.
- Proposed as answer by
Torsten [MVP]MVP, Moderator
Thursday, September 27, 2012 6:31 PM
- Marked as answer by
Joyce Wang [MSFT]Microsoft employee, Moderator
Monday, October 29, 2012 8:43 PM
September 27th, 2012 6:56pm
As it turns out this is caused by expired updates, in software update deployments. Mostly, it is caused by expired definition updates for Endpoint Protection. Expired updates make WBEM run wild and unstable.
To stop this, remove all software update deployments especially those for Endpoint Protection; the WBEM should calm down in an hour or so. If the WBEM repository is corrupt, it may take hours for WBEM to calm down. WBEM needs to detect the corruption and
run a repair. Deleting the WBEM repository should be avoided.
WBEM is a subcomponent of WMI, which in turn is contained in svchost.exe.
We currently have Endpoint Protection updating directly from Microsoft Windows Update.
Our software update deployments are free of any expired or superseded updates. Computer a now running correctly.
I hope this help you.
-
Proposed as answer by
Torsten [MVP]MVP, Moderator
Thursday, September 27, 2012 6:31 PM
-
Marked as answer by
Joyce Wang [MSFT]Microsoft employee, Moderator
Monday, October 29, 2012 8:43 PM
September 27th, 2012 6:56pm
As it turns out this is caused by expired updates, in software update deployments. Mostly, it is caused by expired definition updates for Endpoint Protection. Expired updates make WBEM run wild and unstable.
To stop this, remove all software update deployments especially those for Endpoint Protection; the WBEM should calm down in an hour or so. If the WBEM repository is corrupt, it may take hours for WBEM to calm down. WBEM needs to detect the corruption and
run a repair. Deleting the WBEM repository should be avoided.
WBEM is a subcomponent of WMI, which in turn is contained in svchost.exe.
We currently have Endpoint Protection updating directly from Microsoft Windows Update.
Our software update deployments are free of any expired or superseded updates. Computer a now running correctly.
I hope this help you.
So have you quit using sccm for update services completely, or just for EP updates?
Is the update management in sccm flawed?
Also, how did you clean up outdated updates, did you delete the software update groups?
Thanks in advance,
Freyr
September 28th, 2012 5:18pm
We only quit using SCCM for updating endpoint protection.
I cleaned up old updates by editing the membership of software update groups and deleting the old updates from the deployment package.
Microsoft support says this is not a flaw, something about a new feature in SCCM 2012. I am waiting for more information from Microsoft, on this feature and how to avoid the WBEM issue. I then intend to begin using SCCM for EP updates again.
September 28th, 2012 8:40pm
we faced same problem
100 % cpu utilization, if stop SMS agent host - all ok
yesterday ill try to clean all expired FEP updates and its help me
seems like a MS bug
October 5th, 2012 9:44am
We are receiving the same issue, i have now changed Endpoint protection to use updates via a UNC path rather than config manager, but still having the same issue!! SVChost running at 50 to 60 % and wmiprvc.exe running at high CPU. When i rebuild the wmi
it seems to solve the issue for a while but then after a couple of days it comes back! I have logged a call with Microsoft but they seem to be struggling to find resolution.
October 18th, 2012 3:09pm
We ran into basically the same thing, and the answer is: you better install those wmi hotfixes.
If you hit whatever conditions that cause WMI to start becoming corrupt, the SCCM client with drastically accelerate the speed of that corruption because it makes heavy use of the wmi repository. All kinds of things will go wrong when the WMI repository
gets screwed up, from Group Policy processing to slow performance. APPLY WMI HOTFIXES AVAILABLE FOR YOUR AFFECTED WINDOWS CLIENTS AND SERVERS.
If you are lucky enough to catch this before WMI totally kicks the bucket, you can use SCCM itself to push out the hotfixes (I used a powershell script) and prevent disaster.
list of hotfixes for Windows OS: http://support.microsoft.com/kb/2591403
Powershell sample to deploy hotfixes (all the hotfixes you want applied need to be in the same directory, and content has to get downloaded to the client):
$updates = gci .\*.msu
ForEach ($update in $updates) {
wusa $update.FullName /quiet /norestart
While (Get-Process wusa*) { Start-Sleep -Seconds 1 }
}
October 19th, 2012 6:50pm
We only quit using SCCM for updating endpoint protection.
I cleaned up old updates by editing the membership of software update groups and deleting the old updates from the deployment package.
Microsoft support says this is not a flaw, something about a new feature in SCCM 2012. I am waiting for more information from Microsoft, on this feature and how to avoid the WBEM issue. I then intend to begin using SCCM for EP updates again.
This link is apparently the information that was promised.
http://blogs.technet.com/b/configmgrteam/archive/2012/04/12/software-update-content-cleanup-in-system-center-2012-configuration-manager.aspx
I am somewhat disappointed.
October 24th, 2012 4:05am
Just because you don't have a support contract doesn't mean you can't contact support. If it turns out to be a bug, you will not be charged.
October 24th, 2012 6:05am
Thank you for this. We just got hit with this today and it nearly crippled our vSphere with all the CPU and disk utilization. This hotfix appears to have addressed the issue.
October 30th, 2012 10:22pm
This may help clear the WMI issues....similar issue to what I had which caused numerous other problems...
http://itguru82-sccm.blogspot.co.uk/2012/10/welcome-screen-hanging-cannot-run.html
November 22nd, 2012 6:21pm
okay I had this issue and I figured out how to fix it for the desktop users and I am still trying to figure out how to fix it via the server.
Win7 Desktop Fix
1) sc config winmgmt start= disabled
This will disable Windows Management Instrumentation service
2) shutdown /r /t 1
reboot
3) Install Windows6.1-KB2617858-x64.msu (and Windows6.1-KB2492536-x64.msu & Windows6.1-KB2705357-v2-x64.msu for good measure) might need to reboot
4) sc config winmgmt start= auto
net start winmgmt /y
starts Windows Management Instrumentation service, svchost might ramp up again
5) cd %windir%\system32\wbem
FOR /f %s in ('dir /b *.mof *.mfl') do mofcomp %s
Repairs WMI, it might take some time to kick in but if it sits there for a very long time, it did not work.
If all is good svchost should be back to normal.
January 11th, 2013 1:41am
Hi
We are having similar issue with SCCM 2012 R2 infrastructure and CPU utilization is hitting 100% on WIN8 and WIN 8.1 clients after we enabled SCEP. Is this is a know issue or a bug?
February 18th, 2014 11:25pm
In a specific situation that we had, we were able to narrow it down to a specific third party application that we were pushing. There is a powershell tool: poshcat:
http://blog.coretech.dk/kaj/how-to-install-poshcat/ that was very helpful in speeding up the debugging time. Running the Application Machine Policy Cycle is what would start the processes that
would eventually lead to a high CPU rate.
August 27th, 2014 1:49am
How many updates are we looking at? We have 92, but we've got 3500 machines. Is this too many?
Thanks
Jack
February 23rd, 2015 12:27pm
Same issue seen on a clients and KB2617858 resolves it. I am deploying using the App model no problem with x86 and x64 hotfixes with requisite OS requirements. Is there a way to configure to only apply to those that it applies to...if that makes sense. I
ask because my B&C x64 W7Sp1 image does not require it (I have not included it) whereas other non-B&C do - what's the condition or applicability (or non-applicability) if not as listed on the KB..! If I run it one W7 machine it says it doesn't apply
and isn't already, whereas another it installs..!
http://support.microsoft.com/kb/2705357:
To apply this hotfix, you must be running one of the following operating systems:
- Windows 7
- Windows 7 Service Pack 1 (SP1)
- Windows Server 2008 R2
- Windows Server 2008 R2 Service Pack 1 (SP1)
..obviously, if a client has the issue it applies :)
Donald Rumsfeld's 'known unknowns' comes to mind here. Sorry.
March 9th, 2015 7:54am
2617858 is included in 2775511 which most folks consider a must install. I certainly have been installing/deploying it at all customers for the last few years. Thus, there's really no reason
to be selective here, just deploy 2775511 across the board IMO.
March 9th, 2015 10:10am