Troubleshoot WmiPrvSE - High CPU Usage Problem

WmiPrvSE.exe - high CPU usage problem

Solution 1:-WmiPrvSE.exe ] high CPU usage problem caused by bad startup program. In my case the high cpu usage problem is caused by the startup program "deep freeze". when i use defragmentation program in thawned state it generates WmiPrvSE.exe hich cpu usage problem. so when you want to use the defragmentation program first uninstall deep freeze.

Solution 2 - Perform Clean Boot:-1. Log on to the computer by using an account that has administrator rights.2. Click Start, type msconfig.exe in the Start Search box, and then press Enter to start the System Configuration

utility. Note If you are prompted for an administrator password or for confirmation, you should type the password or provide confirmation.

3. On the General tab, click the Selective startup option, and then click to clear the Load startup items check box. (The Use Original Boot.ini check box is unavailable.)

4. On the Services tab, click to select the Hide all Microsoft services check box, and then click Disable all.

Note This step lets Microsoft services continue to run. These services include Networking, Plug and Play, Event Logging, Error Reporting, and other services. If you disable these services, you may permanently delete all restore points. Do not do this if you want to use the System Restore utility together with existing restore points.

5. Click OK, and then click Restart.

Solution 3 - Using Netmon to figure out the source of high CPU in WMIprvse.exeRecently I was working with a customer who had a file server experiencing high CPU in the WMIprvse.exe process. We received multiple user dumps and noted that someone or something was running the same query again and again. We needed to figure out what was running the query in a tight loop, causing the high CPU.

Figure 1 ] Task Manager on FileServer

Before we get into the exact troubleshooting steps, let me provide some background on WMI. Winmgmt is the WMI service within a SVCHOST process running under the LocalSystem account. In all cases, the WMI service automatically starts when the first management application or script requests connection to a WMI namespace. For more information, see Starting and Stopping the WMI Service. To avoid stopping all the services when a provider fails, each provider is loaded into a separate host process named "Wmiprvse.exe". This also allows each instance of Wmiprvse to run under a different account with varying security. For more details you can look at the MSDN documentation on WMI.

I dumped out all the services in the various svchost.exe processes. You can do this from a command prompt by running the tasklist /svc command. In my instance, I found that the WinMgmt service was running in svchost, PID 452 (PID number will vary). Someone had to be making RPC calls to this svchost.exe process to run the WMI queries. It could be some local process on the machine; it could even be a process on a remote machine.

At this point I requested user dumps of PID 452 from the customer. This would allow me to determine who was making the RPC calls to svchost.exe to run the WMI queries. While the customer was uploading the dumps, we decided to get a Network Monitor trace to see if the RPC calls were coming over the network.

Immediately, I could see a lot of RPC traffic to the svchost.exe process(PID=452).

Figure 2 ] Network Monitor Output from the FileServer. Notice the Source and destination ports and IP addresses. IP addresses are hidden by the aliases

Looking at the RPC payload, I could see the text of the WMI query. You can see this in the Hex Details Pane. The query that was running in a loop was “Select * from Win32_Process”. Looks like I found the source of the WMI queries.

At this point, we got the source IP for the RPC packets. We logged into the machine, and brought up the Task Manager.

Figure 3 ] Task Manager on Remote Machine(Machine1)

Immediately we saw that there was some script running inside a Wscript.exe process. At this point I was pretty sure that this script was the culprit. The customer was not sure what this was, and was not comfortable terminating the process. To prove my suspicion, I had him open a command prompt and run the following command, netstat ^ano.

Figure 4 ] Netstat output from Remote Machine

From the output in Fig. 4, I could see a TCP connection created by PID 3532 (wscript.exe). Looking at the local and foreign addresses from the above output, they matched up exactly to what we were seeing in the Network Monitor trace.

In the above case, we already had our suspicions on the wscript.exe process; however, sometimes it might not be that easy. In that case, we could have used the netstat output to look at all connections to the file server (157.59.123.121). If there were multiple connections, then we can also narrow it down by the port number. Based on that, we could have found the PID responsible.

The customer called me later in the day, and told me that they had recently updated their scripts. One of their scripts had a bug which was running WMI scripts in a tight loop. Fixing the script caused the problem to go away.

Had the query being coming from a local process, I would have had to debug the svchost.exe process, and figure out who was making the WMI calls. However, since we could see the traffic on netmon, we didn’t need to use the debugger. Interesting way to get to the root of the problem without using a debugger!

Solution 4 - Restart the “Windows management Instrumentation” Service:-Restart the “Windows management Instrumentation” Service. The dependent services will restart in the proper order and you’ll see the CPU go way down to normal levels.

just access your Services program. The easiest way to find is just click Start, type Services, hit Enter. Under Services (Local), scroll down until you find the “Windows Management Instrumentation” service and select Restart.

Solution 5 - Is WMIprvse a real villain?How often has it occurred that you were working on something and suddenly your computer became slow? You opened task manager to find out the culprit that is hogging your systems CPU cycles. You sorted the processes according to CPU usage and saw WMIprvse.exe happily sitting at the top.

Before putting the blame on WMIprvse.exe have you ever wondered that it can be that some other application contracted the WMIprvse.exe to create havoc on your computer? Here’s how you can find the culprit which is using WMIprvse.exe to eat up your system resources.

Open Event viewer (Control Panel\System and Security\Administrative Tools\Event Viewer) and enable “Show Analytic and Debug Logs”

Navigate to Application and Services Logs ]> Microsoft ]> Windows ]> WMI]ActivityRight Click on WMI]Activity ]> Trace and select Properties

Select “Enable Logging”

And now you are all set to trace the path culprit takes.Let’s see how a typical event looks like and try to understand the various fields in the event

GroupOperationID: is a unique identifier that is used for all events reported for a specific client.OperationId: indicates the operation sequence.Operation: This will give you the WMI query issued by the client application. In the above example, CreateInstanceEnum has been issued on the win32_process class.ClientMachine: Computer name from which the request originated.User: indicates the account that makes a request to WMI by running a script or through CIM Studio.ClientProcessId: Process Identifier for the process which issued the WMI query.NamespaceName: shows the WMI namespace to which the connection is made(Visit http://msdn.microsoft.com/en]us/library/aa826686(VS.85).aspx for detailed information.)

A quick look up in the task manager for the ClientProcessId will give you the process name against which you might want to take action to bring your computer back to the normal state.

Hope this will help in finding the real villain!

http://msdn.microsoft.com/en-us/library/aa826686(VS.85).aspx

Thoughts from the EPS Windows Server Performance Team

WMI: High Memory Usage by WMI Service or Wmiprvse.exe - Ask t... http://blogs.technet.com/b/askperf/archive/2014/08/11/wmi-high-mem...

1 of 7 25-Apr-15 10:11 AM

WMI: High Memory Usage by WMI Service or Wmiprvse.exe

Scenario

Windows Management Instrumentation Service (Winmgmt) or WMIprovider (wmiprvse.exe) is consuming high amountsof memory.

There are many reasons why WMI might experience high memory consumptions. This can occur in the WMI (WindowsManagement Instrumentation) service (winmgmt) or in the WMI provider hosting vehicle wmiprvse.exe. Both scenarios willbe addressed below.

High memory usage may simply be due to load, as opposed to some type of leak. By default, the memory quota limit forinstances of wmiprvse.exe on Windows XP and Windows Server 2003 is 128 MB, and 512 MB on newer Operating Systems(Vista and higher). Hit those limits and wmi functionality will become problematic if not come to a grinding halt.

There is another case where the quota limit problem could happen. There is limit for all wmiprvse’s cumulatively. If thetotal memory of all instances of wmiprvse’s (with one exception) together reaches 1GB, then all new memory allocationsfail in all wmiprvse processes.

As a first effort you can try to bump up that quota limit to see if it gives enough room for wmiprvse to operate, but if youstill reach the new quota limit, then you will want to proceed with the Scenarios below

How To Bump up WMI memory quota limit:

Go to Start--> Run and type wbemtest.exeClick Connect

In the namespace text box type "root" (without quotes).

Note: you aren’t connecting to CimV2 or any other namespaces. It’s ROOT

Click ConnectClick Enum Instances…

http://blogs.technet.com/b/askperf/archive/2014/08/11/wmi-high-mem...

In the Class Info dialog box enter Superclass Name as "__ProviderHostQuotaConfiguration" (without quotes) andpress OK. Note: the Superclass name includes a double underscore at the front.

In the Query Result window, double-click "__ProviderHostQuotaConfiguration=@"

In the Object Editor window, double-click whichever Property name you wish to modify the quota for. In this casethat will be MemoryPerHost


2 of 7 25-Apr-15 10:11 AM


In the Value dialog, type in 536870912 (512 MB) for XP and Windows 2003. For Vista and higher, start with newvalue of 805306368 (768), then move to 1073741824 (1024) if still needing room. At the same time, if you aregoing to bump up the MemoryPerHostLimit, you should also then bump up the MemoryAllHost limit to2147483648 (2048) provided you have the available ram to do so. If this does not resolve quota violation issue, thenneed to troubleshoot cause of high memory usage following below Scenario sectionClick Save Property.Click Save Object.Close Wbemtest.Restart the machine

Note: if you cannot restart the machine, then as a workaround, you can break Windows Management Instrumentationservice into its own svchost process outline in step 2. a-c below.

If bumping the quota limits does not resolve the issue, then as workaround you can try to move suspected leakingproviders into their own group (wmiprvse) to avoid the memory quota caused by other providers running in the group orkill the instance of wmiprvse exhibiting high memory until issue is resolved. This is outlined below in Scenarios 1a and 2a.

First thing we need to determine is if the memory consumption being caused by private data or heap data. We have toaddress the 2 types differently.

1. Download a Windows Sysinternals tool call VMMap from following url: http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx

VMMapis a process virtual and physical memory analysis utility. It shows a breakdown of a process's committed virtualmemory types as well as the amount of physical memory (working set) assigned by the operating system to those types.

This tool is used to attach to an individual process allowing a snapshot to be taken to see the memory map for thatprocess.

2. Simply launch VMMap and from the process list it displays, pick the instance of wmiprvse showing thehigh working set memory usage.

3. If it is a svchost process that is exhibiting high memory, from a command run scqueryex winmgmt toidentify the PID of the svchost process that is hosting WMI Service (winmgmt). From experience it will be theWMI service more times than not but not always as the service using majority of the memory; as such Iwould try to break it out first on its own and monitor to see if it is the one driving up high memory usage inthe shared svchost process.

From this point, I will assume it is the WMI service as this article is only addressing WMI and no other services.

You will need to break the WMI service out into its own svchost process first if it hasn’t already been accomplished so youcan run VMMap specifically against the WMI service to truly know if it is being consumed by Heap or Private Data. Bydefault the WMI service runs in a shared svchost process with a community of other services. You can do so by thefollowing directions. If it is caused by Heap, you will find later in the Scenario directions below that you will have to goback and uniquely name the svchost process for the service to run in to be able to enable User Stack Tracingagainst it.

a. Open command prompted with elevated privileges

b. Break wmi service out into its own svchost process by running following command: sc config winmgmttype= own

c. Restart wmi service with net stop winmgmt and net start winmgmt commands

d. Verify winmgmt service running in its own svchost process by runnning tasklist /svc

4. Once it displays the result, look under the size column for Private Data and Heap. This should tell you if


3 of 7 25-Apr-15 10:11 AM

http://technet.microsoft.com


the majority of the memory being consumed is Private Data or Heap.

5. Follow appropriate Scenario below based on if issue is with Windows Management Instrumentationservice or wmiprvse and if caused by Heap or Private Data memory.

Scenario 1a: High Memory Consumption by Wmiprvse.exe caused by Heap memory

1. Download Windows Debugging Tools for Windows from following link: http://msdn.microsoft.com/en-us/windows/hh852365.aspx

You can probably just get the standalone version since we only need the debugging tool and not the whole WDKpackage.

2. Go to the directory where you installed the tool and you will find gflags.exe as one of the files, right clickon it and select run as administrator

3. Click on “Image File” tab

4. Type in wmiprvse.exe

5. Hit the keyboard TAB key

6. Place check mark in “Create user mode stack trace database”

7. Click Ok

8. Download the latest version of the Windows Sysinternals tool Process Explorer.http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

9. Find the instance of wmiprvse.exe with high memory consumption and right click on it and bring up theproperties sheet. Click on the WMI Providers tab and document the listed providers

Alternatively you could run following wmiccommand from command prompt to get a list of loaded providers and theirassociated PID you could then match up to PID with instance of wmiprvse with high memory usage:

wmic path msft_providers get Provider,HostProcessIdentifier /format:list

10. We now want to take that list of providers and configure them to run in their own instance ofwmiprivse.exe. Open an instance of PowerShell with admin rights

11. Run the following commands: Replace ProviderName below with actual ProviderNamer found from step9, retain the quote marks.

$prv = gcim -namespace root/standardcimv2 __win32provider -filter "name='ProviderName'"<ENTER>$prv.HostingModel = $Prv.HostingModel + ":OWN"<ENTER>set-ciminstance -inputobject $prv<ENTER>

Repeat the above for each Provider found in step 9

12. Restarting of Wmi service will put the settings into effect without having to reboot machine

13. Now you will want to take a process dump of the instance of wmiprvse when memory usage is high.Download Windows Sysinternals tool called Procdump from URL: http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

14. Open a command prompt with elevated or administrative rights and change to the directory where yousaved Procdump

15. Open Task Manager and add the PID column view then go locate the instance of wmiprvse.exe withhigh memory usage and note the PID, or use Process Explorer

16. Run the following command: procdump –ma -s 300 -n 3 <PID>

Note: Replace <PID> with actual PIDyou documented for instance of wmiprvse.exe exhibiting high memory usage

The above command will produce 3 dumps spaced at 5 minutes apart each in same directory you ran the procdumpcommand from

17. Note also as workaround until issue gets resolved you could simply kill the instance of wmiprvse withhigh memory from task manager or from PowerShell can run following:

kill -f <pid of suspect wmiprvse>

At this point you will now need to open a Support Incident Case with Microsoft to get the data analyzed todetermine cause of high memory usage

Reference this blog when you open the Support Incident Case with Microsoft as it will help the engineerunderstand what actions have been taken or followed and will help us track the effectiveness of the blog.

Scenario 1b: High Memory Consumption by WMI (Windows Management Instrumentation)service caused by Heap memory


4 of 7 25-Apr-15 10:11 AM

http://msdn.microsoft.com

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

http://technet.microsoft.com/en-us


The Windows Management Instrumentation service runs under the display name of winmgmtand is located innetworking svchost.exe process shared along with several other services. You need to break the WMI service out into itsown unique svchost process for data collection purposes.

NOTE: If you have already broken the WMI service out to run in its own general svchost process following directions atbeginning of this article, then you can skip to step 6 to uniquely name the svchost process it is running in. We do thisbecause we only want to enable User Stack Tracingagainst just the WMI service and not every svchost process.

Open command prompted with elevated privileges1. Break wmi service out into its own svchost process by running following command: sc config winmgmt type=own

2.

Restart wmi service with net stop winmgmt and net start winmgmt commands3. Verify winmgmt service running in its own svchost process by runnning tasklist /svc4. Change command focus to system32 folder and run following command: copy svchost.exe wmisvchost.exe5. From start run type in regedit and navigate to HKLM\System_CurrentControlSet\Services\Winmgmt6. Modify existing ImagePath from %systemroot%\system32\svchost.exe -k netsvcs to %systemroot%\system32\wmisvchost.exe -k netsvcs

7.

Note: It is important that you go back and reverse what you did in step 7 and modify path back to original afteryou are no longer needing the service to be broken out and uniquely named as failure to do this can preventfuture WMI hotfixes from being installed.

Simply run following command then restart wmi service: sc config winmgmt type= share

8. Restart wmi service with net stop winmgmt and net start winmgmt commands again

9. Verify you now see wmisvchost.exe process running by running tasklist or looking in task manager atprocess list

10. For sake of brevity here, follow steps 4-14 from Scenario 1a with the exception of typing inwmisvchost.exe in place or wmiprvse.exe for process we are enabling “Create user mode stack tracedatabase” against.

11. Here we want to use procdump to dump the wmisvchost.exe process along with every instance ofwmiprvse.exe that is running. Reference steps 9-11 listed in Scenario 1a above.

First command will dump wmisvchost.exe 3 times spaced at 5 minute interval. Once it has completed, and then run secondcommand to dump out each instance of wmiprvse.exe that is running.

Command for dumping wmisvchost.exe would be: procdump –ma -s 300 -n 3 wmisvchost.exe

Command for dumping each instance of wmiprvse just once: procdump –ma <PID>

Note: Replace <PID> with actual PID for each instance of wmiprvse.exe

At this point you will now need to open a Support Incident Case with Microsoft to get the process dumps analyzedto determine cause of high memory usage


Scenario 2a: High Memory Consumption by Wmiprvse.exe caused by Private Data memory

This scenario is a little bit different than being caused by Heap, as just dumps in of themselves normally do not tell the fullstory. In this type of case, we need to know what type of wmi activity is occurring and it becomes significantly harder andmore involved to try and determine cause.

We will need to collect procdumps still, but also need to add in WMI activity logging.

1. From start run type in eventvwr.msc

2. On the View menu at the top select “show analytical and debug logs” so it displays check mark next to it

3. Expand Applications and Services\Microsoft\Windows\WMI-Activity

Right click on items Debug and Trace and select “Enable” for each one

4. Download the latest version of the Windows Sysinternals tool Process Explorerhttp://technet.microsoft.com/en-us/sysinternals/bb896653.aspx.

5. Find the instance of wmiprvse.exe with high memory consumption and right click on it and bring up theproperties sheet. Click on the WMI Providers tab and document the listed providers

Alternatively you could run following wmiccommand from command prompt to get a list of loaded providers and theirassociated PID you could then match up to PID with instance of wmiprvse with high

memory usage:

wmic path msft_providers get Provider,HostProcessIdentifier /format:list

6. We now want to take that list of providers and configure them to run in their own instance ofwmiprivse.exe. Open an instance of PowerShell with admin rights

7. Run the following commands: Replace ProviderName below with actual ProviderNamer found from step


5 of 7 25-Apr-15 10:11 AM

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx.


9, retain the quote marks.

$prv = gcim -namespace root/standardcimv2 __win32provider -filter "name='ProviderName'"<ENTER>$prv.HostingModel = $Prv.HostingModel + ":OWN"<ENTER>set-ciminstance -inputobject $prv<ENTER>

Repeat the above for each Provider found in step 5

8. Restarting of Wmi service will put the settings into effect without having to reboot machine

9. When memory usage is high, use Procdump tool to dump out the wmiprvse.exe exhibiting high memoryusage. http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

10. Open a command prompt with elevated or administrative rights and change to the directory where yousaved Procdump

11. Open Task Manager and add the PID column view then go locate the instance of wmiprvse.exe withhigh memory usage and note the PID, or use Process Explorer


Note: Replace <PID> with actual PIDyou documented for instance of wmiprvse.exe exhibiting high memory usage

The above command will produce 3 dumps space out 5 minutes apart each in same directory you ran the procdumpcommand from

13. Collect a network trace for 2 minutes using Network Monitor. Latest version can be found at:http://www.microsoft.com/en-us/download/details.aspx?id=4865

14. Now save wmi-activity traces in Event Viewer, do so by right clicking on each and select “Save all eventsas” option

At this point you will now need to open a Support Incident Case with Microsoft for data analysis and most likelyfor more in depth troubleshooting and data collection methods


Scenario 2b: High Memory Consumption by WMI (Windows Management Instrumentation)service caused by Private Data memory

NOTE: If you have already broken the WMI service out to run in its own general svchost process following directions atbeginning of this article, then you can skip to step 5

Open command prompted with elevated privileges1. Break WMI service out into its own svchost process by running following command: sc config winmgmt type=own

2.

Restart WMI service with net stop winmgmt and net start winmgmt commands3. Verify winmgmt service running in its own svchost process by runnning tasklist /svc4. From start run type in eventvwr.msc5. On the View menu at the top select “show analytical and debug logs” so it displays check mark next to it6. Expand Applications and Services\Microsoft\Windows\WMI-Activity7.

Right click on items Debug and Trace and select “Enable” for each one

8. Here we want to use procdump to dump the svchost process housing the WMI Service along with every instance ofwmiprvse.exe that is running. Reference steps 9-10 listed in Scenario 1a above

a. From command prompt run tasklist /svc and locate the instance of svchost that winmgmt is running inand note the PID

b. First command will dump svchost.exe 3 times spaced at 5 minute interval. Once it has completed, andthen run second command to dump out each instance of wmiprvse.exe that is running just once

Command for dumping svchost.exe housing winmgmt would be: procdump –ma -s 300 -n 3 <PID>

Note: Replace <PID> with actual PID for svchost process housing winmgmt

Command for dumping each instance of wmiprvse running would be: procdump –ma <PID>

Note: Replace <PID> with actual PID for each instance of wmiprvse.exe

Collect a network trace for 2 minutes using Network Monitor. Latest version can be found at:http://www.microsoft.com/en-us/download/details.aspx?id=4865

9.

Now save wmi-activity traces in Event Viewer, do so by right clicking on each and select “Save all events as”option

10.

At this point you will now need to open a Support Incident Case with Microsoft for data analysis and most likely


6 of 7 25-Apr-15 10:11 AM

http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

http://www.microsoft.com/en-us/download/details.aspx?id=4865

http://www.microsoft.com/en-us/download/details.aspx?id=4865


for more in depth troubleshooting and data collection methods

Please reference this blog and the following TAG when you open the Support Incident Case with Microsoft, as itwill help the engineer understand what actions have been taken or followed and well help us track theeffectiveness of the blog.

TAG = WMITBLOG


7 of 7 25-Apr-15 10:11 AM


WMI: How to troubleshoot High CPU Usage by WMI Components - ... http://blogs.technet.com/b/askperf/archive/2014/08/12/wmi-how-to-tro...

1 of 4 25-Apr-15 10:13 AM

Scenario

Windows Management Instrumentation Service (Winmgmt) or WMI provider (wmiprvse.exe) is consuming highamounts of CPU.

In the directions below, you may have already broken out WMI Service to troubleshoot your issue. By default, WMI runsin the main shared networking svchost process with several other services.

If it is a svchost process showing high cpu usage, you can use Task Manager and add PID column, then identify whichsvchost process has the high memory usage. From inside a command prompt you can type in tasklist /svc and look forthe PID #, and identify if a single service is running in that svchost process or multiple services. If multiple services, it maybecome necessary to break each service out to run in its own svchost process to determine if it is the WMI service(winmgmt) that is causing the issue. From my experience, it will be the WMI service more times than not but not always. As such, I would suggest breaking it out first into its own, and monitor to see if it is the one driving up high memory usagein the shared svchost process.

If you suspect the WMI (Windows Management Instrumentation) service, you can break it out following directions below.

Break WMI Service out into its own svchost process

Open command prompt with elevated privileges1. Run following command: sc config winmgmt type= own2. Restart Wmi service3. Run sc query winmgmt to ensure status of service now reflects “own” indicating running in its own svchostprocess

4.

When issue had been resolved or no longer needing the service broken out into its own svchost process, place it back intothe shared svchost process by running following command from command prompt:

sc config <service name> type= shareRestart the service or machine and verify result is Win32_SHARE_PROCESS when yourun sc query winmgmt command again

Configure Perfmon Collection using logman.exe method. Capture 15 minutes while issue is occurring.

Short, high resolution log – 1 sec interval with thread counter, 250MB

1. Click on Start

<<Start Search>>, enter "CMD.exe" w/o the quotation marks and then press Enter.

2. Copy and paste the following command into the command prompt window (if this does not work, youmay need to manually type it in):

Logman.exe create counter PerfLog-Short -o "c:\perflogs\PerfLog-Short" -f bincirc -v mmddhhmm -max 250 -c"\Cache\*" "\LogicalDisk(*)\*" "\Memory\*" "\Network Interface(*)\*" "\Paging File(*)\*" "\PhysicalDisk(*)\*""\Processor(*)\*" "\Process(*)\*" "\Redirector\*" "\Server\*" "\System\*" "\Server Work Queues\*" "\Thread(*)\*"-si 00:00:01

3. Start the log with:

Logman.exe start PerfLog-Short

4. Please stop the performance log as soon as the issue returns with the following command:

Logman.exe stop PerfLog-Short

Please note that if you reboot the server, you will need to start the logs again as they will not automatically restarton boot.

Collect and Xperf trace for High CPU by using the Windows Performance Recorder form the WindowsPerformance Toolkit which you can install from the ADK

Note: If the Operating System is a 64 bit box, you must first accomplish the following registry setting beforecollecting Xperf trace.

Registry Path

WMI: How to troubleshoot High CPU Usage by WMIComponents

http://blogs.technet.com/b/askperf/archive/2014/08/12/wmi-how-to-tro...

HKLM\System\CurrentControlSet\Control\Session Manager\Memory ManagementSettingDisablePagingExecutiveData Type:REG_DWORDValue:1

NOTE setting this key is not needed on Windows Server 2012 & 2012 R2

Reboot machine to place registry setting into effect.

Download the Windows 8 ADK (Windows Assessment Deployment Kit) from here.1. Open the adksetup.exe and hit next until you get you the option to select feature options2. Select "Windows Performance Toolkit" and hit "Install"3.

After installation has finished, start creating a trace by starting the "Windows Performance Recorder"

Select CPU usage under Resource Analysis

Logging mode can be left set to “Memory”, or you can change to “File”. Just be conscious of your disk space if you chose“File” as the etl file can become large fast

Capture high cpu occurrence, but do not let the recording run for no more than 10 minutes.

Immediately after capturing the event using Windows Performance Recorder (WPR), now use process explorer to dumpout the process exhibiting high cpu usage.

1. Download Windows Sysinternals tool called Procdump: http://technet.microsoft.com/en-us/sysinternals/dd996900.aspx

2. Open a command prompt with elevated or administrative rights and change to the directory were yousaved Procdump


2 of 4 25-Apr-15 10:13 AM

http://technet.microsoft.com/en-us/sysinternals


3. Open Task Manager and add the PID column view, then go locate the instance of wmiprvse.exe with highcpu usage and note the PID. If it was the WMI service that had the high cpu, then you should already have itbroken out to run in its own svchost process and note the PID of that svchost process. To confirm you havethe right svchost process, you can run tasklist /svc from administrative command prompt and verify the PIDnoted in task manager and ensure it is the svchost process running winmgmt in it.


Note: Replace <PID> with actual PID you documented for instance of wmiprvse.exe or for the svchost process runningwinmgmt exhibiting high memory usage

The above command will produce 3 dumps spaced 1 minute apart each in same directory you ran the procdumpcommand from

5. Download the latest version of the Windows Sysinternals tool Process Explorer.http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

6. If it was wmiprvse.exe that had the high CPU usage, then find the instance and right click on it and bringup the properties sheet. Click on the WMI Providers tab and document the listed providers

At this point you will now need to open a Support Incident Case with Microsoft to get the data analyzed todetermine cause of high CPU usage.

Please reference this blog and the following TAG when you open the Support Incident Case with Microsoft, as itwill help the engineer understand what actions have been taken or followed and well help us track theeffectiveness of the blog.

TAG = WMITBLOG


3 of 4 25-Apr-15 10:13 AM

http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


Documents

Troubleshoot WmiPrvSE - High CPU Usage Problem