Debugging a Service

I l @ ve RuBoard

Debugging a Windows service is not as straightforward as debugging your run-of-the-mill Windows Forms application. The difficulty stems from the context in which the service runs. As previously noted, the SCM handles starting, stopping, and essentially controlling the lifetime of the service. An attempt to run a Windows service project from within Visual Studio will result in the failure dialog box shown in Figure 7-8.

Figure 7-8. The message box that appears if attempting to start a Windows service project within the IDE.

To debug a Window service, you must start the service and then attach to the process hosting the service with Visual Studio .NET. After installing the service, you can start, stop, pause, and continue the service by right-clicking the service in the Server Explorer window in Visual Studio .NET.

Note

Another quick way to start and stop a service is via the command prompt. At the Windows command prompt, you can issue Net Start TimeService or Net Stop TimeService to start or stop a service, respectively.

Once the service is running, choose Debug Processes from the Tools menu. In the dialog box that appears, locate the Show System Processes check box and select it, then select the service process name in the list. Click the Attach button to see the Attach To Process dialog box, as shown in Figure 7-9. Be sure that the Common Language Runtime check box is selected , and then click OK. Click the Close button in the Processes dialog box.

If all has gone well, you can set breakpoints within the service and have the debugger break into the code when the service hits the area of code around the breakpoint. You can also send the service Stop, Pause, and Continue commands to coax it into a section of code that you want to debug.

Figure 7-9. Attaching the Visual Studio .NET debugger to a process.

Debugging the OnStart Method

Debugging the OnStart method can be a little more difficult because the SCM imposes a 30-second timeout on starting the service and the debugger must be attached to the process before you can debug. Realistically, you shouldn't be doing much of anything in the OnStart method other than some occasional initialization. The initialization might need to be debugged , however. The "Debugging Windows Service Applications" topic in the Visual Studio .NET MSDN collection discusses creating a second " dummy " service and then simply adding this to the same Windows service project. This service will exist primarily to aid in the debugging of the other service. Here's the general idea:

1. Add a dummy service to the existing Windows service project.

2. Install both services.

3. Start the dummy service so the process is loaded into memory.

4. Attach the debugger to the running process, as described earlier.

5. Set a breakpoint in the Main or OnStart method of the service that you want to debug.

6. Start the service.

The Trace Class

The Trace class in the System.Diagnostics namespace provides another alternative for debugging with either debug or release code and is especially useful with Windows services. Sure, the event log is useful in debugging and tracing to some degree, but it can definitely be easier to watch trace to a text file or output to a debug monitor, rather than attempting to wade through a ton of log entries. For basic functionality, call the Trace.WriteLine function throughout your code.

The Visual Basic .NET compiler supports the Trace and Debug conditional compilation constants. By default, the Debug statements are omitted in release builds, but the Trace statements are not. This makes it easy for a user to attach a debug window to your released code and then send a log file back to you, without you having to recompile your code. As shown in Figure 7-10, you can set the Trace and Debug constants in the Build Configuration property page.

Figure 7-10. The Build Configuration property page.

After enabling tracing via the conditional compilation flag, you'll need a viewer of some sort to examine the trace statements at run time. The Web site at http://www.sysinternals.com has a collection of great diagnostic tools. One of these tools is a debug viewer named DebugView for capturing such trace statements. Figure 7-11 shows the DebugView tool in action.

Figure 7-11. The DebugView tool.

I l @ ve RuBoard