locked
Service not starting with Debugger.Break c# windows service RRS feed

  • Question

  • With following code, by service does start but when I uncomment Debugger.Break() it doesn't. What's wrong.

     protected override void OnStart(string[] args)
        {
            #if DEBUG
                 //Debugger.Break();
            #endif
        }

    Regards, Vinay

    Wednesday, August 22, 2012 3:42 PM

Answers

  • AFAIK nothing has changed.  Both of them ultimately trigger an assertion in Win32 which causes the dialog to pop up.  But the OS and UAC influence whether you'll see the dialog or not.  It is possible that a 3.5 app doesn't have the same manifest as a 4.0 app which could cause behavior differences. 

    Under Vista+ there is a service that runs that detects interactive service UIs.  When this happens it switches to the service desktop to display the message (but you have to be watching the task bar for it).  By default the service isn't running IIRC.  A service is marked interactive during installation via an option applied to the service type.  I didn't see that the behavior had changed between v2 and v4 but that could also be a contributing factor.  The user account you're running it under also has an impact.

    All in all there are various reasons why it might work sometimes and not others.  But it isn't a supported option for debugging services because, as you've seen, it isn't reliable.  Wish I could give you a better reason than that but I can't.

    Michael Taylor - 8/23/2012
    http://msmvps.com/blogs/p3net

    • Proposed as answer by Bob Shen Monday, September 3, 2012 7:38 AM
    • Marked as answer by Bob Shen Wednesday, September 5, 2012 2:50 AM
    Thursday, August 23, 2012 3:38 PM

All replies

  • And if you try this:

    System.Diagnostics.Debugger.Launch()

    Web Developer

    Wednesday, August 22, 2012 4:41 PM
  • You can't debug services like that.  Services run under the context of the SCM.  A service is required to start within a certain period of time otherwise the SCM marks it as unresponsive and kills it.  Even more important is that services run under a different window station so UIs (like one that is triggered with Debugger.Break) will not be seen.

    To debug a service you normally run it as a normal console app such that you can debug normally.  It "switches" to service mode via a command line option or something, depending upon how you need to set things up.  The only time you should need to debug a service via SCM is when something is going wrong because it is a service - generally security stuff.  In that case you have to wait until the SCM starts the service and then attach to the process.  You can't debug the startup code of a service via SCM.  Debugging services is documented here: http://msdn.microsoft.com/en-us/library/7a50syb3(v=vs.100).aspx

    Michael Taylor - 8/22/2012
    http://msmvps.com/blogs/p3net

    Wednesday, August 22, 2012 5:10 PM
  • Hi CoolDadTx,

    Thanks for your response and I understand the alternatives available to debug my service. But, I really don't understand following. What's is missing. 

    When I change the target framework to 3.5 and put a debugger.Break in service OnStart it prompts a window to attach the process.

    Where as same thing in 4.0 framework doesn't work.

    What's new in framework 4.0 which would not allow Debugger.Break?


    Regards, Vinay

    Thursday, August 23, 2012 5:11 AM
  • AFAIK nothing has changed.  Both of them ultimately trigger an assertion in Win32 which causes the dialog to pop up.  But the OS and UAC influence whether you'll see the dialog or not.  It is possible that a 3.5 app doesn't have the same manifest as a 4.0 app which could cause behavior differences. 

    Under Vista+ there is a service that runs that detects interactive service UIs.  When this happens it switches to the service desktop to display the message (but you have to be watching the task bar for it).  By default the service isn't running IIRC.  A service is marked interactive during installation via an option applied to the service type.  I didn't see that the behavior had changed between v2 and v4 but that could also be a contributing factor.  The user account you're running it under also has an impact.

    All in all there are various reasons why it might work sometimes and not others.  But it isn't a supported option for debugging services because, as you've seen, it isn't reliable.  Wish I could give you a better reason than that but I can't.

    Michael Taylor - 8/23/2012
    http://msmvps.com/blogs/p3net

    • Proposed as answer by Bob Shen Monday, September 3, 2012 7:38 AM
    • Marked as answer by Bob Shen Wednesday, September 5, 2012 2:50 AM
    Thursday, August 23, 2012 3:38 PM
  • I had the same problem and this reply from Norkk solved that one.

    Thanx!

    Tuesday, December 4, 2012 12:55 PM