Bug 1848380

Summary: blnsvr.exe consumes CPU making continuous failed Win32_PerfRawData_PerfOS_Memory queries
Product: [Community] Virtualization Tools Reporter: Kevin Mitchell <kevmitch>
Component: virtio-winAssignee: Amnon Ilan <ailan>
Status: CLOSED WORKSFORME QA Contact: xiagao
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: ghammer, haoliu, jinzhao, juzhang, virt-maint, vrozenfe, yvugenfi
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Windows   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-05 07:55:00 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Kevin Mitchell 2020-06-18 09:26:08 UTC
Description of problem:

On a windows guest with virtio-win drivers installed, task manager shows "WMI Provider Host" consuming a consistent ~5% CPU at idle.

Version-Release number of selected component (if applicable):

The guest is running Windows 10 Home Version 1909 OS build 18363.900.

I can reproduce the problem with both virtio-win-0.1.1 (stable) and virtio-win-0.1.185 (latest).

The host is running Debian testing with

* linux-5.6.14-2
* qemu-5.0-5 
* libvirt-6.0.0-7 
* virt-manager-2.2.1-4

How reproducible:
100% 

Steps to Reproduce:
1. Create a new Windows 10 guest VM with virt-manager with OVMF firmware (not sure if relevant, didn't try BIOS)
2. Run the virtio-win-gt-x64 installer from the virtio-win iso
3. Reboot
4. Open task manager and wait for system to settle from boot

Actual results:

"WMI Provider Host" continues to consume ~5% CPU

Expected results:

The idle guest should report near 0% CPU usage.

Additional info:

Digging into the Event Viewer under 

Applications and Services Logs/Microsoft/Windows/WMI-Activity/Operational

I see an Error log approximately every second like:

Id = {00000000-0000-0000-0000-000000000000}; 
ClientMachine = DESKTOP-RNTOIM5; 
User = NT AUTHORITY\SYSTEM; 
ClientProcessId = 1644; 
Component = Unknown; 
Operation = Start IWbemServices::ExecQuery - root\cimv2 : SELECT * FROM Win32_PerfRawData_PerfOS_Memory; 
ResultCode = 0x80041017; 
PossibleCause = Unknown

ClientProcessId = 1644 is the PID of blnsvr.exe. 

I believe the failed query is at 

https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/Balloon/app/memstat.cpp#L109

If I go to "Services" and stop "BalloonService", CPU usage drops to 0% as expected.

Comment 1 xiagao 2020-06-23 01:51:27 UTC
I tried to reproduce,but failed.

host version:
kernel-4.18.0-206.el8.x86_64
qemu-kvm-5.0.0-0.module+el8.3.0+6620+5d5e1420.x86_64
edk2-ovmf-20200602gitca407c7246bf-1.el8.noarch
virtio-win-1.9.12-0.el8.iso(balloon version: 185)

guest version:
win10-64  os version: 18363

steps is the same with comment0

Actual results:
"WMI Provider Host" consume 0% CPU while balloon service is running.

Comment 2 Vadim Rozenfeld 2020-06-23 03:28:36 UTC
It looks as ExecQuery is failing. This is the reason why you see WMI request coming every second
0x80041017 means "Invalid query". 
KEvin, can you please try running the same or similar Win32_PerfRawData_PerfOS_Memory
query from the elevated account manually, by yourself and see the results?

Thanks,
Vadim.

Comment 3 Kevin Mitchell 2020-06-30 06:12:21 UTC
In the affected VM, I see:

PS C:\Windows\system32> Get-WmiObject -Query "SELECT * FROM Win32_PerfRawData_PerfOS_Memory"
Get-WmiObject : Invalid query "SELECT * FROM Win32_PerfRawData_PerfOS_Memory"
At line:1 char:1
+ Get-WmiObject -Query "SELECT * FROM Win32_PerfRawData_PerfOS_Memory"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (:) [Get-WmiObject], ManagementException
    + FullyQualifiedErrorId : GetWMIManagementException,Microsoft.PowerShell.Commands.GetWmiObjectCommand


I tried creating another machine again from scratch and it seems there is no problem. There must be something wrong with my original Windows install, so I guess I'll just stick with the new one. 

I'd be happy to provide any more information if you can think of any tests to perform. Otherwise, I'll understand if you just want to close this as "works for me".

Either way I'll update if I see this reappear in the new instance.

Comment 4 Amnon Ilan 2020-07-05 07:55:00 UTC
Closing this bz based on comment#3, but please do report/reopen if it reappears