(888) 881-CORE
I installed my program as a Windows Service using the SC command. The result was “CreateService SUCCESS”, and my service is listed with all the others so I know it worked.But whenever I try to start the service, the NET command fails with “The service is not responding to the control function”. What does that mean? Why can’t I start the service?
— Marc B.
Hi Marc.
You are running into a common problem with the SC utility. While SC will happily install any script, batch file or executable as a service, the service it creates may not be usable!
Let’s dig into the details.
SC is not picky; it will install anything as a service
As you have discovered, the “SC CREATE” command will create a new Windows Service. The command line must look like this:
SC CREATE <SERVICE-NAME> binpath= "<FULL-PATH-TO-PROGRAM>"
(Yes — the space after “binpath=” is required!)
Apparently all you need to specify is a friendly name and the full path to your program for SC to work it’s magic. Simple, right?
For example, to install the Windows Notepad application as a service called “NotepadService”, run this command from an administrative command prompt:
SC CREATE NotepadService binpath= "C:\Windows\Notepad.exe"
SC will confirm success:
And the new service will be listed in the Services application:
But there are limits to what SC will do. Even as it dutifully performs the basic operations — creating the necessary entries in the Windows Registry — SC will not validate the path/program in any way. This means that:
- SC will succeed even if the program does not exist. You can give it a bogus path and see:
However, the following error pops up when you try to start the “BadPath” service installed above:
- SC will succeed even if the program cannot run. For example, here we have installed a ridiculous service where the path is an MP3 music file:
Indeed, as an MP3 is not a valid application, it is no surprise that attempting to start the service results in failure:
So, as we have shown, SC is firmly focused on basic installation — not operation. The fact that a service was created with SC does not mean that the service can ever start or run.
Only a “true” Windows Service Application can be started as a service
Even though SC will install any program as a service, the reality is that only specially constructed executables can actually operate as a service. We call those Service Applications.
Service applications implement the Windows Services API — a set of operations used to control and monitor services. Windows uses the API to interact with Service Applications.
The API is quite extensive. With it, Windows can command any Service Application to:
- start running
- stop running
- report status
- pause
- resume running
- prepare for system shutdown
Unfortunately regular desktop applications (like Microsoft Word, Google Chrome and Adobe Acrobat Reader) do not support the Windows Services API. They are not Service Applications. There is simply no way for Windows to directly control or interrogate any of those desktop programs as a service.
Non-Service Applications will fail to start, citing error 1053
To illustrate, let’s take Dropbox — a leading cloud storage provider. The company produces Dropbox.exe, a desktop application that synchronizes files between your PC and the cloud. Dropbox.exe is not a service application.
As you can see, SC has no problem installing Dropbox as a service:
But when you try to start the Dropbox Service from the Services application, a curious scenario plays out:
- Windows starts Dropbox.exe.
Here you can see Dropbox (and its two helper processes) running in Process Explorer:
- Next, the Service Control window will report that “Windows is attempting to start” the service:
- And after about 30 seconds, the Dropbox.exe processes vanish from the system and Error 1053 is raised:
Even though Windows kicked off Dropbox.exe as intended, the process was terminated in less than 40 seconds. A clear failure.
And the story is the same with other regular, non-service applications as well. They all misfire in the same way.
Why did the Dropbox service fail to start?
The problem occurs in step 2.
After launching Dropbox.exe (step 1), Windows waits for the new process to report its status and confirm that the service has started properly. However, since Dropbox does not support the Windows Services API, it fails to respond to that service-specific status check.
And after a few seconds of lingering, Windows eventually gives up. It terminates the Dropbox.exe process (and all its sub-processes) and reports that “the application did not respond to the start or control request in a timely fashion” (i.e. error 1053).
Use a “Service Wrapper” to install a regular program as a Windows Service
As demonstrated above, you cannot simply install a regular application with SC and expect the service to work. You need help from a special “go-between”.
A service wrapper is a Service Application that starts and stops another application in response to important events. When a service wrapper receives a Windows Services API request, it acknowledges the request and performs the appropriate action on the application it is managing.
For example, let’s say that we have a service wrapper configured to manage Notepad. When the service wrapper receives a “start the service” request, it would start a new instance of Notepad.exe and let Windows know that the service was started successfully.
And when the service wrapper receives a “stop the service” demand, it would terminate the Notepad process it started before exiting itself.
Perhaps the best known service wrapper is Microsoft’s Srvany. Srvany is free and functional, but has some significant shortcomings.
Alternatively, our AlwaysUp utility is a professional service wrapper. It’s not free, but is robust and mature, and makes running your application in the background as a Windows Service super easy.
