Get-ComputerInfo returns empty values on Windows 10 for most of the properties. And it runs slower than on Windows 2016. #3080

Closed
happysysadm opened this Issue Feb 1, 2017 · 38 comments

Projects

None yet

9 participants

@happysysadm

Steps to reproduce

get-computerinfo CsTotalPhysicalMemory

Expected behavior

CsTotalPhysicalMemory : 17179398144

Actual behavior

CsTotalPhysicalMemory :

Environment data

Windows 10 (virtual or physical it is the same)

@SteveL-MSFT
Contributor

@happysysadm what OS version? I just tried it on my Win10 machine and that property has a value

PS C:\> get-computerinfo CsTotalPhysicalMemory

CsTotalPhysicalMemory
---------------------
          25767264256
@happysysadm
happysysadm commented Feb 1, 2017 edited

Steve,

here's a more precise output:

PS C:\> (Get-ComputerInfo).psobject.properties.value
14393.693.amd64fre.rs1_release.161220-1747
6.3
Enterprise
Client

Wednesday, November 2, 2016 4:34:17 PM
00329-10281-56270-XX237
Windows 10 Enterprise
C:\WINDOWS
(UTC+01:00) Brussels, Copenhagen, Madrid, Paris
\\DESKTOP-CASA
Desktop
Off

here's my psversiontable:

Name                           Value
----                           -----
PSVersion                      5.1.14393.693
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.693
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1


OS is Microsoft Windows 10 Enterprise 1607 build number 14393.693.

I am not the only one to have this issue:
reddit post

@SteveL-MSFT
Contributor

@happysysadm can you try this and tell me what you get?

(Get-CimInstance win32_computersystem).TotalPhysicalMemory
@happysysadm

@SteveL-MSFT using gcim I get the correct value in bytes:

PS C:\> (Get-CimInstance win32_computersystem).TotalPhysicalMemory
17049706496
@SteveL-MSFT SteveL-MSFT added this to the 6.0.0 milestone Feb 1, 2017
@SteveL-MSFT
Contributor

@happysysadm Looking at the code, it appears that all get-computerinfo does is query WMI and for that property it simply gets it from win32_computersystem, so I'm not sure why at this time it would be empty for you. Without a consistent repro, this will be hard to debug.

@jeffbi
Collaborator
jeffbi commented Feb 2, 2017

This won't make it much easier to debug without a consistent repro, but we might be able to reduce the number of empty items.

In the generic CimHelper.GetFirst<T> function, during the process of querying WMI and populating the properties of the object built up from the results, any exception thrown will cause the function to return a null value, resulting in all properties of the cmdlet's return value that came from that query to be empty.

In the case in which a single property value is requested, such as CsTotalPhysicalMemory, that could be empty because of a failure when populating either that property or any other property of the object returned when processing the query of win32_computersystem.

If we handled errors at a more granular level, such as in the CimHelper.SetObjectDataMember function, we could allow processing the query results to continue even if processing a particular property/field fails.

Of course, this doesn't address the issue of why it's failing, but it might at least improve the final result.

@thezim
Contributor
thezim commented Feb 2, 2017

@SteveL-MSFT Issue is for PowerShell 5.1. Is this a valid bug for PowerShell 6?

@rodmhgl
rodmhgl commented Feb 2, 2017 edited

I'm seeing this behavior as well.

PS C:\windows\system32> (Get-ComputerInfo).psobject.properties.value
14393.693.amd64fre.rs1_release.161220-1747
6.3
Enterprise
Client

Friday, January 6, 2017 5:55:36 PM
00329-00000-00003-AA690
Windows 10 Enterprise
Company
Compnay User
C:\windows
(UTC-06:00) Central Time (US & Canada)
\\SERVER
Mobile
Off


PS C:\windows\system32> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.14393.693
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14393.693
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

PS C:\windows\system32> (Get-CimInstance win32_computersystem).TotalPhysicalMemory
17118289920
@iSazonov
Collaborator
iSazonov commented Feb 2, 2017

It is working good on latest versions (for Powershell Core too)

PS C:\> Get-ComputerInfo CsTotalPhysicalMemory

CsTotalPhysicalMemory
---------------------
           4186898432


PS C:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.15019.1000
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.15019.1000
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
@happysysadm
happysysadm commented Feb 2, 2017 edited

@SteveL-MSFT and it's painfully slow, compared to win2016 which runs in < 3 seconds.

On windows 10 here's how long it takes:

PS C:\> Measure-Command { Get-ComputerInfo }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 42
Milliseconds      : 177
Ticks             : 421773107
TotalDays         : 0.000488163318287037
TotalHours        : 0.0117159196388889
TotalMinutes      : 0.702955178333333
TotalSeconds      : 42.1773107
TotalMilliseconds : 42177.3107

Could the long execution time be related to the empty values?

@powercode
Collaborator

@happysysadm Have you tried running Windows Performance Recorder to see what is taking so long?

@SteveL-MSFT
Contributor

@jeffbi I like your suggestion on handling errors with more granularity. we should also make use of verbose output to know which ones are failing. can you take care of this? thanks.

@jeffbi jeffbi was assigned by SteveL-MSFT Feb 2, 2017
@rodmhgl
rodmhgl commented Feb 2, 2017

@powercode - I have run Windows Performance Recorder and I have the analysis, but it turns out I have no idea what I'm looking at here.

@SteveL-MSFT
Contributor

@rodmhgl the cmdlet code mostly uses WMI to get the values which is very likely where the time is being spent. Might be worth spending some time reviewing the cmdlet code to see if it's using WMI optimally (for example using select prop1, prop2, prop3 from wmiclass queries assuming the WMI Provider optimizes for this so it doesn't spend time populating the entire instance we end up throwing away). Working on some other issues so no time to do that right now. On my Win10 box, I don't see any perf issue:

PS C:\> Measure-Command { Get-ComputerInfo }


Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 2
Milliseconds      : 906
Ticks             : 29066461
TotalDays         : 3.36417372685185E-05
TotalHours        : 0.000807401694444444
TotalMinutes      : 0.0484441016666667
TotalSeconds      : 2.9066461
TotalMilliseconds : 2906.6461

One thing to try is to temporarily disable any third party virus/malware scanners as I've seen them have big perf impact

@jeffbi
Collaborator
jeffbi commented Feb 2, 2017

The cmdlet does not specify individual properties on the WMI queries. It gathers up everything it can, then checks if individual properties were given as cmdlet parameters.

The request for specifying properties as parameters came after the bulk of the code had already been written. At the time, the decision was made to keep the code intact and handle user-specified properties after gathering the data

@jeffbi
Collaborator
jeffbi commented Feb 2, 2017

@SteveL-MSFT What is the preferred method for indicating failure when setting a property? WriteVerbose, WriteDebug, WriteWarning, other? And do you want to include the exception's message in the output?

@thezim
Contributor
thezim commented Feb 2, 2017

@powercode Can you try this to to see if WMI itself is the bottle neck. Run this in a cmd.exe process.

wmic /namespace:\\root\cimv2 path win32_computersystem
@SteveL-MSFT
Contributor

@jeffbi I think WriteVerbose is fine to tell the user something wasn't collected, probably use WriteDebug for the exception message

@rodmhgl
rodmhgl commented Feb 2, 2017

@thezim - on my system that wmic command completes almost instantly. Get-ComputerInfo (with the blank results) is around 45 seconds.

@jeffbi
Collaborator
jeffbi commented Feb 2, 2017

@SteveL-MSFT Telling the user something wasn't properly collected will really call out the fact that the cmdlet is collecting everything even if only a particular property was requested. Do we want to do that?

Using more granular error handling is trivial. Writing a message is somewhat less so since CIMHelper is a static class with no access to the cmdlet object. I can change that of course, but it will require additional changes throughout the cmdlet.

@SteveL-MSFT
Contributor

@jeffbi If every property is a parameter, we should probably optimize it so we only collect information the user explicitly requests. Let's start with just the granular error handling and treat the verbose/debug output as a separate issue.

@iSazonov
Collaborator
iSazonov commented Feb 3, 2017

If we plan to port this cmdlet then it makes sense to replace the WMI calls to a direct system/registry calls.

@happysysadm
happysysadm commented Feb 3, 2017 edited

@thezim in my case wmic completes at the speed of light.

I agree with @jeffbi on the fact that there is no need to collect everything when one just asked for

get-computerinfo CsTotalPhysicalMemory

Also I want to point out that on the tested systems I don't run any third part AV or antispyware.
I agree with @SteveL-MSFT that it's hard to find out what is breaking the information flow, so if you have any idea on things I could collect and share with you, just let me know.

@powercode
Collaborator

@happysysadm @rodmhgl If you can share the file, I can try to see if I can understand what is going on.

@happysysadm

@powercode can you please explain what file you are asking for?

@powercode
Collaborator

@happysysadm I was thinking of the recording you made in Windows Performance Recorder.

@happysysadm

@powercode that file is huge (more than a gig) and most of the events are for some reason empty. Nonetheless there are a bunch of event id 80 like the one below:

ExceptionType=Microsoft.Management.Infrastructure.CimException;
ExceptionMessage=The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: "winrm quickconfig".;
ExceptionEIP=0x7ffbe4508df8;
ExceptionHRESULT=0x80131500;
ExceptionFlags=CLSCompliant;
ClrInstanceID=36

Apart from those, have you got something in particular I should look for? Looking for ideas...

@rodmhgl
rodmhgl commented Feb 6, 2017

@happysysadm Eureka! Enabling WinRM (winrm quickconfig) fixed the issue for me. Get-ComputerInfo is now returning all properties and completing in 3.7s.

@happysysadm
happysysadm commented Feb 6, 2017 edited

@rodmhgl oh c'mon I never thought of this for a cmdlet like get-computerinfo that doesn't even support Remoting. I'll give it a try as well and keep posted.

@happysysadm

@rodmhgl you were right. Just run enable-psremoting and get good values back from this cmdlet. Seems like a big bug though...

@MaximoTrinidad

Just an FYI

Get-ComputerInfo apparently work on Windows 10 Insider Preview latest Build 15007.rs_prerelease.170107-1846

getcompinfo_01_2017-02-06_15-31-22
getcompinfo_02_2017-02-06_15-31-22

@jeffbi
Collaborator
jeffbi commented Feb 6, 2017

Odd. On one of my boxes (Windows 10 Pro, 10.0.14393 PS version 5.1.14393.693) all the CIM-based properties were empty until I ran winrm quickconfig, then all of them worked.

On another box, same OS and PS versions, I get everything except the Win32_ComputerSystem properties. Yet Get-CimInstance Win32_ComputerSystem works.

I'm investigating the differences between the two cmdlets

@happysysadm

@MaximoTrinidad is winrm up and running on your win10 box?

@SteveL-MSFT
Contributor

The perf difference when WinRM is not configured for remoting is likely due to waiting multiple times for the http timeout. This cmdlet should not require remoting as the calls are being made to the local machine.

@rkeithhill
Contributor
rkeithhill commented Feb 7, 2017 edited

@rodmhgl Same here on my Windows 10 Insider build 15025 - takes ~45 seconds to run this command. Running winrm quickconfig brings it down to 4.6 seconds for me.

@SteveL-MSFT
Contributor

@jeffbi found the issue, the cmdlet is passing localhost as the computername which (by design) goes through the winrm remoting stack. The cmdlet should be passing null instead to indicate it is a local call.

@MaximoTrinidad

@happysysadm
My winrm is running in my box and "get-computerinfo" took 4 secs to execute.
getcompinfo_03_2017-02-06_15-31-22

@jeffbi jeffbi added a commit to jeffbi/PowerShell that referenced this issue Feb 7, 2017
@jeffbi jeffbi Fix #3080
Pass null rather than "localhost" to CimSession.Create
a316521
@happysysadm

Thanks @jeffbi for the quick fix.

@mirichmo mirichmo closed this in #3107 Feb 8, 2017
@mirichmo mirichmo added a commit that referenced this issue Feb 8, 2017
@jeffbi @mirichmo jeffbi + mirichmo Fix #3080 (#3107)
Pass null rather than "localhost" to CimSession.Create
7ba3b50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment