A Windows Service is an application that runs outside of any desktop session. It can run automatically when Windows starts up, before any users log in. Alternatively, it can be started up by some other app via the Windows Service Control Manager (SCM - pronounced "scum"). Not to be confused with a Web Service, which runs a particular protocol and serves up XML to remote machines, a Windows Service is a basic building block of the Windows operating system. An out-of-the-box install of Windows XP has more than 80 Windows Services installed (necessary?). Outside of a Microsoft environment, this type of program is commonly referred to as a ‘daemon’, or more accurately, a ‘dragon’ (which appeals far more to the author than any other terminology). It runs in a security context independent of any logged on user—configured in the Services Manager (right-click My Computer, select Manage, expand Services and Applications, then Services) where you’ll also find its start/stop controls.

Visual Studio .NET makes it very simple to create and install Windows Services: just select the Windows Service template when starting a new project. In this article you’ll see the (very little) code needed to make this service work and all the Administrative tasks you’ll need to perform to get it running. You’ll build a project called “Empty Service” that can be used as a template to build all kinds of Windows Services. You then just add your own business class to perform the activity you need.

A Windows Service exposes two main commands: Start and Stop. It begins work when it receives a Start command from the SCM. It is therefore in the OnStart method that you will put code to execute whatever work it is you want the service to perform. The Service can support other functions optionally, such as Pause and Continue, or Custom Commands. These too respond to controls received from the SCM. You want to avoid any desktop interaction since your service will run in a security session unattached to any particular user session (e.g. no message boxes, prompts, etc.).

As the Start command is only called once, the Service itself must implement a mechanism to periodically “wake the dragon”. The simplest way to do this is to drop a Timer component on the Service designer, and call its Start and Stop methods from the OnStart and OnStop methods of your Service. However, this gives you little control over process creation and you end up with many threads running at a time. This article shows you how to implement a single “worker” thread which executes in a loop only when the previous iteration is complete—hence program overlap is avoided.