We're running v6.1.0 of the Horizon View Agent which has the vRealize Operations Manager agent built in. With the "VMware vRealize Operations Horizon Desktop Agent" service running we're seeing 4-10% CPU usage (our VDI sessions are two vCPU's) from WmiPrvSE.exe. Using Process Monitor the process is constantly trying to access the C:\Windows\System32\tzres.dll file which looks to pertain to the time zone setting of Windows. When the service is disabled WmiPrvSE.exe goes away and CPU goes back down. Anyone have any thoughts on what the heck is going on? This is way too much overhead for a monitoring tool and looking to just remove all together. We've had this issue from the start (running vROPS 6 within our View 5.3 environment prior to upgrading).
Thanks,
Travis
Just a quick update...we've disabled the vRealize service and the CPU dropped down. We've struggled on finding value in the product anyways so we have ceased to use it.
WmiPrvSE.exe is not a virus or a malware. Windows® Management Instrumentation (WMI) is a component of the Microsoft Windows operating system that provides management information and control in an enterprise environment.
This is due to bad startup programs.
Detailed insofmation about this error are given here.. You can find all information from here.
WmiPrvSE.exe high CPU usage problem caused by bad startup program
or from this link
Just a quick update...we've disabled the vRealize service and the CPU dropped down. We've struggled on finding value in the product anyways so we have ceased to use it.
We're experiencing this same issue in our Horizon 7.0.1 / vSphere 6.0 U2 / vRops 6.2 / V4V 6.3 environment today. It's being made even worse by the fact that the WMIprvSE.exe is tripping up our AV on-access scanner and causing our AV agent to consume another 50% of the CPU on top of the usage by WMIprvSE.exe. I'll follow-up if VMware support has a fix or not.
Apparently this is a known bug and it's supposed to be fixed in V4V 6.4, no solid ETA for that release though. We're ripping the agent out for now and will re-evaluate once 6.4 is available.
Read this Virtual Cloud by J
This known issue and has been fixed in v4h 6.4 which is expected to out Q4 2016.