| Date: | October 21, 2004 / year-entry #372 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20041021-00/?p=37513 |
| Comments: | 35 |
| Summary: | Windows Management Instrumentation is a scriptable interface to configuration information. This saves you the trouble of having to figure it out yourself. For example, here's a little program that enumerates all the CPUs in your system and prints some basic information about them. var locator = WScript.CreateObject("WbemScripting.SWbemLocator"); var services = locator.ConnectServer(); var cpus = new... |
Windows Management Instrumentation is a scriptable interface to configuration information. This saves you the trouble of having to figure it out yourself. For example, here's a little program that enumerates all the CPUs in your system and prints some basic information about them.
var locator = WScript.CreateObject("WbemScripting.SWbemLocator");
var services = locator.ConnectServer();
var cpus = new Enumerator(services.ExecQuery("SELECT * FROM Win32_Processor"));
while (!cpus.atEnd()) {
var cpu = cpus.item();
WScript.StdOut.WriteLine("cpu.ProcessorType=" + cpu.ProcessorType);
WScript.StdOut.WriteLine("cpu.CurrentClockSpeed=" + cpu.CurrentClockSpeed);
WScript.StdOut.WriteLine("cpu.MaxClockSpeed=" + cpu.MaxClockSpeed);
WScript.StdOut.WriteLine("cpu.Manufacturer=" + cpu.Manufacturer);
WScript.StdOut.WriteLine();
cpus.moveNext();
}
Save this program as There's a whole lot of other information kept inside WMI. You can get lost amidst all the classes that exist. The Scripting Guys have their own tool called WMI Scriptomatic which lets you cruise around the WMI namespace. (The Scripting Guys also wrote Tweakomatic which comes with hilarious documentation.) Added 11am: It appears that people have misunderstood the point of this entry. The point here is not to show how to print the results to the screen. (I just did that to prove it actually worked.) The point is that you can let WMI do the hard work of actually digging up the information instead of having to hunt it down yourself. Want BIOS information? Try Win32_BIOS. Change the query to "SELECT * FROM Win32_BIOS" and you can get the manufacturer from the Manufacturer property. Plenty more examples in MSDN. |
Comments (35)
Comments are closed. |
Windows Scripting is great – you can send an email containing a script, and have it send itself out to everyone in the recipients’s address book. Plus it has everyhing you need for install a "remote admin" kit at the recipient – e.g. Filesystem and Registry access. And if you want to just nuke the machine, you can find out enough to do that without getting caught. Can you get access for to the sockets for DDos attacks? That’s the only feature missing IMO.
Just like binary exe’s then!!
The fact that I can use a screwdriver to severely injure anyone I can get within arm’s reach of does not lessen its usefulness as a scewdriver.
I think the real issue is: where is Raymond vacationing this time?
Please don’t feed the troll.
Tim Golden wrote a module to wrap this. It also needs Mark Hammond’s Win32 extension module.
http://tgolden.sc.sabren.com/python/wmi.html
There’s a nifty list of examples at:
http://tgolden.sc.sabren.com/python/wmi_cookbook.html
I stumbled on this when I was trying to enumerate the TCP/IP interfaces for a Windows Box.
If you wish to enumerate the network interfaces, you can just use GetNetworkParams, GetAdaptersInfo and GetNumverOfInterfaces from iphlpapi.dll. It’s pretty straight forward to use and works like a charm.
Brian – I think our troll is just jealous because his favorite OS has nothing like it.
I would venture that the troll’s favorite OS does have the ability to query all that stuff, but it’s just not packaged the same way. Not running a script embedded in an email by default could be argued to be a deliberate design system.
Oh, and to troll a bit on my own, I went looking on msdn, but I couldn’t for the life of me find out how to run a service in a chroot jail.
My favourite OS can query that stuff and with rather less typing:
Welcome to Darwin!
james$ sysctl hw
hw.ncpu: 2
hw.byteorder: 4321
hw.memsize: 1073741824
hw.activecpu: 2
hw.cputype: 18
hw.cpusubtype: 11
hw.pagesize: 4096
hw.busfrequency: 166635063
hw.busfrequency_min: 166635063
hw.busfrequency_max: 166635063
hw.cpufrequency: 999999996
hw.cpufrequency_min: 999999996
hw.cpufrequency_max: 999999996
hw.cachelinesize: 32
hw.l1icachesize: 32768
hw.l1dcachesize: 32768
hw.l2cachesize: 262144
hw.l3cachesize: 1048576
hw.tbfrequency: 41656341
hw.optional.floatingpoint: 1
hw.optional.altivec: 1
hw.optional.graphicsops: 1
hw.optional.stfiwx: 1
hw.optional.dcba: 0
hw.optional.datastreams: 1
james$
Not trolling but it just seems like more work than it needs to be. The SQL style query is cute though!
WMI is a great way of getting data that has been available for 5 to 10 years via SMBIOS or Win32 APIs like GlobalMemoryStatus(Ex). And it can be called from scripts which is a good thing. But it still can’t tell me the temperature of my CPU, or how fast the fans are running, or the power supply voltages, or a lot of other configuration data. I really wish Microsoft would lock the hardware guys in a room at WinHEC and not let them out until they’d agreed to expose that information in a standard way.
Hey, I’ve got an idea – we could make a fake filesystem, where all the info is structured as a bunch of files. You could query the info by typing the file and set parameters by echoing data to the right files. We could give it a friendly name, too. Let’s call it the proc: drive ;)
"I really wish Microsoft would lock the hardware guys in a room at WinHEC and not let them out until they’d agreed to expose that information in a standard way."
Maybe the Linux folks could take the lead here and do this at the next Linux hardware conference?
Video drivers are so complicated these days I prefer to treat them as black boxes that either "work" or "don’t work."
Don’t complain about Linux. We can’t threaten a hardware manufacturer that their products won’t be supported by Linux, they don’t care. Whereas MS carries more weight. (check out the recent video by Alan Cox discussing debugging techniques; they traced a very rare crash to a problem in a certain ATA disk; the disk manufacturer didn’t listen until MS approached them much later about the exact same problem)
I read the tweakomatic documentation some months ago. it really is hillarious you should all check it out:
http://www.microsoft.com/technet/scriptcenter/tools/twkmatic.mspx
Quotes follow:
"Ok, fine, we admit it. Tweakomatic does not do everything TweakUI does. Is that because the Scripting Guys are a bunch of lazy good-for-nothings who couldn’t take their eyes off the TV long enough to add a couple more features to Tweakomatic? In the words of Homer Simpson, Oh, no, no, no, no, no. Well, yes."
[…]
Tweakomatic is Fully Guaranteed and Supported, Right?
Hey, let’s be serious. This thing is called Tweakomatic. Can you imagine this scenario:
“Microsoft Product Support. How may I help you?”
“Uh, yes, I seem to be having some problems with my Tweakomatic.”
[…]
"You want to know the sordid truth about the TweakUI team? Well, actually, we don’t know anything at all about the TweakUI team (although we sure hope they have a sense of humor). So in order to make our point, we’ll make something up instead.
The truth is, the TweakUI team has the cushiest job on the planet. These guys spend all their time at the baccarat tables in Monte Carlo. Every couple years or so, Microsoft releases a new version of Windows, and these guys drain the last of their martinis, stumble out of the casino, hammer out a new version of TweakUI, and then head back to the gaming tables."
Win32_Processor is not available on Windows 95, Windows 98 and Windows ME – which is what about half of our customers still run :(
Cooney: About that fake filesystem, check out Monad over at http://channel9.msdn.com/ShowPost.aspx?PostID=25531. Now, look very carefully at the providers (like filesystems, registry etc.) ;)
"I really wish Microsoft would lock the hardware guys in a room at WinHEC and not let them out until they’d agreed to expose that information in a standard way."
Seems like they already did that, but your computer needs to support that standard. Check out http://www.dmtf.org/standards/wbem/, which is what WMI implements. I know Dell ships an addon for exposing such information, maybe you can find something like that for your computer as well?
Btw. Haven’t tested this yet, but seems like there is an implementation of WBEM for Linux and other operating systems too. See http://www.openwbem.org/. Anyone here who knows more about it?
Finally, a nice quote from the WBEM FAQ of their goal with it: "The ultimate objective is to provide customers with the ability to manage all systems, regardless of their instrumentation type, using a common standard."
Andreas: I’ll check that clip out.
Raymond, why are you posting? I thought you were off on vacation. Can’t you designate a deputy?
James, the SQL queries IS the feature of WMI. For example to get an info about a running process you just run "SELECT * FROM Win32_Process WHERE Name='<process name>’", instead of looking up the PID and then looking up all the information scattered around the system API (which is what you have to do in Win9x and other, non-win systems).
Strangely, I wasn’t able to use other properties in the WHERE clause, only Name worked.
Another nice thing to know about is wmic.exe (on Windows XP, maybe other versions of Windows as well?), which let’s you execute queries without having to write a script or something similar.
See some info about wmic.exe at Don Box’s old blog http://www.gotdotnet.com/team/dbox/default.aspx?key=2004-09-27T12:15:40Z.
"The fact that I can use a screwdriver to severely injure anyone I can get within arm’s reach of does not lessen its usefulness as a scewdriver."
Of course, but the fact that you can use other people’s screwdrivers to cause harm to other people is a bit of a problem.
I agree that the information at http://www.microsoft.com/technet/scriptcenter/tools/twkmatic.mspx is very well presented. I used to consider WMI as one of the "don’t touch" items in Windows, now I’m thinking of using it to automate some monitoring related activities.
Jerry – the SQL stuff does look a nice way of doing things. Having a single port of call for extracting all sorts of information rather than a whole bunch of API calls sounds good to me. (As does Linux’s procfs and BSD’s sysctl namespace ;) )
I had a look to see how far back WMI is supported and was pleasantly surprised to see that MSDN says that WMI is available as a download for 9x so it looks like they can play along too.
"Don’t get too excited. At least on my machine, most of these seem not to be implemented. Try it on your machine. "
Believe me, I’ve tried it on dozens of systems. Those WMI classes are defined, yes, but they don’t give meaningful data.
Incidentally, almost all of the information in msinfo32 can be found in the WMI schema. So things you see there can be retrieved using a script and WMI.
>> If you wish to enumerate the network interfaces…
Those network interface APIs mentioned above are a good example of one reason I try to avoid using WMI when possible. WMI is implemented as a Service, and that service can be turned off.
The Win32 APIs in question cannot be turned off. So if you absolutely require some piece of configuration information for your program to operate properly, I recommend trying to find a straight Win32 API to get it before going to WMI.
That having been said, WMI is a great resource. There are also some things you can do with it that you *can’t* easily do with Win32 APIs, like retrieve Event Log messages from a remote machine *asynchronously* as they occur.
watch out for WMI though, it sometimes doesn’t tell the truth even when the method claims to be implemented on a particular system. Try comparing the values stored in Win32_CPU with the values in HKLM\HARDWARE\DESCRIPTION\System\CentralProcessor\0"
One sure way of determining where a WMI provider gets its information from is through the MappingStrings qualifier.
I’ve just checked through a number of properties on the Win32_Processor management class against what’s in the registry. Many of the properties don’t seem to have documented where the provider gets its values from which is unfortunate. It worth noting that many of the Microsoft management classes have made good use of the MappingStrings qualifier! Just not this class by the looks of it…
If you’re unfamiliar about the MappingStrings qualifier, then check this link (http://www.wbem.co.uk/articles/MappingStrings.pdf) which is a couple of pages I wrote a while ago…
WMI looks neat, but AFAICS the information can’t be accessed from other platforms. So we’re using NRPE for NT. It would be nice if there was a version that ran over HTTP, as specified in the standard.
Cooney: "Hey, I’ve got an idea – we could make a fake filesystem, where all the info is structured as a bunch of files. You could query the info by typing the file and set parameters by echoing data to the right files. We could give it a friendly name, too. Let’s call it the proc: drive ;)"
Isn’t that the way *nix works? ;) Everything is a file.
Any chance this is broken?
I have a bunch of C# code that calls System.Management classes, and I noticed today that none of it is working; I get various exceptions.
So, in hunting down the problem, I found this blog entry. Sure enough, I cannot get this piece of WSH code to run, either.
My main suspects are XP SP2 and .NET Framework 1.1 SP1. Is anyone else having a similar problem? Or have I simply ‘broken’ WMI on my machine somehow?
I was once told that very detailed information is in WMI including numbers of words typed and total applicaiton run time for apps like office but I can not find it. Is there a way that you can dump tons of info from WMI. I looked through the MOF file but could find nothing