Simon Carter has a tip on debugging services. It boils down to calling the Windows Sleep API in your service constructor code. This gives your debugger enough time to attach the your process in time to step through the service start up code. Usually when you attach to a running process, it has already gone through it’s normal initialization code (“We now join this program already in progress”). If you are trying to diagnose a problem in the startup code, it’s already too late by the time you can attach to it. That is the joy that we call Windows Service programming.
I prefer to take a different tack for debugging a service. I separate the code of what the service is supposed to do from the actual service code. I’ll build a Windows App (or Winforms app) that calls the same code that the service would call. It’s much easier to debug the code from an application instead of a service. 99.9% of the time, the problem is not part of the service controller code, it’s the in the code that service uses. The other 0.01% of the time where the problem is in the service creation code, I just add a lines to send data to the Windows event log. This technique works well for Win32 Delphi and .NET programming.