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?

A shot in the dark :-D

Have you reviewed client log files? Have you enabled software inventory ? 

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

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.

If that is your belief and you have evidence, please contact CSS so that they can review and coordinate a fix.

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.

We have the exact same issue here! Please let us know if you found a fix for this!

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.

Our contract does not include support. We are hoping someone else found and solved this issue.

Our contract does not include support. We are hoping someone else found and solved this issue.

It's hard to help without sitting in front of an affected system, so all I can offer is having a look at http://ccmexec.com/2012/06/suggested-hotfixes-for-wmi-related-issues-on-windows-platforms-updated-june-14th-2012/, which *might* help.

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.

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

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

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

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

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

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

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.

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

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.

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 }
}

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.

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.

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.

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

Rebuilding WMI is not recommended by Microsoft, see http://blogs.technet.com/b/configmgrteam/archive/2009/05/08/wmi-troubleshooting-tips.aspx: "Don't delete the repository (though it may make problems seem to go away)"

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.

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?

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.

How many updates are we looking at? We have 92, but we've got 3500 machines. Is this too many?

Thanks

Jack

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.

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.