If you would like to read the first part in this article series please go to Troubleshooting Windows Server 2008 R2 Service Startup Issues (Part 1).
Introduction
In my first article in this series I talked about some really basic techniques for troubleshooting problems with services that refuse to start. In this article, I want to conclude the series by talking about five more things that you can do to get a stubborn service to start.
Check the Dependency Services
Sometimes a service may fail to start due to a problem with a dependency. Services can sometimes form a hierarchical architecture in which other services must be running in order for a service to start. Granted, not all services have dependencies associated with them, but dependency services are common enough that they certainly warrant a look if you are having trouble starting a service.
In the old days it was really tough to track down problems with dependency services, but most of the newer versions of Windows make it easy. To check service dependencies, open the Service Control Manager, right click on the service that you are having trouble starting, and select the Properties command from the resulting shortcut menu. When you do, Windows will display the service’s properties sheet.
As you can see in Figure A, this properties sheet contains a Dependencies tab. The Dependencies tab is divided into two sections. The top portion lists the services that must be running in order for the service that you have selected to start. The bottom portion of the tab lists services that cannot be started until the selected service is running. In this particular screen capture you can see that the Windows Firewall service cannot start unless the Base Filtering Engine and the Windows Firewall Authorization Driver have started. You can also see that there are no services that directly depend on the Windows Firewall service.
Figure A: Sometimes the failure of a dependency service may prevent a service from starting.
One thing that is important to keep in mind as you troubleshoot service dependencies is that sometimes the dependencies can form a multilevel hierarchy. If you look back at the figure above, you will notice that there is a plus sign to the left of the listings for the Base Filtering Engine service and the Windows Firewall Authorization Driver service. If you click on these icons then Windows will list any other dependencies that exist within the service hierarchy. As you can see in Figure B, there are multiple dependencies for the Base Filtering Engine service, but no additional dependencies for the Windows Firewall Authorization Driver service.
Figure B: Services can have several levels of dependencies.
Check for Authentication Failures
Services can also fail to start as a result of authentication failures. Most services do not run under the context of the user that is currently logged in. If they did then services would be unable to run in the background while no one is logged in. Likewise, services often require special permissions that are beyond those assigned to standard user accounts. As such, every service is linked to an account that provides the necessary permissions for the service to run.
You can see which account is linked to a service by opening the Service Control Manager, right clicking on the service that you are having trouble with, and choosing the Properties command from the resulting shortcut menu. When you do, Windows will display the properties sheet for the service. You can see which account is in use by going to the Log On tab, shown in Figure C.
Figure C: The Log On tab allows you to specify the account used by the service.
As you can see in the figure, Windows gives you the option of running the service using the Local System account or a specific account. In this particular case, an account called Local Service is being used. In case you are wondering, the Local System account is a very high level account that is used only when the service in question needs to act as a part of the operating system. In contrast, the Local Service account has rights that are more similar to those of a standard user. On occasion you might also see a service configured to use the Network Service account. The Network Service account uses the credentials associated with the machine’s computer account.
Normally if a service is configured to use the Local System, Local Service, or Network Service account then you won’t have to worry about managing the credentials for that service. Windows takes care of this automatically on your behalf (assuming that nothing is broken within the operating system). What can be a problem however, is that some services run under the context of either a local user account or a domain user account. When such service accounts are used, passwords can and sometimes do expire.
When a service account password expires, the problem might not be noticed immediately. However, the next time that the machine is rebooted the service which has been assigned an expired password will fail to start. You can fix the problem by going to the service’s Log On tab and manually specifying the new password.
Keep in mind that a service can fail to authenticate even if the password is correct if the machine in question is unable to communicate with the domain controller on which the service account resides.
Malware Infestation
Certain types of malware infestations can cause system services to fail to start. For example, some antivirus products run as system services. If a virus wants to avoid detection then it may check for the existence of such a service, shut the service down, and then damage the system in a way that prevents the service from being started in the future.
Although antivirus related services are by far the most common target, they are certainly not the only type of service that can be attacked by a virus. Viruses can attack virtually any system service. For example, I once saw a virus that attacked the Windows Firewall Service.
Disk corruption
If you are having trouble getting a service to start then another thing that I recommend doing is checking the system for hard disk corruption. I once ran into a situation in which a system seemed to be perfectly healthy aside from the inability of one particular service to start. No matter what I tried I just could not get this service running. Out of desperation I ran the CHKDSK. Upon doing so, I discovered that the system volume was corrupt and that several operating system files had been damaged.
Unfortunately, CHKDSK was unable to fix the problem. I was however able to make a list of the files that have been damaged and then copy those files from another system that was running the same version of Windows (and the same set of patches).
Time Sync Issues
If all else fails, check the system clock and make sure that the time matches the time that is displayed on your domain controllers. If a service uses the Kerberos protocol for authentication then the authentication process can fail if the computer’s clock falls out of sync with the clocks on your domain controllers. In order for Kerberos to function properly, clocks cannot be out of sync by more than five minutes.
Conclusion
As you can see, there are any number of potential causes for service failures. Fortunately, it is usually relatively easy to get a failed service running again using the steps that I have described in this article series. If you have trouble getting a service running, don’t forget that the Event Viewer may contain valuable clues as to the nature of the problem.
If you would like to read the first part in this article series please go to Troubleshooting Windows Server 2008 R2 Service Startup Issues (Part 1).
