Windows Server How-To
How To Troubleshoot System Services
Often times problems with applications refusing to run are related to the failure of dependency services. In some cases the application might display a detailed error message describing the problem, but all too often the administrator is left to figure out the problem on their own.
The first step to diagnosing such a problem is to identify any required services that are not running. Begin the process by entering the SERVICES.MSC command at the server's Run prompt. This will cause the server to launch the Service Control Manager.
As you can see in Figure 1, each service has a status and a startup type. I recommend looking at the list of services to make sure that every service that has a startup type of Automatic is running. Although manually scanning through a list of services might seem tedious, it is easier than using PowerShell. For whatever reason, Microsoft chose not to expose the Startup Type through the Get-Service cmdlet. There is a way to get the startup type using Get-WmiObject, but for one off situations it is a lot faster to manually scan the list of services than to write a script.
[Click on image for larger view.] Figure 1. The Service Control Manager displays the various system services.
If you identify a service that isn't running then you may be able to fix the problem simply by right clicking on the service and selecting the Start command from the shortcut menu. For example, I have a System Center Virtual Machine Manager server that occasionally has trouble starting a specific service at boot time. When this happens I am able to right click on the service and start it manually.
Of course getting a failed service to start is not always as simple as right clicking on the service and choosing the Start command. In my experience, the two biggest causes of service failures are permissions problems or dependency failures.
Dependency failures occur when a service depends on another service that isn't running. Fixing this type of problem involves figuring out which services make up the dependency chain and then determining which of those services are and are not running. Fortunately, this is really easy to do.
You can view the dependencies for a service by right clicking on a service and then choosing the Properties command from the shortcut menu. When the service's properties sheet appears, select the Dependencies tab. This tab will show the services that the service depends on, as well as the services that depend on the currently selected service. As you can see in Figure2, there can be multiple layers of dependencies. For example, the World Wide Web Publishing Service depends on the HTTP Service and the Windows Process Activation Service. The Windows Process Activation Service depends on the Remote Procedure Call Service, which in turn depends on the DCOM Server Process Launcher and the RPC Endpoint Mapper.
[Click on image for larger view.] Figure 2. A service can have a number of dependencies.
If a service is not starting then it is necessary to figure out which service within the dependency chain is actually causing the problem. You can do this by attempting to manually start each service (unless it is already running), starting with the services that are at the deepest levels of the dependency chain.
The other common cause of service failures are permissions problems. Services must have permission to interact with the system. Native services typically receive this permission through the Local System Account. A lot of third-party services also use the Local System Account, but some use designated service accounts instead.
You can check to see what account a service is using by looking at the Log On tab of the service's properties sheet, as shown in Figure 3. If a service is configured to use a Windows account (as opposed to the Local System Account) then I recommend looking for clues that permissions might be a problem. For instance, you can attempt to start the service and then immediately check the Event Viewer to see if the event that was logged is permission related. If so, then check to make sure that the designated account still exists and that its password has not expired. Problems can also occur if the service account password is reset without specifying the new password in the Log On tab for the service.
[Click on image for larger view.] Figure 3. Native services typically use the Local System Account.
It is important to understand that although dependency failures and security problems tend to be the most common causes of service failures, they are not the only potential causes. Services can also fail as a result of disk corruption, buggy patches, or a service account that does not have the correct permissions associated with it (just to name a few). That being the case, I strongly recommend using the Event Viewer to help you to determine the cause of the problem.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.