PC Review
Forums
Newsgroups
Windows XP
Windows XP WMI
Win32_Processor.Name versus Win32_Processor.Family
Forums
Newsgroups
Windows XP
Windows XP WMI
Win32_Processor.Name versus Win32_Processor.Family
![]() |
Win32_Processor.Name versus Win32_Processor.Family |
|
|
Thread Tools | Rate Thread |
|
|
#1 |
|
Guest
Posts: n/a
|
I see some inconsistencies between Win32_Processor.Name and
Win32_Processor.Family, and I would like to understand if this behavior is intentional or a bug in WMI. * I have a machine at home where Win32_Processor.Name is reported as "AMD Athlon(TM) XP 1900+" but the Win32_Processor.Family is reported as a value of 29, which is supposed to be "AMD Duron". I thought in this case the processor family would return value 28 for "AMD Athlon". I realize there may be something in the relationship between these two processors I simply don't understand, so I ask - is this the correct behavior? Is it a bug or by design? I wonder if, possibly, the two values are backwards in the MSDN documentation... * Here at work I have a Pentium-4 where Processor.Name gets returned as "Intel(R) Pentium(R) 4 CPU 2.40GHz", but the Win32_Processor.Family comes back with a value of 2, or "Unknown". Is there supposed to be a processor family which maps to the newer Pentium-4 processor? According to the MSDN docs, a value of 178 is supposed to be Pentium 4. Is it a bug or by design that the processor family is returned as "Unknown" ? This particular CPU is a Xeon. Here is a snippet of the code: szComputerName = "." set WMIService_CIMV2 = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & szComputerName & "\root\cimv2") set ProcessorSet = WMIService_CIMV2.ExecQuery ("select * from Win32_Processor") for each Processor in ProcessorSet Name = LTrim(Processor.Name) if (Right(Name, Len(" processor")) = " processor") then Name = Left(Name, Len(Name) - Len(" processor")) Family = Processor.Family WScript.Echo Processor.Name WScript.Echo Processor.Family next set ProcessorSet = Nothing set WMIService_CIMV2 = Nothing Thanks, David Holcomb |
|
|
|
#2 |
|
Guest
Posts: n/a
|
David Holcomb wrote:
> I see some inconsistencies between Win32_Processor.Name and > Win32_Processor.Family, and I would like to understand if > this behavior is intentional or a bug in WMI. Hi It looks like the Win32_Processor.Family property is not to be trusted, it does not return correct numbers in many cases (even for old processor families known when Win2k or WinXP was released). Some threads about this and some code that uses Win32_Processor.Description instead to detect CPU family: http://groups.google.com/groups?thr...8%40tkmsftngp11 http://groups.google.com/groups?thr...ilea.materna.de http://groups.google.com/groups?thr...8%40tkmsftngp11 For an up-to-date Intel Processor Identification listing that script examples above uses, take a look here: http://groups.google.com/groups?sel...FTNGP09.phx.gbl Alternatively, use PSInfo.exe (supports remote computers also). PSInfo.exe is in the in the free PsTools suite found at http://www.sysinternals.com/ A VBScript example that picks up the processor type from PSInfo.exe: '--------------------8<---------------------- Const OpenAsASCII = 0 Const FailIfNotExist = 0 Const ForReading = 1 sExe = "F:\sysinternals\Pstools\Psinfo.exe" Set oShell = CreateObject("WScript.Shell") Set oFSO = CreateObject("Scripting.FileSystemObject") sTempFile = oShell.ExpandEnvironmentStrings("%TEMP%\") & oFSO.GetTempName oShell.Run "%comspec% /c " & sExe & " ""Processor type"" -c >" _ & sTempFile, 0, True Set fFile = oFSO.OpenTextFile(sTempFile, ForReading, _ FailIfNotExist, OpenAsASCII) sResult = fFile.ReadLine fFile.Close oFSO.DeleteFile(sTempFile) aResult = Split(sResult, ",") WScript.Echo "Processor type: " & aResult(1) '--------------------8<---------------------- -- torgeir, Microsoft MVP Scripting and WMI, Porsgrunn Norway Administration scripting examples and an ONLINE version of the 1328 page Scripting Guide: http://www.microsoft.com/technet/sc...er/default.mspx |
|
![]() |
|
| Thread Tools | |
| Rate This Thread | |
|
|

Main Page 

