What are the best practices when running a process as a windows service?

Question

Is there any things to take care of when running your process or executable as service.Things like silent logging.Critical error reporting scenarios? etc? How do you handle it ?

Answer 1

For critical error reporting, you are constrained to using the standard Service settings (in the properties of the installed service), or doing something yourself. This could be as simple a log file that logs unexpected errors (by using AppDomain.UnhandledException to catch and log them), using the Windows event log to log similar info, or having another process watch the service for errors (ie. the service stopping) and alerting someone.

Microsoft has an article entitled " Introduction to Windows Service Applications " that is a good general introduction to making services in .Net.

Some other things about developing Windows services from my experience:

• A Windows service is allowed about 30 seconds to start. After that, Windows will report it as not having started correctly. This means that you need to ensure that your OnStart method of the service kicks off a new thread to run the service and then returns.
• Don't expect any user interaction (ie. message boxes, confirmations) because the service runs "headless" (ie. without a UI), so you cannot expect a user to interact with it.
• Check the account that the service will run as to ensure that you are not running it as a user with unnecessarily high security privileges.
• Make extensive use of logging (eg. log4net) so that you can see what the service is doing during runtime, as well as being able to diagnose any errors (by logging stack traces).
• Make sure you use the correct version of InstallUtil (ie. 32 or 64 bit) to install the service with. Even better, let the service install itself using the ManagedInstallerClass.InstallHelper .

Answer 2

• Be sure to use a tracing/logging API to have diagnostic information. Eventlog, log files, database, whatever... Just have the troubleshooting info somewhere.
• Trace/Log early and often. Nothing is more frustrating then having to make a code change which is just to add diagnostic tracing.
• Be cognizant of memory leaking. When writing an app that will be restarted everyday or runs as a scheduled task, sometimes we get a bit lazy. Remember this service needs to clean up after itself thoroughly. Make proper use of the using clause with all IDisposables.
• Do not forget the volatile keyword on your STOP variable! My God this gets me every time.

Answer 3

Don't show any message boxes / dialogs.

Be aware that your app will usually not run under the same account as a logged-in user. So if a user is able to access some file/directory, this does not mean that the service can do as well.

Answer 4

确保您具有某种形式的警报系统，以在服务发生故障时通知您，例如，向您自己或某个邮箱发送电子邮件。

Answer 5

I have a good one, add the following code to your OnStart method or even better before it in your Main method.

#if DEBUG
   //LogMessage("Service starting");
   #warning The service has been set to break on debug. Only used for debugging.

   //LogMessage("DEBUG MODE - If the service crashed after this then your problem is that you're running in DEBUG mode without a Visual Studio installed.");
   if (Debugger.IsAttached == false) Debugger.Launch();
#endif

Basically the important part if the Debugger.Launch() which will pop open a window when you start the service and ask you whether you would like to debug the service and with which Visual Studio. It makes working with services awesome and easy. I put the #warning there just so it shows up in warning list to remind me it's there, although the #if DEBUG should prevent most issues.

Just remember not to deploy with this code running (ie don't release debug code) because it does crash if there is no Visual Studio installed on the machine.

Answer 6

If it makes sense, don't forget to implement the Pause event. Handle all exceptions so it fails gracefully when it fails.