WMI and boolean values from Win32_Processor

[Daniel Berger]

Hi all,

A.S. Perl 5.8.1
Windows 2000

I noticed that when using Win32::OLE + WMI, the boolean return values
from the Win32_Processor class return undef instead of a value.

Relevant link (select Win32_Processor on the left frame):
http://msdn.microsoft.com/library/d...isdk/wmi/computer_system_hardware_classes.asp

Example code:

use strict;
use Sys::Hostname;
use Win32::OLE qw(in);

my $host = hostname();

my $cs = "winmgmts://$host/root/cimv2";
my $wmi = Win32::OLE->GetObject($cs);

my $cpu_set = $wmi->InstancesOf("Win32_Processor");
foreach my $cpu(in($cpu_set)){
print "Name: [", $cpu->{'Name'}, "]\n";
print "Error Code: [", $cpu->{'ConfigManagerErrorCode'}, "]\n";
print "Description: [", $cpu->{'Description'}, "]\n";
print "Error Cleared?: [", $cpu->{'ErrorCleared'}, "]\n";
}

# Output:
Name: [AMD Athlon(tm) XP 2800+]
Error Code: []
Description: [x86 Family 6 Model 10 Stepping 0]
Error Cleared?: []

The ConfigManagerErrorCode and ErrorCleared attributes (among others)
are of type boolean. I would expect a 0 or 1 for these attributes,
not undef. Or is it understood that undef == false? Or is a WMI
issue? I didn't see anything in the Win32::OLE docs that specifically
mentioned this.

Regards,

Dan

 

[Anno Siegel]

Hi all,

A.S. Perl 5.8.1
Windows 2000

I noticed that when using Win32::OLE + WMI, the boolean return values
from the Win32_Processor class return undef instead of a value.

What makes you think the return values are undefined?

Relevant link (select Win32_Processor on the left frame):
http://msdn.microsoft.com/library/d...isdk/wmi/computer_system_hardware_classes.asp

Example code:

use strict;

I don't see "use warnings". Switching on warnings is the easiest way
to make actual undef's stand out.

use Sys::Hostname;
use Win32::OLE qw(in);

my $host = hostname();

my $cs = "winmgmts://$host/root/cimv2";
my $wmi = Win32::OLE->GetObject($cs);

my $cpu_set = $wmi->InstancesOf("Win32_Processor");
foreach my $cpu(in($cpu_set)){
print "Name: [", $cpu->{'Name'}, "]\n";
print "Error Code: [", $cpu->{'ConfigManagerErrorCode'}, "]\n";
print "Description: [", $cpu->{'Description'}, "]\n";
print "Error Cleared?: [", $cpu->{'ErrorCleared'}, "]\n";
}

# Output:
Name: [AMD Athlon(tm) XP 2800+]
Error Code: []
Description: [x86 Family 6 Model 10 Stepping 0]
Error Cleared?: []

The ConfigManagerErrorCode and ErrorCleared attributes (among others)
are of type boolean. I would expect a 0 or 1 for these attributes,
not undef. Or is it understood that undef == false? Or is a WMI
issue? I didn't see anything in the Win32::OLE docs that specifically
mentioned this.

It is standard Perl practice to return 1 for boolean true, but an
empty string[1] for false. It is still a defined value. So your
result is consistent with normal behavior. I suppose that is the
case.

However, in the absence of warnings, you could be right, and some
of the values could indeed be undefined. To check this, switch on
warnings, or do something like

die 'boo' unless defined $cpu->{'ConfigManagerErrorCode'};

[1] The empty string returned for boolean false isn't just any empty
string. It also has a numeric value of 0, so you can add to it
(or index with it, or otherwise use it as a number) with impunity.
It is one of the janus-headed scalars Perl has up its sleeve, and
it is as correct to say that the value is 0 which happens to have
a string value of ''. Other such two-sided scalars are supplied
by the system variable $!.

Anno

 

[Daniel Berger]

What makes you think the return values are undefined?

When I 'use warnings', I know for sure. It is definitely
undefined.

The ConfigManagerErrorCode and ErrorCleared attributes (among others)
are of type boolean. I would expect a 0 or 1 for these attributes,
not undef. Or is it understood that undef == false? Or is a WMI
issue? I didn't see anything in the Win32::OLE docs that specifically
mentioned this.

It is standard Perl practice to return 1 for boolean true, but an
empty string[1] for false. It is still a defined value. So your
result is consistent with normal behavior. I suppose that is the
case.

As I mentioned, it's definitely undefined. In fact, I made a mistake
with my sample code. The 'ConfigManagerErrorCode' is an integer in
the range 0 to 31 but it, too, is coming back undefined. I tried the
same code on my WinXP Home laptop, but they were also undefined.

So, either they're only defined in XP Pro and later or there's a bug
in WMI (or just the WMI documentation). That, or Win32::OLE is broken
somehow. If that's the case, it's broken in the same way in Ruby's
win32ole package (which I also tested with).

Anyway, thanks for the tip.

Regards,

Dan

 

[Petri]

So, either they're only defined in XP Pro and later or there's a
bug in WMI (or just the WMI documentation).
That, or Win32::OLE is broken somehow.

There are whole sections in MSDN that only exist on MSDN...

List the names of the properties that really exist:
---8<---
Set objClass = GetObject("winmgmts://./root/cimv2:Win32_Process")

WScript.Echo strClass & "Class Properties:"
WScript.Echo "------------------------------"

For Each objClassProperty In objClass.Properties_
WScript.Echo objClassProperty.Name
Next
---8<---

My apologies for the VBScript to all you poor readers of clpm, but I simply
don't know how to do this enumeration in Perl.


Petri

 

[Daniel Berger]

There are whole sections in MSDN that only exist on MSDN...

List the names of the properties that really exist:
---8<---
Set objClass = GetObject("winmgmts://./root/cimv2:Win32_Process")

WScript.Echo strClass & "Class Properties:"
WScript.Echo "------------------------------"

For Each objClassProperty In objClass.Properties_
WScript.Echo objClassProperty.Name
Next
---8<---

My apologies for the VBScript to all you poor readers of clpm, but I simply
don't know how to do this enumeration in Perl.


Petri

Your VB led me to the Perl. They definitely exist as properties. See below.

use strict;
use warnings;
use Sys::Hostname;
use Win32::OLE qw(in with);

my $host = hostname();
my $cs = "winmgmts://$host/root/cimv2:Win32_Processor='cpu0'";
my $wmi = Win32::OLE->GetObject($cs);

foreach my $p(in($wmi->Properties_)){
print $p->{'Name'}, "\n";
}

# Output
AddressWidth
Architecture
Availability
Caption
ConfigManagerErrorCode
ConfigManagerUserConfig
CpuStatus
CreationClassName
CurrentClockSpeed
CurrentVoltage
DataWidth
Description
DeviceID
ErrorCleared
ErrorDescription
ExtClock
Family
InstallDate
L2CacheSize
L2CacheSpeed
LastErrorCode
Level
LoadPercentage
Manufacturer
MaxClockSpeed
Name
OtherFamilyDescription
PNPDeviceID
PowerManagementCapabilities
PowerManagementSupported
ProcessorId
ProcessorType
Revision
Role
SocketDesignation
Status
StatusInfo
Stepping
SystemCreationClassName
SystemName
UniqueId
UpgradeMethod
Version
VoltageCaps

So, it looks like they're simply not defined, at least not yet, though I'm guessing.

Regards,

Dan

 

[Petri]

Your VB led me to the Perl. They definitely exist as properties.
See below.

# Output

ConfigManagerErrorCode
ErrorCleared

Er, these two do NOT appear on either my WinXP or Win2K box using the VBscript
code.
Both boxes have WSH V5.6 and the latest service packs and hotfixes.

But the disturbing thing is, they DO appear when running the Perl code.
I don't even know how that's possible.

So, it looks like they're simply not defined, at least not yet,
though I'm guessing.

Who knows what's going on here...

Good job figuring out the Perl translation by the way.
I got thrown off course by that underscore after Properties.
Never figured it was part of the name, I just thought it was used as VB's line
concatenation or whatever, since it was the last character on the line.


Petri

 

[Daniel Berger]

Er, these two do NOT appear on either my WinXP or Win2K box using the VBscript
code.
Both boxes have WSH V5.6 and the latest service packs and hotfixes.

But the disturbing thing is, they DO appear when running the Perl code.
I don't even know how that's possible.


Who knows what's going on here...

I searched around a bit more on Google and the only clue I came across
was the possibility that some of these attributes depend on your BIOS
or BIOS settings, and so some values for certain attributes may come
back undefined. Seems reasonable, though I'm not 100% sure of it.

Anyway, thanks everyone for their time and help.

Regards,

Dan