只需将调试器放置在任何地方，并在启动时附加Visualstudio即可

#if DEBUG
    Debugger.Launch();
#endif

此外，你需要以管理员身份启动VS，并且你需要允许，一个进程可以由不同的用户自动调试(如下所述):

reg add "HKCR\AppID{E62A7A31-6025-408E-87F6-81AEB0DC9347}" /v AppIDFlags /t REG_DWORD /d 8 /f

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

将代码包含在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

只需将调试器放置在任何地方，并在启动时附加Visualstudio即可

#if DEBUG
    Debugger.Launch();
#endif

此外，你需要以管理员身份启动VS，并且你需要允许，一个进程可以由不同的用户自动调试(如下所述):

reg add "HKCR\AppID{E62A7A31-6025-408E-87F6-81AEB0DC9347}" /v AppIDFlags /t REG_DWORD /d 8 /f

对于现有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)启动服务。

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

有时，分析在服务启动期间发生了什么是很重要的。附加到流程在这里没有帮助，因为在服务启动时附加调试器的速度不够快。

简单的回答是，我使用以下4行代码来做到这一点:

#if DEBUG
    base.RequestAdditionalTime(600000); // 600*1000ms = 10 minutes timeout
    Debugger.Launch(); // launch and attach debugger
#endif

这些被插入到服务的OnStart方法中，如下所示:

protected override void OnStart(string[] args)
{
    #if DEBUG
       base.RequestAdditionalTime(600000); // 10 minutes timeout for startup
       Debugger.Launch(); // launch and attach debugger
    #endif
    MyInitOnstart(); // my individual initialization code for the service
    // allow the base class to perform any work it needs to do
    base.OnStart(args);
}

对于那些以前没有做过的人，我在下面列出了详细的提示，因为你很容易陷入困境。以下提示适用于Windows 7x64和Visual Studio 2010 Team Edition，但也适用于其他(更新的)环境。

重要提示:以“手动”模式部署服务(在VS命令提示符中使用InstallUtil实用程序或运行您准备好的服务安装程序项目)。在启动服务之前打开Visual Studio并加载包含服务源代码的解决方案——在Visual Studio中根据需要设置额外的断点——然后通过服务控制面板启动服务。

因为调试器。启动代码，这将导致一个对话框“一个未处理的Microsoft . net Framework异常发生在Servicename.exe.”出现。单击“是”，调试Servicename.exe，如下图所示:

之后，Windows UAC可能会提示您输入管理凭据。输入它们并继续执行Yes:

之后，著名的Visual Studio即时调试器窗口出现。它询问您是否要使用已删除的调试器进行调试。在单击Yes之前，选择不想打开新实例(第二个选项)——在这里，新实例没有帮助，因为不会显示源代码。所以你选择之前打开的Visual Studio实例:

单击Yes后，过一会儿Visual Studio将在调试器所在的行中显示黄色箭头。启动语句，您可以调试您的代码(方法MyInitOnStart，其中包含初始化)。

按F5继续立即执行，直到到达您准备的下一个断点。

提示:要保持服务运行，请选择Debug -> Detach all。这允许您在服务正确启动并完成调试启动代码之后运行与服务通信的客户机。如果您按下Shift+F5(停止调试)，这将终止服务。您应该使用服务控制面板来停止它，而不是这样做。

请注意,

If you build a Release, then the debug code is automatically removed and the service runs normally. I am using Debugger.Launch(), which starts and attaches a debugger. I have tested Debugger.Break() as well, which did not work, because there is no debugger attached on start up of the service yet (causing the "Error 1067: The process terminated unexpectedly."). RequestAdditionalTime sets a longer timeout for the startup of the service (it is not delaying the code itself, but will immediately continue with the Debugger.Launch statement). Otherwise the default timeout for starting the service is too short and starting the service fails if you don't call base.Onstart(args) quickly enough from the debugger. Practically, a timeout of 10 minutes avoids that you see the message "the service did not respond..." immediately after the debugger is started. Once you get used to it, this method is very easy because it just requires you to add 4 lines to an existing service code, allowing you quickly to gain control and debug.