Actually you can use this trick every time when:
So the problem is that you can't simply attach the Visual Studio debugger to the process as there isn't one to attach to until after you start the process. However, once you start the process if you have a bug such as an exception in the process's initialization you won't get the debugger attached to the process before it's too late.
Calling Debugger.Launch() or Debugger.Break() in your code allow you to debug such problems. This methods pop up the following screen asking you which instance of the debugger it should use to debug the application.
To extend this trick, you can add a commandline switch (e.g. -debug) to you service program. (The program will only call Debugger.Break if the switch is set.) Then, if you want to debug you just modify ImagePath in the registry (HKLM/SYSTEM/CurrentControlSet/Services/YOURSERVICE) and append the switch. Another problem is, that service control manager kills the process if it does not respond within a given timeout. To influence this timeout you have to edit the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control -> ServicesPipeTimeout Much more interesting information can be read in this wonderful knowledge base article: http://support.microsoft.com/kb/824344 Regards, a4711
a4711 4/18/2008 9:50:51 AM
Good remark about timeout. Sometimes it's hard to debug when you have less than 30 seconds ;)
kostya.ly 4/20/2008 12:41:53 AM
I had to do remote debugging(start up). ie service is installed in a machine where there is no visual studio installed. You know what I did ? :D.. When service starts it sleeps(Thread.Sleep()) for 1 minute. by then I would have connected my visual studio to the service .. simple !!
sanjay 4/7/2010 5:56:56 PM