Jigar Mehta’s WebBlog

May 13, 2007

FAQ about Windows Service..

Filed under: Uncategorized — jigarme @ 7:46 pm

I thought, it would be good to share some information on Most frequently asked questions about Windows Service.

  1. What is a windows service?

A Windows Service is not a special type of application.  From a core OS perspective, they are Windows applications (either a console application or a GUI application) just like any other application.  From a really simple perspective, there are only a few things that make a Windows Service different:

  • A Windows Service is started by the Service Control Manager (SCM) instead of by the end-user.  This means that every service is no longer dependant on the end-user but must instead interact with the SCM.  There are a few special rules it a service must follow to be a well behaved service (such as telling the SCM about its status).
  • A Windows Service is started under a specific user account rather than the interactive users account.
  • A Windows Service is usually (should *always* be) non-interactive.  A service should never create windows and should never directly interact with the end-user. Only poorly designed Services will display a user interface directly.

That’s it.  A Windows Service really is not a special type of application.  Its just an application that is started (by the SCM) with CreateProcess*(), just like every other process.  It has its entry point (Main(), WinMain() or the managed entry point) that is called just like every other process.  It will have threads that get scheduled and execute code, just like every other process.  And a service can use most technologies, depending on how the developer wrote the service.  More on this below.

In fact, many developers develop their code to run as both a service and a desktop application.  The only difference is often a command line argument that tells the application whether or not it should register with the SCM. This allows developers to test their application interactively, from Visual Studio.

  1. Why does someone typically need or want to write a Windows Service?

The reason a Service should be used is to separate the work from the end-user. 

  • A Service can be started automatically without requiring an end-user to be present. 
  • Services do not stop when a user logs off. 
  • You can control the security context (the "user") that the Service will run under.
  1. What about "server" applications?

It is true that many server applications (IIS, SQL, Exchange) execute as Windows Services.  However, this is *not* because you must write a Service to have a server.  Anyone running "file sharing" applications knows that an end-user can run a server application.  An application launched by the end-user using Explorer can open a socket and listen on it just as easily as an Windows Service.

The reason most Servers are also a Windows Service is so that the Server is not associated with a logged on user.  The IIS Service can start without anyone having to log in, can run under a controlled security context and will continue to run when an interactive user logs out.

  1. So why do problems with Windows Services seem to much harder?

This is for a couple of reasons: 

  • Some developers have the (wrong) belief that Windows Services are special applications.  You can’t "see" the application and this makes it harder for some developers to understand how it works. This confusion often limits the way developers think.
  • Most developers writing Windows Service are writing complicated applications and doing the more complicated tasks. They typically would need to interact with varied and larger number of resources – other services, file system, keep track of system activity etc
  • Debugging a Windows Service is harder because you can’t start it from Visual Studio; it must be started from the SCM.
  • A Service must be fully installed before you can execute it.  This makes the initial "getting started" of development more complicated than with a simple desktop application.
    • Note that there are some easy ways to install a service for dev/test purposes. For example “sc.exe create” can be used to install a service.
  • A Service should never display a UI.  This makes it hard to interact with the service and test it.
  • Q308403 – 308403 – HOWTO: Design a Service to Interact with Multiple User Sessions http://support.microsoft.com/support/kb/articles/Q308/4/03.asp
  1. What information is needed when troubleshooting a customer developing a Service?

You need to do all the same troubleshooting that you would need to do for a regular application.  But of course there are some service issues more common with services also.

  • What exactly is failing?  Does an API executed fail?  What is the failure code?  Was there an exception that caused the executable to crash?
  • Is this a custom Windows Service or a Microsoft Service?  Many Microsoft Services (IIS, SQL) have additional diagnostics available.
  • Does the service fail in a specific configuration?  X86 or x64?  Windows XP vs W2K3.  This question should always be asked but it is often overlooked for "service" issues.
  • What does the service do?  Does it spawn new processes? Does it do database queries?  Does it have socket clients?  You need to understand the basic intention of the service because some technologies simply don’t run correctly from a service.  For example, any GUI technologies have non-intuitive behavior from services.  Understanding the basic intention of the service might provide a good clue about who might best help the customer.
  • Is there an entry in the event log for the service failure?

Here are a few questions more common to services:

  • What security context is the service configured to run under?  This is very important because the failure is often that the service doesn’t have permission to do what it wants to do, or access a resource. This is especially important if the service is trying to access network resources.  Remember that local accounts can’t access network resources.  Special system accounts (Network Service, Local System) can use the "machine identity" while accessing network resources, but this is a special case.

    Running FileMon or RegMon will often give a very strong clue about what failed if the customer thinks that the failure was due to a security check.

  • If configured for LocalSystem, is it also configured to "interact with desktop"? If yes, this is usually an indication of a bad design but is OK for testing purposes.
  • Is it configured to autostart or manually start?  Does an auto-start service also fail if "manually" started?
  • When does it fail?  While starting/stopping/etc?  While booting or shutting down?  Or while accomplishing tasks initiated in other ways (such as due to a client request) or maybe it just randomly stops working?  This can provide valuable clues.
  • For example, the SCM will only start one service at a time and it will wait only a very small amount of time.  This seriously limits what a service developer can do before reporting SERVICE_RUNNING.  This is frequently the problem with services that fail to start. 
  • The "managed" equivalent is "What did you do before returning from OnStart".  There is a very small amount of time available before OnStart() must return.  This means that you have to be very careful about what can be done.
  1. My application works fine as a desktop application, but not as a service…

This is fairly common complaint.  It usually means that the service uses something (a COM control, a registry key, a file) that is installed and works for the interactive user, but not for the user account that the service is running under.

  • Try configuring the service to run as the same user that you log in under.
  • Try logging in interactively using the same user that the service is configured for and run the "desktop" version of the application.
  • Try running the service as "LocalSystem, Interactive with Desktop".  This is a very bad design (search the web for "shatter attack") but can provide a useful data point.

Here is a list of specific things that might be different between a service and a desktop application:

  • Environment differences.  Environment variables might be difference.  Logon scripts are not run for services.  The "current working directory" might be different than what Explorer would set.
  • User Context might be different.  This is especially important when accessing any network resource.  Remember that local accounts don’t have access to the network.
  • Services always run in Terminal Session 0!  This is often confusing and has consequences to a number of different technologies.
  1. How do I debug a service?

This is a large subject with a lot of different suggestions.  There are two reasons why debugging is so hard:

  • Developers can’t simply launch their application in Visual Studio; the service has to be started by the SCM.
  • The SCM will wait only a short time for the service to report SERVICE_RUNNING.  After this timeout, the SCM will assume the process is hung and terminate the process.  Services simply aren’t allowed to hang (or get stuck at a breakpoint in a debugger) before reporting SERVICE_RUNNING.
  • Before troubleshooting a service, it is important to determine what part requires troubleshooting. Is it the start/stop of service that is failing? If yes when – when done from SCM or when restarting the machine? Is the service failing during some execution path? If the startup of the service is failing – you need to use Image File Execution – for this it is important to make the service interactive with the desktop and you many have to increase the timeout period for the service to start.
  • For details please look at http://support.microsoft.com/?kbid=824344
  • To debug the service from Visual Studio you need to launch the service from the SCM and then attach VS to it as mentioned in the KB http://msdn2.microsoft.com/en-us/library/7a50syb3.aspx
  • If you are debugging a .NET service make sure that you debug using the correct version of VS based on the version of framework that your service is using.
  • Note that setting the ServiceBase.AutoLog property can help many service developers

Stay tuned.. Wave


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: