当我写一个服务时，我把所有的服务逻辑都放在一个dll项目中，并创建了两个“主机”来调用这个dll，一个是Windows服务，另一个是命令行应用程序。

我使用命令行应用程序进行调试，并仅针对无法在命令行应用程序中重现的错误将调试器附加到实际服务。

如果您使用这种方法，请记住，您必须在实际服务中运行时测试所有代码，而命令行工具是一个很好的调试辅助工具，它是一个不同的环境，并且它的行为与实际服务不完全相同。

最好的选择是使用“系统”。诊断的名称空间。

将代码包含在if else块中，用于调试模式和发布模式，如下所示，在visual studio中切换调试和发布模式。

#if DEBUG  // for debug mode
       **Debugger.Launch();**  //debugger will hit here
       foreach (var job in JobFactory.GetJobs())
            {
                //do something 
            }

#else    // for release mode
      **Debugger.Launch();**  //debugger will hit here
     // write code here to do something in Release mode.

#endif

我认为这取决于你使用的操作系统，Vista很难附加到服务，因为会话之间的分离。

我过去使用的两个选项是:

Use GFlags (in the Debugging Tools for Windows) to setup a permanent debugger for a process. This exists in the "Image File Execution Options" registry key and is incredibly useful. I think you'll need to tweak the Service settings to enable "Interact with Desktop". I use this for all types of debugging, not just services. The other option, is to separate the code a bit, so that the service part is interchangable with a normal app startup. That way, you can use a simple command line flag, and launch as a process (rather than a Service), which makes it much easier to debug.

希望这能有所帮助。

我使用了JOP的答案的变体。使用命令行参数，您可以在IDE中使用项目属性或通过Windows服务管理器设置调试模式。

protected override void OnStart(string[] args)
{
  if (args.Contains<string>("DEBUG_SERVICE"))
  {
    Debugger.Break();
  }
  ...
}

对于现有Windows服务程序的故障排除，请像其他人建议的那样使用'Debugger.Break()'。

对于新的Windows服务程序，我建议使用James Michael Hare的方法http://geekswithblogs.net/BlackRabbitCoder/archive/2011/03/01/c-toolbox-debug-able-self-installable-windows-service-template-redux.aspx

您也可以通过命令提示符(sc.exe)启动服务。

就我个人而言，我会在调试阶段将代码作为独立程序运行，当大多数错误被解决后，再改为作为服务运行。