A reusable Windows service template - part 3

Edit: This open-source template has now been updated and placed in a GitHub repository.

A few years ago I wrote a bunch of C# Windows services that were all based around the same basic template. Recently I decided to extract what I learned from that experience to make a better template.

This Windows service template is designed to:

  • Provide all of the service infrastructure, so that the developer can focus primarily on the real work that the service does.
  • Create a service infrastructure that starts/restarts, monitors, and logs the worker thread where the service's work is occurring.
  • Isolate the service's work from the controlling infrastructure so that any crash is logged properly and doesn't bring down the service. 
  • Have relatively simple and small code, so that it's easy to understand, maintain, and debug.
  • Enable the developer to test and debug the service within Visual Studio.
  • Allow the service to install and uninstall itself from the command-line, without the use of InstallUtil.
  • Remove any use of Thread.Sleep.
  • Remove any cross-thread interactions that involve polling or "busy" loops.
  • Reduce application-level cross-thread interactions that involve shared memory.
  • Log everything that the service is doing, and especially cross-thread interactions.

This is the third entry in a 3-part series:

  • Part 1 discusses the purpose of the template, along with its start modes - install, uninstall, and debugging.
  • Part 2 describes the core of the service template - a detailed design analysis of the controller and worker threads.
  • This part investigates the thread-safe logging class.

The screenshot below shows the Windows event log for the service template start and stop events.

Unfortunately the .NET Windows event log object only allows the date/time to be specified at the granularity of 1 second. If you create multiple events within a single second, you can't by default sort those events in the order in which they occurred. The trick I use to overcome this is to increment the Event ID for all events logged within a single second. As you can see above, sorting the display by both date/time and Event ID shows the events in the order that they actually occurred.

The code below shows the core of the class that logs these events. 

// Write message to event log.
private void LogMessage(string message, EventLogEntryType messageType, string methodName)
    // Extract name of thread that triggered this message.
    string threadName = Thread.CurrentThread.Name;
    if (threadName == null)
        threadName = THREAD_NAME_SCM;
    // Maintenance developer might want to know this fact.
    if (Thread.CurrentThread.IsBackground)
        threadName = threadName + " (background)";
    // Setup full message and then write to event log.

    string fullMessage = string.Concat("Thread: ", threadName, Environment.NewLine, 
                                "Method: ", methodName, Environment.NewLine, 
                                "Message: ", message);
    // Note the assumption that no external call inside this protected
    // block will lock something in such a way as to cause a deadlock.
    lock (LockEventLog)
        // Because EventLog's timestamp only has a granularity of 1 second, 
        // we populate the EventId field with an incrementing integer wherever  
        // an event occurs in the same second as the previous event.
        // The combination of Timestamp and EventId makes it easier to view
        // the real order of events in the Windows event log. 
        if (Math.Abs((DateTime.Now - this.LastEventWriteTime).TotalSeconds) < 1)
            this.EventOrder = 1;
        this.LastEventWriteTime = DateTime.Now;
        this.AppEventLog.WriteEntry(fullMessage, messageType, this.EventOrder);


This concludes our dive into latest version of the reusable Windows service template. The previous version of this template has proven to be very reliable in a demanding production environment, and this version should be even more robust.

One final caveat: be careful not to make any network call in the template infrastructure code. Network calls to other resources such as a database are notoriously less reliable than local calls.