Understanding Windows Services

As you know, Windows Services can run when Windows starts, even if no one logs in. These applications have no user interface and run in the background, independent of any user. They “log in” as the service account or as a specific user, which means they can run under the security context of a specific user, regardless of who is logged in.

Windows Services are unique in several ways. You cannot debug a service by starting it within the IDE because you must install it first so that Windows can manage it. You will see how to debug it later.

You had to add installers to this project, something you have not had to do in any other project. This, again, is because the service must be installed so that Windows can handle starting and stopping it.

Because a service does not have a user interface, you should plan to write any messages from the service into the Windows event log. This is the key to a long-running service; nothing blocks execution, such as waiting for a user to click the OK button to clear a message box. You want to have exemplary error handling in your service, capturing errors so that they can be written to the event log instead of causing a message to be displayed to the user, indicating that an error was encountered. If you try to pop up a message box, it will not be visible to the user, and the program might hang, waiting for the dialog box to be cleared.

Service Lifetime and Events

A service has a number of events to which it can respond, and these mirror the stages of a service's lifetime. For example, you've already seen the OnStart event handler. Here are the events to which the service can respond:

• OnStart— OnStart fires when the service starts. As you saw in the code in your service, this event writes to the log file the fact that the service is starting, and the date and time that the start occurred.

• OnPause— If the CanPauseAndContinue property is set to True for your service, the service can be paused from the Service Control Manager. If the service is paused, this event fires and can perform actions before the processing is actually paused.

• OnContinue— If the CanPauseAndContinue property is set to True for your service, this event fires when the service is continued after being paused.

• OnStop— When the service is stopped, this event is fired before the service stops. There is a CanStop property that is set to True by default. If the property is set to False, the service does not receive the stop event (but it is still stopped).

• OnShutdown— If the service is running and the machine is shut down, this event is fired. This is different from an OnStop in that this fires only when Windows is shutting down. There is a CanShutdown property that is set to False by default; this property must be set to True for your service to receive this event.

Your projects also have an AutoLog property, which is set to True by default. This allows your service to log certain events automatically. For example, if you run the service you created earlier, you can check the Event Viewer and, in the application log, you will see information messages about your service starting and stopping. These are created for you, but if you choose to turn them off, simply set AutoLog to False.

Earlier, you saw that you could set the Account property to User, which allows you to specify a particular user under whose account the service will run. However, after you have installed the service and the Service Control Manager is handling the service, you can change the security context for the service by modifying the properties of the service in the Service Control Manager.

Debugging Your Service

Your service cannot be debugged in the usual sense because it has to be installed into the Service Control Manager first. Because this is a Windows Service, the IDE cannot start it for you; you need the Service Control Manager to start it for you. Therefore, to debug your Windows Services application, you'll have to build it, install it, and start it. This means that you actually are debugging a running application, which had to be installed before you started debugging. Although the IDE cannot start a service for you, it can debug one for you.

Place a breakpoint on one of the lines inside the Timer1_Tick event handler. Next, choose Processes from the Debug menu. After the Processes dialog box is open, check the Show system processes box. In the list, your service will be listed as the name of the EXE, not the name of the service. Choose LearningVBservice.exe as shown in Figure 10.2. Click the Attach button, and you will see the screen shown in Figure 10.3. Choose Common Language Runtime and click the OK button. Now, click Close on the Processes dialog box.

Because the service is running, the breakpoint in your code will be hit within five seconds, and you can now interactively walk through the program as you would any other. Your running service is now in debug mode, so it is no longer running in the normal fashion; instead, it is responding only to your debugging commands. To stop the debugging process, just choose Stop Debugging from the Debug menu. Note that when you stop debugging, the service returns to running normally.

Before leaving this chapter, you might want to remove your service. To do this, go back to a command prompt, go to the directory holding the EXE for your service, and type the following line:

installutil /u LearningVBservice.exe