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 16-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.

Featured

  • Microsoft Dynamics 365: Why It May Not Be What You Think

    For starters, the cloud-based CRM/ERP software has some surprising integrations with PowerApps, Microsoft's low-code developer environment.

  • Microsoft 365 Insider Test Program Emerges for Organizations

    Microsoft has started a new Microsoft 365 Insider Program for organizations to test its software, but the program's name and scope could be changing.

  • IT Pros: Don't Forget To Protect Your Personal Security

    Don't be the IT pro who spends way too many hours each day keeping their users secure only to neglect their own home networks. Brien describes the two steps he took to avoid this trap.

  • Microsoft Edge Browser Shifting to Open Source Chromium Platform

    Microsoft plans to align its Microsoft Edge browser production efforts with the open source Chromium Web platform for the desktop version of the browser, the company announced on Thursday.

comments powered by Disqus
Most   Popular

Office 365 Watch

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.