On IRC today a guy was getting the error shown at right. Now usually you’d say “check out the System Event Log, resolve whatever you find there, and get on with life!”
But he had done that – and there were no service failure errors to be found. So someone came up with the bright idea of running the command SC queryex state= all. (Documented here, until MS gets around to replacing the missing page here.) And within that output, on line 1851, we found that the driver Parport (Parallel port driver) had failed with exit code 1058. net helpmsg 1058 revealed that “The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.”
That’s when the guy remembered that a PATA drive (parallel ATA, get it?) had been disabled. He re-enabled it and dialog box stopped bothering him (and his Terminal Services users) at boot/logon.
Which is all fine and dandy, but it took some eyes bleeding to read through 1850 lines (out of over 3200!) very repetitive sc queryex output to find this little issue. What could have saved a lot of that effort? WMI, of course!
A nice thing about WMI is that you can query on specific properties of objects like this. Using the Win32_BaseService class, he could have run a query like this: wmic path win32_baseservice where (exitcode != 0) get exitcode, name, state, status
We know from net helpmsg 1077 that exitcode 1077 means “No attempts to start the service have been made since the last boot,” so we can discount all those 1077 entries. We can even write a query to exclude them: wmic path win32_baseservice where (exitcode != 0 and exitcode != 1077) get exitcode, name, state, status
Of course, in my case that query returns nothing:
The same query can be done, with slightly different syntax, in PowerShell:
But in his case, either method of performing the query would have returned precisely the items he wanted to see. And none of us would have had to painstakingly read those 1850 lines of boring, repetitive sc queryex output.
The downside of WMI queries, especially for those of us who remember all of the old commands in the cmd shell, is that the WMI namespace is so large. And writing queries in WQL often means we have to stop and think a moment – or worse, go look something up. And we often want to admin our systems like we want to drive cars: forward motion is better than standing still, even if we have to take the longer route just to preserve that forward motion!
But give WMI a try. It’s quite powerful, and it can get you there faster, if you give it a chance.
Some reference links:
- The Grammar of WMIC
- WMIC - Take Command-line Control over WMI (a pretty good tutorial)
- WMIC Examples 1, 2, 3, 4, 5
- WMIC Best Practices - Syntax - Verbs – Switches
- WQL – Operators
- WMIC Scripting Primer part 1, 2
- WMI Tools download includes CIM studio, Object browser, others
- WMI Scriptomatic - this is for writing vbscripts using WMI, but handy anyway
- The Win32 Classes define most of the objects you'll need to query outside of the base WMIC aliases.
- WMIC Snippets (wrote this one myself)
- PowerShell WMI Snippets (still under construction)
