How To Make Debugging .NET Windows Services Easier

July 24th, 2007

As you may know, Windows Services developed in .NET can’t be run with the Visual Studio .NET environment. Instead, you have to install the application as a service, so that it can run under the Windows Services Control Manager, and attach the Visual Studio debugger to the process. The catch is that the service has to be running before you can debug it and this makes it difficult for you to debug your start-up routines.

In this article I’ll examine some techniques you can use to make debugging your Windows Service apps easier

The first technique I like to use is scaffolding. This means that I first develop the app as a standard Windows application, either WinForms or Console, and develop a substantial portion of the program without having to deal with the baggage of the service environment. I use very simple code for the scaffold that essentially emulates the standard service, such as the Start, Stop, Pause, and Continue commands. Each part of the program can be tested as it is written this way as long as you’re using a good design.

Unfortunately, not every service application can be built up this way since some need to run as a service in order to do what they need to do properly. Also, you need to be mindful that your scaffold app will be running under your user account, not the NETWORK or LOCAL services accounts, so the rights are very likely to be different. Security issues are a common stumbling block when it come to running as a service.

Once the units of your program are in place you’re ready to deploy it and run it as a service. However, you will probably still need to debug it. To do this, you install and start the service and attach to it using the Attach To Process dialog from the Visual Studio Debug menu. Now you’re ready to set your breakpoints and debug the app but there are still some challenges involved in debugging a .NET service application.

First, the service has to be running for you to attach to it. This means that by the time you can hook into it the startup code has already been executed. If you have a problem in the startup code, code that executes in either the Main or OnStart methods, this can be difficult to debug. Also, since the attachment process doesn’t stop or pause the service but suspends the service thread, this can cause some odd effects on some code. Also, you can’t use pausing techniques to have the program wait on you because Windows only provides a 30 second stretch of time for a service to start. If it hasn’t completed its start during that time, it program won’t start. You can use logging to disk to capture some of these errors but that can be difficult and tedious to manage.

My method for getting around this problem is to have very little code in the startup routines themselves, like so:

Protected Overrides Sub OnStart(ByVal args() As String)
    ServiceStartUp()
    MyBase.OnStart(args)
End Sub

Then, to enable debugging, I move this call, ServiceStartUp(), to the OnContinue method and comment it out in OnStart. That way I can start the service without any code being executed, pause the service, set breakpoints and attach to it from within Visual Studio, and click to allow it to continue. I can then debug the startup code of the application.

Make sure that you uncomment the startup line in the OnStart method when you’re ready to deploy though!

One other tip is how to find your app in the Attach To Process Window. This can be confusing at first. The default setting of the dialog only shows processes for the currently logged in user so your service, which is mostly likely running under a system service ID, won’t be visible although you’ll see a grayed out copy of the matching project in the list. Check on the “Show processes from all users” box to see the process you want. Don’t let the similarly named “vshost” file confuse you.

If you have any questions or ideas about debugging .NET Windows Service applications, please leave a comment here.

Entry Filed under: Tip Sheets

Rate This Article:

(1 votes, average: 5 out of 5)

 Loading ...