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.