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.exe

Recently 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 didnt 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 youll 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? Heres 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]Activity
Right Click on WMI]Activity ]> Trace and select Properties

Select Enable Logging

And now you are all set to trace the path culprit takes.
Lets 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!

h Memory Usage by WMI Service or Wmiprvse.exe - Ask t...

http://blogs.technet.com/b/askperf/archive/2014/08/11/wm

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

Scenario

Windows Management Instrumentation Service (Winmgmt) or WMIprovider (wmiprvse.exe) is consuming high amounts
of memory.
oughts from the EPS Windows Server Performance Team
There are many reasons why WMI might experience high memory consumptions. This can occur in the WMI (Windows
Management Instrumentation) service (winmgmt) or in the WMI provider hosting vehicle wmiprvse.exe. Both scenarios will
be addressed below.
High memory usage may simply be due to load, as opposed to some type of leak. By default, the memory quota limit for
instances 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 wmiprvses cumulatively. If the
total memory of all instances of wmiprvses (with one exception) together reaches 1GB, then all new memory allocations
fail 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 you
still 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.exe
Click Connect

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

Note: you arent connecting to CimV2 or any other namespaces. Its ROOT
Click Connect
Click Enum Instances

In the Class Info dialog box enter Superclass Name as "__ProviderHostQuotaConfiguration" (without quotes) and
press 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 case
that will be MemoryPerHost

In the Value dialog, type in 536870912 (512 MB) for XP and Windows 2003. For Vista and higher, start with new
value of 805306368 (768), then move to 1073741824 (1024) if still needing room. At the same time, if you are
going to bump up the MemoryPerHostLimit, you should also then bump up the MemoryAllHost limit to
2147483648 (2048) provided you have the available ram to do so. If this does not resolve quota violation issue, then
need to troubleshoot cause of high memory usage following below Scenario section
Click 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 Instrumentation
service 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 leaking
providers into their own group (wmiprvse) to avoid the memory quota caused by other providers running in the group or
kill 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 to
address 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 virtual
memory 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 that
process.
2. Simply launch VMMap and from the process list it displays, pick the instance of wmiprvse showing the
high working set memory usage.
3. If it is a svchost process that is exhibiting high memory, from a command run scqueryex winmgmt to
identify the PID of the svchost process that is hosting WMI Service (winmgmt). From experience it will be the
WMI service more times than not but not always as the service using majority of the memory; as such I
would try to break it out first on its own and monitor to see if it is the one driving up high memory usage in
the 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 hasnt already been accomplished so you
can run VMMap specifically against the WMI service to truly know if it is being consumed by Heap or Private Data. By
default the WMI service runs in a shared svchost process with a community of other services. You can do so by the
following directions. If it is caused by Heap, you will find later in the Scenario directions below that you will have to go
back 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 winmgmt
type= 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

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 Instrumentation
service 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 WDK
package.
2. Go to the directory where you installed the tool and you will find gflags.exe as one of the files, right click
on 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 the
properties 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 their
associated 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 of
wmiprivse.exe. Open an instance of PowerShell with admin rights
11. Run the following commands: Replace ProviderName below with actual ProviderNamer found from step
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 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 you
saved Procdump
15. Open Task Manager and add the PID column view then go locate the instance of wmiprvse.exe with
high 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 procdump
command from
17. Note also as workaround until issue gets resolved you could simply kill the instance of wmiprvse with
high 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 to
determine cause of high memory usage
Reference this blog when you open the Support Incident Case with Microsoft as it will help the engineer
understand 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

The Windows Management Instrumentation service runs under the display name of winmgmtand is located in
networking svchost.exe process shared along with several other services. You need to break the WMI service out into its
own 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 at
beginning of this article, then you can skip to step 6 to uniquely name the svchost process it is running in. We do this
because we only want to enable User Stack Tracingagainst just the WMI service and not every svchost process.
1. Open command prompted with elevated privileges
2. Break wmi service out into its own svchost process by running following command: sc config winmgmt type=
own
3. Restart wmi service with net stop winmgmt and net start winmgmt commands
4. Verify winmgmt service running in its own svchost process by runnning tasklist /svc
5. Change command focus to system32 folder and run following command: copy svchost.exe wmisvchost.exe
6. From start run type in regedit and navigate to HKLM\System_CurrentControlSet\Services\Winmgmt
7. Modify existing ImagePath from %systemroot%\system32\svchost.exe -k netsvcs to %systemroot%\system32
\wmisvchost.exe -k netsvcs
Note: It is important that you go back and reverse what you did in step 7 and modify path back to original after
you are no longer needing the service to be broken out and uniquely named as failure to do this can prevent
future 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 at
process list
10. For sake of brevity here, follow steps 4-14 from Scenario 1a with the exception of typing in
wmisvchost.exe in place or wmiprvse.exe for process we are enabling Create user mode stack trace
database against.
11. Here we want to use procdump to dump the wmisvchost.exe process along with every instance of
wmiprvse.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 second
command 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 analyzed
to determine cause of high memory usage
Reference this blog when you open the Support Incident Case with Microsoft as it will help the engineer
understand what actions have been taken or followed and will help us track the effectiveness of the blog.

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 full
story. In this type of case, we need to know what type of wmi activity is occurring and it becomes significantly harder and
more 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 Explorer
http://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 the
properties 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 their
associated 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 of
wmiprivse.exe. Open an instance of PowerShell with admin rights
7. Run the following commands: Replace ProviderName below with actual ProviderNamer found from step

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 memory
usage. 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 you
saved Procdump
11. Open Task Manager and add the PID column view then go locate the instance of wmiprvse.exe with
high memory usage and note the PID, or use Process Explorer
12. 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 space out 5 minutes apart each in same directory you ran the procdump
command 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 events
as option
At this point you will now need to open a Support Incident Case with Microsoft for data analysis and most likely
for more in depth troubleshooting and data collection methods
Reference this blog when you open the Support Incident Case with Microsoft as it will help the engineer
understand what actions have been taken or followed and will help us track the effectiveness of the blog.

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 at
beginning of this article, then you can skip to step 5
1. Open command prompted with elevated privileges
2. Break WMI service out into its own svchost process by running following command: sc config winmgmt type=
own
3. Restart WMI service with net stop winmgmt and net start winmgmt commands
4. Verify winmgmt service running in its own svchost process by runnning tasklist /svc
5. From start run type in eventvwr.msc
6. On the View menu at the top select show analytical and debug logs so it displays check mark next to it
7. Expand Applications and Services\Microsoft\Windows\WMI-Activity
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 of
wmiprvse.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 in
and note the PID
b. First command will dump svchost.exe 3 times spaced at 5 minute interval. Once it has completed, and
then 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

9. 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
10. Now save wmi-activity traces in Event Viewer, do so by right clicking on each and select Save all events as
option
At this point you will now need to open a Support Incident Case with Microsoft for data analysis and most likely

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 it
will help the engineer understand what actions have been taken or followed and well help us track the
effectiveness of the blog.
TAG = WMITBLOG

WMI: How to troubleshoot High CPU Usage by WMI

Components
Scenario
Windows Management Instrumentation Service (Winmgmt) or WMI provider (wmiprvse.exe) is consuming high
amounts of CPU.
In the directions below, you may have already broken out WMI Service to troubleshoot your issue. By default, WMI runs
in 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 which
svchost process has the high memory usage. From inside a command prompt you can type in tasklist /svc and look for
the PID #, and identify if a single service is running in that svchost process or multiple services. If multiple services, it may
become 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 usage
in 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
1. Open command prompt with elevated privileges
2. Run following command: sc config winmgmt type= own
3. Restart Wmi service
4. Run sc query winmgmt to ensure status of service now reflects own indicating running in its own svchost
process
When issue had been resolved or no longer needing the service broken out into its own svchost process, place it back into
the shared svchost process by running following command from command prompt:
sc config <service name> type= share
Restart the service or machine and verify result is Win32_SHARE_PROCESS when you
run 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, you
may 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 restart
on boot.
Collect and Xperf trace for High CPU by using the Windows Performance Recorder form the Windows
Performance 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 before
collecting Xperf trace.
Registry Path

HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management

Setting
DisablePagingExecutive
Data Type:
REG_DWORD
Value:
1
NOTE setting this key is not needed on Windows Server 2012 & 2012 R2
Reboot machine to place registry setting into effect.
1. Download the Windows 8 ADK (Windows Assessment Deployment Kit) from here.
2. Open the adksetup.exe and hit next until you get you the option to select feature options
3. Select "Windows Performance Toolkit" and hit "Install"

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 dump
out 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 you
saved Procdump

3. Open Task Manager and add the PID column view, then go locate the instance of wmiprvse.exe with high
cpu usage and note the PID. If it was the WMI service that had the high cpu, then you should already have it
broken out to run in its own svchost process and note the PID of that svchost process. To confirm you have
the right svchost process, you can run tasklist /svc from administrative command prompt and verify the PID
noted in task manager and ensure it is the svchost process running winmgmt in it.
4. Run the following command: procdump ma -s 60 -n 3 <PID>
Note: Replace <PID> with actual PID you documented for instance of wmiprvse.exe or for the svchost process running
winmgmt exhibiting high memory usage
The above command will produce 3 dumps spaced 1 minute apart each in same directory you ran the procdump
command 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 bring
up 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 to
determine cause of high CPU usage.
Please reference this blog and the following TAG when you open the Support Incident Case with Microsoft, as it
will help the engineer understand what actions have been taken or followed and well help us track the
effectiveness of the blog.
TAG = WMITBLOG