Bug 1848380 - blnsvr.exe consumes CPU making continuous failed Win32_PerfRawData_PerfOS_Memory queries
Summary: blnsvr.exe consumes CPU making continuous failed Win32_PerfRawData_PerfOS_Mem...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virtio-win
Version: unspecified
Hardware: x86_64
OS: Windows
unspecified
unspecified
Target Milestone: ---
Assignee: Amnon Ilan
QA Contact: xiagao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-06-18 09:26 UTC by Kevin Mitchell
Modified: 2020-07-05 07:55 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-05 07:55:00 UTC
Embargoed:


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.