WMIC Wildcard Search using like and %

This is a quick post to provide some detail on using the wildcard search for WMIC.  This feature of the command structure will allow you to use like conditions in a where clause to look for objects that match a specific pattern.  For those of you comfortable with the SQL syntax for the same task, this will be quite familiar.

Background – Regular WHERE clause

First, let’s look at using WMIC without wildcards for comparison.  All of the statements below are run while at the WMIC command prompt.  To get to the WMIC command prompt, simply go to a Windows command window and type WMIC.

Command to show you all of your services

  • service

Command to show you all of your services that are running

  • service where state=”Running”

Command to show you specific data about your services that are running

  • service where state=”Running” get Name, DisplayName, PathName, ProcessID

Filtering it Down – the LIKE Operator

So you’ll notice that the list of services you have running is a bit difficult to sift through as there are a lot of them.  You can always export this list to a text file by calling WMIC with that command line and piping to a text file, but when you are looking for a specific set of data, I like elaborating on the where clause.  The key thing to keep in mind here is that you need to enclose the full where clause in double quotes to keep it as a single string.  As you’ll notice above, it is possible to use state=”Running” by just not using any spaces in the clause, however that doesn’t work with like.

For example, this will not work

  • service where PathNamelike”%SQL%” get Name, DisplayName, PathName, ProcessID

But this will

  • service where “PathName like ‘%SQL%'” get Name, DisplayName, PathName, ProcessID

The body of the where clause needs to be wrapped in quotes to make it a contiguous statement that does not get confused as multiple arguments.  There are a couple of interesting conveniences that should be noted about WMIC in general

  1. Using single or double quotes seems to be largely interchangeable
  2. Keywords and commands are not case sensitive

So the trick is that you need to use a slightly different and more complex syntax in order to use the like and % functionality.  Taking this command syntax full circle, you can use the more complex syntax all of the time to avoid confusion

  • service where “state = ‘Running'”

Using this wildcard filtering functionality is one of the most powerful uses of WMIC that applies to your everyday tasks.  You can combine this with the other powerful WMI functionality such as killing processes, starting or stopping services, etc.  So if you wanted to stop all of the services on your server that are running a particular application (we’ll say Widget.exe), you could do something like this:

  • service where “PathName like ‘%Widget.exe%'” call StopService

WMIC continues to be very useful in my work, so I hope you find this post helpful in your activities!

VSS Labeling Problem – File $/path/ is already open

Recently, while using the source control system that everyone hates (but seems to continue to use), I was trying to apply a label and got the following error:

image

The path name blurred to protect intellectual property, but this was a path in VSS, not a file.  When trying to apply a label to the folder I got this message.  I noticed that it seemed to happen on certain folders, but not others.  For the folders it did occur on, it would say image down in the status bar for about a minute before coming back with this error. 

This may or not help you, but I will share the steps I used to resolve this error.

  1. The first important step to resolving this issue was narrowing it down to the specific folder where this problem was occurring.  In my case, this was simply trial and error of applying labels at each folder until I honed in on the culprit.
  2. Next, check out all of the files in that folder.  In my case, there were about 2 dozen files.  When checking them all out, I got a message in the status bar that was suspicious:

Could not checkout local version of $/<path>/<filename>, checking out latest version instead.

So at this point, I tried checking the file out and back in with no change in the behavior.  My problem still persisted and I was not able to label that file or any parent folder of that file.  Arrrrgghh!

So while I have narrowed it down, no solution yet.  Please contribute any comments or resources you have that may help here.  I’ll continue to investigate and will likely be running SS ANALYZE next…