Last month, in "The All-Purpose Service Controller" (InstantDoc ID 93400), I gave you a taste of SC (sc.exe), the powerful Windows command-line tool for controlling services. This month, let's take a crack at just one of SC's subcommands—the one that lets you create new services. In the process, we'll gather some details about how services work that you might not know.
Give It a Try
Suppose you want to install a new service that grabs images from a Web cam every few minutes and emails them to a certain address. This service was free, and it wasn't well documented. All you know is that the service is called wcmail.exe, and you've downloaded it to C:\wc\wcmail.exe. The simplest SC setup command is
sc create Webimagemailer binpath= C:\wc\wcmail.exe
to which SC would respond with the terse message \[SC\] CreateService SUCCESS.
This command accomplishes several tasks. First, it creates a subkey in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services called Webimagemailer. Inside that subkey, SC creates further subkeys named Enum and Security—subkeys that most services have. Inside these subkeys are a number of configuration options that SC sets, but you'll have the opportunity to fine-tune them later. One of these options, ImagePath, contains the service's location, which we fed to SC through the binpath= parameter. (SC is strange about its parameters, in this case requiring a space between the equals sign and the parameter.)
Investigating the Microsoft Management Console (MMC) Services snap-in reveals that you now have a service called Webimagemailer—a manual startup service running under the LocalSystem account. You could have used the start= parameter—which takes boot, system, auto, demand (the SC phrase for manual startup,) or disabled—to configure the startup setting. Similarly, you could have used the obj= username parameter to control the account under which SC runs. Also, you might be very security conscious and not want a service that you don't know very well running under the Local-System account, so you could craft an account called, say, webcamguy with a password of swordfish and just the permissions it needs to let wcmail.exe get the job done—but no more. And while you're at it, the name Webimagemailer looks a bit ungainly in the Services snap-in. By using the displayname= "descriptive name" option, you can make it look more attractive in the list of services.
Try Again
OK, so you want to try creating an improved command that works better for you. To delete your first try and make room for the second, type
sc delete Webimagemailer
That command marks the service for deletion; you'll have to reboot for it to take effect. Now, you can add your new startup type, service account, and display name:
sc create webimagemailer binpath= C:\wc\wcmail.exe start= auto displayname= "Web cam image mailer" obj= .\webcamguy password= swordfish
Remember to leave that space after the equals sign, or you'll find SC infuriating.
Now, Fine-Tune It
Suppose the service works fine, but it's got an annoying, intermittent habit. If you disconnect the Web cam from the computer for some reason and forget to reconnect it, you get that irritating At least one service or driver failed during startup message every time you boot the computer. The Web cam service is nice, but it's not so important that you need incessant reminders that there's no Web cam. So, it would be nice to suppress that message.
You can use the error= parameter to do that. Windows watches how services start up, and you can configure the OS's response to failed startups in four ways: normal, the default option, displays the message and starts Windows normally; ignore, the option you want, just puts a note in the event log; severe recognizes the importance of the service or driver and triggers the OS to reboot to the Last Known Good configuration; and critical triggers Windows to reboot to the Last Known Good configuration but to bluescreen the system if the driver or service still won't load.
So, delete the service, reboot, add the error= ignore parameter, and everything should be fine—at least, until you realize that you need to work out a certain dependency problem. But that's fodder for next month's column.
