Introduction to NT Services
At system boot, Windows NT/2K starts an RPC server called as the Service Control Manager (SCM). An NT service is basically a win32 program that is loaded by the SCM. They are loaded before any user has logged into the system. Services may sometimes be manually started instead of getting started automatically at boot time. It was quite recently that I made my first attempt at writing an NT service and I found to my chagrin that very little information was available for a service-newbie. Even on Code Project I could only find wrapper classes which was not what I wanted.
This article gives you a generic service skeleton which you can use as a starting point when you write your first service. The service does nothing basically. I found a couple of examples on the net both of which were called beeper services because that's what they did. They beeped the system speaker at regular intervals. I thought I'd do the same for my skeleton service because that seems to be the easiest way to give an indication that the service is up and running.
The main function
I have written my service as a console application and therefore the main function. But I presume there is nothing stopping you from writing your service as a GUI application with a WinMain but since I haven't tried it out yet, I won't delve too much into that. All that the main function does is to call
StartServiceCtrlDispatcher to connect the main thread of our service to the SCM. We simply fill up the
SERVICE_TABLE_ENTRY structure and call
StartServiceCtrlDispatcher passing the
SERVICE_TABLE_ENTRY structure as a parameter.
strServiceName is the name of our service. We also pass a pointer to our
ServiceMain function. I used the name
ServiceMain thinking that, that was mandatory, but later on I realized that you can use any name you want to use. Rather silly of me to think so, I guess. Members of the final entry in the table must have NULL values as an indication that this is the end of the table.
StartServiceCtrlDispatcher is a straightforward thing as you can see. Simply pass a pointer to a
SERVICE_TABLE_ENTRY array. If
StartServiceCtrlDispatcher fails it returns false immediately, otherwise it will return only after our service has terminated. Very recently I have understood that the same executable can have more than one service, but again since I didn't really try it out, I will refrain from making any bold statements. Anyway I think that one service per exe is a smart way of doing things which follows the keep-it-simple paradigm.
The ServiceMain function
ServiceMain is the entry point function for our service. When the SCM starts our service it creates a new thread for executing our
ServiceMain function. The first thing a
ServiceMain does is to call
RegisterServiceCtrlHandler to register a handler function. The service uses this handler function as it's control handler function which receives control codes including codes to start, stop, pause and continue the service.
Once we have registered our service control handler, we need to update the SCM with regard to our service's status. We can do this using the
SetServiceStatus API call. We will need to do this several times during the course of our program and each time it involves filling up a
SERVICE_STATUS structure. Therefore I have written a function called
UpdateServiceStatus which will automate this for us. I discuss this function later on in this article. Basically what we do after registering our handler is to update the SCM with the
SERVICE_START_PENDING status for our service, which means that our service is starting.
3000 is the
dwWaitHint parameter of the
SERVICE_STATUS structure which is in milliseconds. If this time has expired and the service status has not yet changed, the SCM assumes that an error has occured. Once we have updated the SCM with our status, we create an event. We do this so that we can use
WaitForSingleObject on this event. We can then set the event to terminate our service somewhere else in our program.
After we do this we call
UpdateServiceStatus again with the
SERVICE_START_PENDING status, only this time we increment the
dwCheckPoint parameter of the
SERVICE_STATUS structure. This parameter is used to track the progress of a service during a lengthy start or stop operation. Now we start our service execution thread.
I discuss this function later on, but in summary it simply starts a new thread using
CreateThread where we put our actual functionality. Now we call
UpdateServiceStatus again, passing
SERVICE_RUNNING as our parameter.
Well, now that our service is up and running we need to call
WaitForSingleObject on the event we created earlier. Because
ServiceMain should not finish till our service has terminated. Again this is a very simple step as shown below.
The UpdateServiceStatus function
As I had mentioned earlier, I wrote this function to wrap the
SetServiceStatus API call. It is by no means an innovative idea. Just about every example of a service that I saw on the web used some form of a wrapper function, because during the course of a service program, we need to change the service status several times. Basically what we do in this function is to populate a
SERVICE_STATUS structure. I'll mention some of the members of this structure that are important to us. I strongly suggest that you look up this structure in your copy of MSDN.
dwCurrentState :- This indicates the current state of the service. Some of the values we use are
SERVICE_START_PENDING. You can look up the other allowed values on MSDN.
dwControlsAccepted :- This is used to indicate the control codes that will be handled by our service handler. For our skeleton service I have used
SERVICE_ACCEPT_SHUTDOWN. These are the only two control codes our skeleton service will handle. When our service is in the
SERVICE_START_PENDING state we must set this parameter to zero.
dwCheckPoint :- I have mentioned about this parameter earlier. The service increments this value during a lengthy start or stop operation. Any program that invokes an operation on the service can use this value to track the progress of various operations. If you are wondering how a program can do that, take a look at the
QueryServiceStatus API call.
dwWaitHint :- This specifies the interval in milliseconds before the service status changes again. If the service status has not changed by then, the SCM assumes that an error has occured. Use zero for this parameter when we are setting the service status to
The first parameter we pass is the service status handle which is returned by the
RegisterServiceCtrlHandler function. I have saved this in a global variable. The second parameter is a pointer to the
SERVICE_STATUS structure that we have populated.
The StartServiceThread function
Well, this function simply starts our service execution thread using the
CreateThread API call. If the thread is created successfully I also set the global
nServiceRunning variable to true. I have used
CreateThread but you might want to use
_beginthreadex if you are planning on using some of the CRT functions in your thread.
The ServiceExecutionThread function
This function is our main service execution thread. In our skeleton service I have simply put a
while loop using my global
nServiceRunning BOOL variable as the while's evaluation expression. Thus till
nServiceRunning is made false the
while loop will loop endlessly. Please keep in mind that an endless while loop will use up your CPU infinitely till your machine crawls to a pathetic frozen state. I am avoiding this using a
Sleep, but you might want to use some kind of blocking calls or waiting calls in your programs.
Well, that's the service body for you. It won't get any simpler than that I guess. Of course the functionality is useless, that's why we call it a skeleton service.
The ServiceCtrlHandler function
This is our service's control handler function. All service control requests like starting a service, stopping a service etc. are handled by the control handler. The MSDN prototype for this function is as follows.
VOID WINAPI Handler(
Basically we put a switch statement on the
fdwControl variable and we have case blocks for each control code that we intend to handle.
As you can see our skeleton program's switch construct handles only two control codes,
SERVICE_CONTROL_STOP. If you scroll up, you'll see that when I set the service status to
SERVICE_RUNNING I set the
dwControlsAccepted member of the
SERVICE_STATUS structure to
SERVICE_ACCEPT_STOP|SERVICE_ACCEPT_SHUTDOWN. Thus these are the only two control codes that the SCM will send to our control handler function. As you can see, for both cases, we are using the same code. All we do is to change our global service status variable to
SERVICE_STOP_PENDING and then we call
SERVICE_STOP_PENDING. Then we call our own
KillService function (which I explain down below) and return.
The KillService function
Well, we use the
KillService function to terminate our service. We first set nServiceRunning to false, so that our service execution thread exits. Then we set our blocking event so that
ServiceMain will exit.
Once we have done that we need to inform the SCM that our service has terminated. So we call
SERVICE_STOPPED as the
Installing our service
First we use the API call
OpenSCManager to get a handle to the SCM database.
We pass 0 for both lpMachineName and lpDatabaseName as we need to open the SCM database on the local machine. We pass
SC_MANAGER_CREATE_SERVICE as our
dwDesiredAccess so that we can use the
CreateService API call to create our new service and add it to the SCM database.
"Buster's first NT service",
You must look up
CreateService on MSDN. I have used
SERVICE_ALL_ACCESS as my
dwDesiredAccess parameter. This allows me full rights and I can do as I please. I have used
SERVICE_DEMAND_START as the
dwStartType parameter. This means the service won't start automatically at system boot time. It will need to be manually started either via the control-panel's Component Services applet or programmatically using
StartService. Later on in this article I show you how to programmatically start and stop our service. You need to specify the full path of the service executable. The last 5 parameters can be ignored for now. To be frank, as soon as I found that they can all be NULL, I didn't bother to interpret their purpose. But I suggest that you go ahead and figure out how you can put them to proper use.
Starting our service programmatically
The first thing we need to do is to use
OpenSCManager to obtain a handle to the SCM. Now we use
OpenService to obtain a handle to our skeleton service.
OpenService successfully returns,( which we can figure out by checking whether it has returned NULL, in which case the call has failed), we can proceed by calling
StartService using the handle returned by
Since we are not passing any parameters to
ServiceMain, I am passing 0 and NULL as the 2nd and 3rd parameters. If
StartService succeeds, the return value is nonzero and we can assume that our service has been successfully started. This will become obvious soon, when the PC speaker starts beeping once in 4 seconds and you might get rude stares from your co-employees. In which case you might want to stop the service.
Stopping our service programmatically
The first two steps for stopping our service are same as for starting our service. We call
OpenSCManager to get a handle to the SCM and then call
OpenService to get a handle to our service. Now we can use the
ControlService API call to send a control code to our service handler.
m_SERVICE_STATUS is a
SERVICE_STATUS structure which will receive status information about our service. As you can see I have passed
SERVICE_CONTROL_STOP as the control code. And we know how we have handled this control code in our service handler. Now it all begins to fit into a pattern, huh? By now the 4-second beeping will have stopped and the rude stares will slowly fade away.
Thank You [and remember that I am a service-newbie too]