A few months ago, I wrote an article on how you can take control of stubborn system services. That article largely focused on using PowerShell to force a service to start after the service fails to start automatically. Although the techniques that I described in that article work in most cases, there are situations in which a service might be configured to start automatically, and yet fail to start, even after repeated attempts to manually start the service. In this article, I want to look at some of the underlying causes and solutions.
In an effort to show you how to resolve this type of issue, I want to walk you through the diagnostic process on one of the VMs in my lab. I have a VM that is running System Center 2016 Virtual Machine Manager. For whatever reason, the System Center Virtual Machine Manager Service fails to start automatically when the system boots. Attempting to manually start the system services results in a long delay, followed by error 1053, which states that the service did not respond to the start or control request in a timely fashion. You can see what the error looks like in the figure below.
In case you are wondering, 1053 is a general error, and is not specific to System Center Virtual Machine Manager. It can be caused both by system services that are failing to start or by system services that are failing to stop.
Stubborn system services: Cover the basics first
Before you begin the sometimes tedious process of tracking down the reason why system services are not starting correctly, it’s a good idea to check a few basic things. First, make sure that the computer (or virtual machine) meets the minimum system requirements for the application that you are having trouble with. A system with too few CPU cores, for example, may have difficulty starting a service in a timely manner.
Another thing to check is to make sure that the system is up to date. It’s always possible that the service failure is not related to anything that you have done but rather is caused by a bug (I’ve seen it happen). Updating the system with the latest available patches may fix the problem.
Finally, consider whether any recent administrative activities might be causing the problem. For example, have you recently configured the service to use a different service account? If not, is there any chance that the service account password, or even the software license, might have recently expired? You might also consider whether any recent security changes could be impacting the service. For example, I have seen situations in which an incorrect firewall modification prevented an application from being able to access the Active Directory.
Troubleshooting
Assuming that all of the basics check out, the next step in the process is to make sure that all of the dependency services are running. Very often when a service fails to start, the problem isn’t actually related to that service, but rather an underlying dependency.
To check service dependencies, open the Service Control Manager, right-click on the service, and choose the Properties command from the shortcut menu. This will open the properties sheet for the service. Now, go to the properties sheet’s Dependencies tab, which you can see in the figure below.
Now, this is where things get interesting. If you look at the figure above, you can see that this service has no dependencies. The reason why this is so interesting is because this is the System Center Virtual Machine Manager service, and System Center Virtual Machine Manager definitely has dependencies. Some of the dependencies, for example, include Active Directory and SQL Server. You can see a list of the dependencies here.
If the System Center Virtual Machine Manager service had listed dependencies, then the next step in the process would be to check to see whether those dependency services had started and to start those services if necessary. In this case, however, the dependencies exist at the application level, not at the service level. Even so, there is something stopping the service from starting.
Check the event logs
Given that we do not yet know what is preventing the service from starting, the next logical thing to check is the event logs. In my case, the logs contain a rather unhelpful event that simply says that VMM encountered a critical failure and will terminate the process. You can see the actual error below. So in other words, we are attempting to start the service, but the service is encountering a critical failure and stopping the underlying process.
As you look at the event text in greater detail, however, you will notice that it mentions a log file. You can see a portion of the log file in the figure below.
The base exception in this log file indicates that ExecuteReader requires an open and available connection and that the connection’s current state is closed. Further down in the log file (not shown in the screen capture) there are references to SQL Server. Hence, it seems likely that the problem may be related to VMM’s dependency upon SQL Server.
Looking back at the Service Control Manager, I can see that SQL Server is not running, as shown in the figure below.
Fortunately, I have no trouble manually starting SQL Server. With SQL Server running, VMM is also able to start, as shown below.
Although the Service Control Manager is designed to show service dependencies, application-level dependencies may sometimes exist, even though those dependencies are not listed in the Service Control Manager. Like a service level dependency, application-level dependencies can sometimes prevent a service from starting.
Photo credit: Shutterstock
