This is a foundational post.  There are a few posts which are coming that require a basic understanding of what a service is and how it is described beyond just knowing where and how to manage services.  This post is more of an abstract conceptualization of what a service is and is intended to lay the groundwork for future posts.

We can all recognize common services and we know where to go to manage these services when we want to start, stop, or otherwise modify them.  But, besides an entry in the Services Management Console, what is a service?

There are two types of services, driver services and installed services.  For our discussion here, we’re going to focus on installed services and their construction.   The construct of installed services includes a few fundamental components which are stored in the services database, including:

  • Type descriptor:  This determines whether the service runs in its own process or shares a process with other services.  You can see shared processes by launching Task Manager (or an even better view with Process Monitor) and finding a SVCHOST process.  These are typically shared processes which are leveraged by multiple services.  This is important in troubleshooting services when a service shares a process.  It is important to understand how to identify shared processes and isolate services into their own process.  A future post will discuss service process isolation.
  • Start Type:  Does the service start automatically, on-demand (manual), or is it disabled?  There is now a category for delayed auto-start as well.
  • Executable:  The fully qualified path to the service program and any arguments which the program should use.
  • Error Control:  Indicates how the service control manager should respond to service startup errors.
  • Dependencies (Optional):  Services which must be started before this service is allowed to start.
  • Account Info (Optional):  A username and password from a local, primary, or trusted domain.  If no username and password is configured, the service will start under LocalSystem.
  • Recovery Info (Optional):  Recovery response information that will be used to recover the service or the system, or to run a custom program, should the service fail unexpectedly.

Okay, so you have probably seen most of that in the Services Management Console and / or SCM’s registry database at HKLM|System|CurrentControlSet|Services.  So what?  What’s the point of this?

The point is that as administrators we often treat services and the functions that they perform as some kind of mystic component of Windows.  We aren’t sure why or how they work and that’s okay with us until they break.  Then we tend to go into a fog about how we should troubleshoot failures or unexpected behaviors.

An installed service, either out-of-the-box or custom, is just an application.  So, when we are troubleshooting services, we should use much of the same methodology that we would use in troubleshooting any other application.

From there, we can look at the unique components of a service as well.  The two major deviations in troubleshooting these service applications are dependencies and type (share process or own process).  While dependency troubleshooting can be fairly straightforward, isolating services which share a process may be a little more confusing the first time and we will be posting a blog about service process isolation in the near future.

A future post will also show you how to use this understanding to create your own service to simplify administrative burdens and automate redundant tasks.