I was recently tasked with figuring out why a seemingly correct call to sc.exe wasn’t working. This turned into an exercise in frustration as I tried the command about 50 different ways. This is close, but not close enough:
** Don’t do this—it doesn’t work (keep reading) **
C:\>sc.exe create ServiceName binpath="C:\Path\Service.exe -args"
depend="tcpip"
DisplayName="Service Name"
DESCRIPTION: Creates a service entry in the registry and Service Database.
USAGE: sc <server> create [service name] [binPath= ] <option1> <option2>...
OPTIONS:
NOTE: The option name includes the equal sign.
type= <own|share|interact|kernel|filesys|rec>
(default = own)
start= <boot|system|auto|demand|disabled>
(default = demand)
error= <normal|severe|critical|ignore>
(default = normal)
binPath= <BinaryPathName>
group= <LoadOrderGroup>
tag= <yes|no>
depend= <Dependencies(separated by / (forward slash))>
obj= <AccountName|ObjectName>
(default = LocalSystem)
DisplayName= <display name>
password= <password>
It unhelpfully just dumps the usage information without telling me what I did wrong. After screwing around with it for far too long, I finally figured it out. It says that each “option name includes the equal sign”, but it also includes the space after the equal sign.
It turns out that a literal, precise interpretation of the command line arguments is needed:
C:\>sc.exe create ServiceName binpath= "C:\Path\Service.exe -args" depend= "tcpip" DisplayName= "Service Name" [SC] CreateService SUCCESS
Obvious, right? :/ I’m sure the devs have their reasons for this unusual parsing requirement but it’s definitely a big usability fail.
Interestingly, while preparing this post I learned that the help info has been improved in Windows 7 and Windows Server 2008:
NOTE: The option name includes
the equal sign.
A space is required between
the equal sign and the value.
So I guess now it’s documented, but still a usability fail.
