Nix May 28, 2008 4:36 PM

Yeah, almost catching up, except that you have to reboot and accept a reportedly-large performance hit before the moral equivalent of fuser/lsof works. I don’t understand how this can be expensive data to collect: surely the OS must be tracking it anyway…

Davi Ottenheimer May 28, 2008 4:56 PM

Ha ha ha, “built-in”, as if that is something special.

To use your car analogy, Bruce, I can’t remember anyone telling me to use the “built-in” seatbelt, or the “built-in” brakes.

I can think of some other operating systems with command-line tools that include security features/functions. We don’t refer to them as “built-in” any more than we think of the command line itself as “built-in”. Heck, these OS even include a wait/sleep function so you can write proper security scripts. Wonder why that was never “built-in” for Windows. Skoudis suggests the ever popular “just ping into nul for five seconds” as if it’s normal behavior.

anon May 28, 2008 5:07 PM

@Davi Ottenheimer
Aren’t wait/sleep POSIX? Doesn’t Windows support POSIX to some degree?

If *NIX is your target, then you’re aiming far too low. We can do far better than a security design rooted in the threat models of a non-Internet connected world.

Tangerine Blue May 28, 2008 5:12 PM

Good stuff, Bruce. I’m sure Windows IT pros know this stuff, but I didn’t, and it’s good info. Thanks!

janantha May 29, 2008 12:00 AM

I agree with Pat .. Mark’s utilities are pretty good but most of them are basically a GUI which uses the WMIC stuff under the hood. THere will be situations where u want minimum contamination where CLI is the way. WMIC, Netsh and other CLI stuff are the best way to get info when required. you can directly dump the output using >> to a text file for later inspection

RonK May 29, 2008 12:06 AM

Cool! The WMI interface is provided by all current Windows versions; the WMIC console application was left out of XP Home. However, with OpenPegasus, one can access the WMI info remotely from a Linux box. Of course, to do that one has to do some contortions, like running a mapping proxy on one of the Windows boxes in your network which maps the non-standard WMI transport protocol to a more standard protocol.

It seems that MS is getting more and more conflicted between needing to provide access via standard open protocols (or rather, protocols which can be CALLED standard and open by their marketing guys) and wanting to keep everything locked-in and proprietary.

Ranum Fan May 29, 2008 12:44 AM

I remember when Ed Skoudis first started to collect these WMIC commands a few years ago. The point was to try to find the most information you can with a command line on a Windows machine that you could absolutely not install any new tools on.

NotPosix May 29, 2008 2:33 AM

@anon: “Doesn’t Windows support POSIX to some degree?”

This was misleading marketing statements from Microsoft.

sleep is POSIX.2, and Microsoft said that they would not comply to POSIX.2 because it is not an ISO standard:
The same page explains why Microsoft would not comply to POSIX.N for N=2, 3, …, 12.

In NT, only the kernel is POSIX.1 (basically, it is C calls).

XP and windows 2003 are no more POSIX according to and unless Windows Services for Unix (SFU, or its successor SUA) is downloaded.

Their new tool Powershell is not POSIX either, despite having a misleading name.

You can still have a look at some marketing misleading statements here :

D0R May 29, 2008 2:53 AM

I have always wondered why Microsoft buries these powerful tools (wmic, netsh, gpedit, dxdiag, regedit…) in the deep of Windows. Probably they believe the average user is too dumb to use them and he would make a mess if he knew about them. But for those with a more extensive knowledge of the machine, some documentation would be surely appreciated.

Ulrich Boche May 29, 2008 3:29 AM

Mark Russinovich’s Process Explorer displays all this information in a much more readable fashion. Command line is not always better than a GUI.

And of course I know that Sysinternals is now part of Microsoft.


uberdilligaff May 29, 2008 6:37 AM

@Ulrich: I’m a great fan of Russinovich’s Process Explorer and other GUI tools such as Autoruns, but you know that he has also provided CLI versions of most of his tools, too. You can easily have it both ways.

bob May 29, 2008 7:17 AM

My problem has never been being unable to find a big long list of arcane service names running on my machine; my problem has always been figuring out which of them are needed/useful/legitimate.

merkelcellcancer May 29, 2008 8:51 AM

“My problem has never been being unable to find a big long list of arcane service names running on my machine; my problem has always been figuring out which of them are needed/useful/legitimate.”

BillP Studios WinPatrol 2008 does this and much more on a friendly level that seeks out answers (with the plus version) in a way we can all understand.

Curt Sampson May 29, 2008 12:26 PM

This, for those of us who lived through the GUI vs. command line wars of the late ’80s and early ’90s, is a brilliant quote:

“However, memorizing the obscure locations where Microsoft has buried various controls in its GUI is a bewildering task.

“Fortunately, users don’t have to dig through the GUI to find what they want; instead they can rely on command-line shortcuts.”

Pat Cahalan May 29, 2008 1:05 PM

@ Curt

GUI vs. command line wars of the late 80’s…

You mean the holy wars? Next to distro cult wars or macintosh fanaticism, probably the most pointless argument in personal computing history 🙂

It’s a fantastically crazy argument on both sides. Sometimes you want a GUI (usually, when you want visual representation of data). Sometimes, you want a CLI (usually, when you want optimized command-entry).

Ben Hutchings May 30, 2008 10:51 AM

If you really want to explore WMI then the wbemtest GUI is a lot easier to use than wmic. But having found an interesting class in wbemtest you can read it through wmic or a script. I have a diagnostic script for Windows networking that is written in VBScript (for portability!) and reads just about everything through WMI.

Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.