Posted onJuly 19, 2021 (Revised February 21, 2022)
Our build server has a ton of services installed and it takes a while for them to start whenever the machine boots. One of the services doesn’t connect to the database if it starts too soon. When that happens, I have to log in and start it manually. Is there a way to delay the service until the other services are up and running?
— Christos D.
Hi Christos.
After some brainstorming, our team has come up with four potential solutions for you.
Solution #1: Set your Service to “Automatic (Delayed Start)”
The simplest way to delay a service is to adjust when it starts at boot. Instead of starting as soon as possible, you can tell Windows to launch the service about 2 (or more) minutes after boot.
To make that change:
Start the Services utility.
To do so, press the Windows + R keys to open the Run window, and then type services.msc.
Find your service in the list. Double-click its row to open the service’s properties.
In the Startup type field, select Automatic (Delayed Start) from the list:
Click OK to save your change.
Need to wait for longer than 2 minutes?
By default, all “delayed start” services are launched a couple of minutes after boot. Fortunately, that wait time is configurable and you can set it to longer if you like, but that setting applies to all delayed start services. There is simply no way to adjust the wait time of a single delayed start service.
Solution #2: Specify a Dependency between Services
Another option for delaying the start of a service is to mark it as dependent on another service.
To explain, let’s take two services, Service1 and Service2. If Service1 must start before Service2, you would update Service2 to add Service1 as a dependent. You would say that Service2 depends on Service1.
I know that may be a bit confusing, so let’s look at a real-world example.
Microsoft’s “System Events Broker” depends on a couple of services: “Remote Procedure Call (RPC)” and “RPC Endpoint Mapper”. You can see the relationship in the service’s properties (in the Services application):
Because of those dependencies, Windows will always start the two RPC services before launching the “System Events Broker” service.
Note however, there are significant side effects of setting up a dependency relationship between two services.
For example, the screenshot above also shows that “Task Scheduler” depends on “System Events Broker”. As a result of that relationship, stopping “System Events Broker” will stop “Task Scheduler”, as the Services application informs us here:
You see, the dependency relationship is about much more startup sequence. It implies that “System Events Broker” is critical for “Task Scheduler” to operate.
So if you mark your service as dependent on another service, stopping that other service might stop your own. Make sure you’re OK with that.
Solution #3: Launch your service from an “at startup” scheduled task
Instead of having the Windows Services launch your service, you can shift that responsibility to the Windows Task Scheduler. And in doing so, you can introduce a post-boot delay to start the service after your machine settles down.
Here’s how to create a scheduled task that starts your service a few minutes after boot:
Launch the Task Scheduler.
To do so, press the Windows + R keys to open the Run window, and then type taskschd.msc.
On the right, click Create Basic Task to launch the wizard:
Give your task a meaningful name. For example, we’re restarting the Print Spooler service 10 minutes after boot:
Click Next.
For the trigger, choose When the computer starts:
Click Next.
For action, select Start a program:
Click Next.
In the Program/script field, enter NET.EXE.
And in the Add arguments field, enter START followed by the name of your service:
Click Next.
On the summary screen, check the Open the Properties dialog… box. We still need to make a few adjustments to the new scheduled task:
Click Finish to exit the wizard.
In the Properties window that comes up, affirm a couple of options:
Run whether user is logged on or not. Otherwise, your service will only restart when you’re logged on.
Run with highest privileges. Necessary because starting your service likely requires administrative rights.
Switch to the Triggers tab and edit the At startup trigger.
In the Edit Trigger window, check the Delay task for box and enter your delay in minutes. You may have to type the time as not all values appear in the dropdown:
Click OK to save your change.
Back on the Properties window, click OK to close out of the task. You will probably have to enter your password:
And now that you have a scheduled task to start the service when you want, you should prevent the service from trying to start automatically at boot. Open your service’s properties and change the Startup type to Manual:
Finally, please reboot and make sure that your service starts in the expected time frame.
Solution #4 (for AlwaysUp services only): Pause before starting
If your service was created by AlwaysUp, you are able to stall your application via a configuration setting.
To do so:
Edit your application in AlwaysUp.
Switch to the Startup tab.
In the Pause for field, enter a suitable delay in seconds:
Check the But only after a reboot box — to avoid the pause when you start the service/application manually.
Click OK to save your settings.
The next time your computer boots, Windows will start the AlwaysUp service. And, as you instructed, AlwaysUp will pause for a while before launching your application.
Hopefully one of these methods will work in your situation!
My team manages a few third-party Windows Services. We plan to write scripts that start, stop and restart the services as part of regular maintenance through batch files. Should we use NET or SC? What’s the difference? Is one more reliable?
— Silvia
Hi Silvia.
Yes, both commands are adept at manipulating the state of a Windows Service. For example, both NET STOP and SC STOP will cause a service to shut down.
And both NET and SC are mature, stable and reliable utilities. Apparently Microsoft has worked out all the bugs over the past 30 years. 🙂
However, as far as developing batch files to start, stop and restart services, there is one subtle but important difference between the two utilities.
NET makes a request and waits to confirm…
When you issue a NET START or NET STOP command, NET.EXE:
Opens the Windows Service Control Manager (with OpenSCManager).
Rejects the operation if the service is not in a compatible state. For example, if a stop was requested but the service is already stopped, an error is returned (likely exit code 2).
Requests that the service transitions to the appropriate state (with ControlService).
Rejects the operation if the service is not in a compatible state. For example, if a stop was requested but the service is already stopped, an error is returned (likely exit code 2).
Requests that the service transitions to the appropriate state (with ControlService).
Returns success (exit code 0).
SC does not wait for the service to stop or start.
What the difference means for your batch files
Because SC does not wait for the service to transition to the desired state, you have to be careful when you use SC in batch files.
For example, to restart a service, this sequence looks like it should do the trick:
SC STOP ServiceName SC START ServiceName
And it works, for many services!
Indeed, here is the Print Spooler service quickly transitioning through the PENDING states and ending up running, as desired:
However, things go awry if the service takes a few seconds to stop.
For example, our CloudFileServer service takes 2-5 seconds to terminate (while it closes and uploads transient files to a remote site). The SC script doesn’t fare as well with that service:
As you can see, SC STOP succeeds and the service promptly transitions to the STOP_PENDING state. Unfortunately, the subsequent SC START fails with the “already running” error because the service is still shutting down — it has not yet stopped. And the final result (not pictured) is a dead service — the opposite of what we were hoping to achieve!
On the contrary, the equivalent sequence with the NET command worked much better:
However, NET will run into the same problem as SC if the service takes longer than 30 seconds to stop.
You should pause or confirm when using SC
Of course, you can have SC behave like NET by adding extra code to your script. For instance, adding the TIMEOUT command (which pauses for a fixed period) will give a slow service the chance to stop gracefully before attempting to restart it:
This updated script works well with our CloudFileServer service:
Similarly, you can add code to check the state of the service (with the SC QUERY command) and react accordingly. That approach is more complicated, but it may be worth it in your situation.
Consider ServicePilot when working with slow or busy services
If you are working with services that take a while to start or stop, you should consider using our free ServicePilot command line utility.
Like NET.EXE, ServicePilot will wait to confirm the desired end state. However, ServicePilot allows you to specify the time to wait for the transition to complete.
Here is ServicePilot controlling SlowStopService — our internally developed service which can take up to a minute to stop:
Despite being almost 20 years old, Microsoft’s free Srvany utility is still a surprisingly popular tool. Every week, we come across at least one person using the ancient service wrapper to install an executable or batch file to start at boot as a Windows Service.
Truthfully, Srvany is fine for many situations. It’s basic, and it works. And the price is right.
However, the utility has several shortcomings that aren’t immediately obvious. Here are the top 3 that we (and our customers) have encountered over the years:
Problem #1: Srvany may continue to run even though your application is dead
When it is started, a Srvany service immediately launches its target application. And if the application starts properly and runs without interruption, everything is great.
But what happens if the application crashes or stops running?
To find out, we created a new service that runs the Windows Notepad text editor:
When we started the service, Srvany launched notepad.exe as instructed. Here you can see the service in the “Running” state with Notepad operating in Session 0:
Next, we forcibly terminated Notepad.exe. As expected, the process disappeared.
However, even after Notepad had exited, the service remained in the “Running” state. Misleading, to say the least.
Basically, you cannot rely on the state of a Srvany service to reflect the state of the target application. Just because the service says its running doesn’t mean that the application is!
Problem #2: Srvany may leave your application running after the service stops
As described in this article, when you stop a Srvany service, only the target application is closed. If the target application had launched other applications, those others will not be stopped.
This can be a problem for batch files and applications involving multiple processes.
To illustrate, we installed a new Srvany service that runs a batch file. The batch file starts Notepad:
When we started the service, Srvany launched the batch file, which started Notepad. So far so good:
However, when we stopped the service, only the batch file (cmd.exe) was terminated. Notepad continued to run, alive and well — despite the service being in the stopped state.
Here again, the state of the service does not reflect the state of the target application. But there are unwelcome side effects too.
If we start the service again, Srvany will launch a fresh copy of Notepad. And then we have two copies of Notepad running. This “duplicate” scenario can create chaos for more complex situations, for example with applications that should not run multiple instances. Watch out!
Problem #3: Srvany isn’t particularly user friendly
According to our customers, Srvany comes up short in three areas of usability:
There is no GUI to install your application as a service. You must use a separate command line tool (Instsrv) to create a new Srvany service, which is less than ideal.
To configure the application to run, you have to create keys and values with the Windows Registry Editor — an administrative tool that can cripple your PC if you use it incorrectly.
Srvany is difficult to troubleshoot because it doesn’t write a log file or provide helpful feedback when things go wrong. As a result, frustration often ensues.
For Windows users, software updates are a regular part of life. Vendors like Microsoft, Adobe and Oracle are constantly tweaking their software, which then inundate us with “helpful” nudges. This prompt from printer manufacturer Brother International is a prime example:
Most of the time, you have to install software updates manually. That is, you must take deliberate action to approve and apply the upgrade. For example, in the screenshot above, the new printer driver will not be installed if we never click the “Update” button.
But while manual updates remain the norm, an increasing number of vendors refuse to be held hostage by reluctant users. They choose to deploy software updates automatically, on their own schedule, without securing explicit consent. Products like Dropbox, OneDrive, and Box Drive are members of that new “vendor knows best” group. All apply updates whenever they like.
Yet despite the faint whiff of authoritarianism, automatically installing software has many benefits. To begin with, busy users don’t need to be remember to check for updates or be interrupted to install new packages.
And most important of all, automatic updates have the power to stamp out critical vulnerabilities — quickly and efficiently.
However, those positives are only appreciated when the updated application works as expected, with no surprises. From our own experience, there is nothing more infuriating than software that breaks itself without our consent! 😡
The problem with automatic updates in a 24/7 environment
For mission-critical applications that must operate continuously, updates introduce significant risk. Each change to the application (or the supporting operating system) has the potential to cripple the software — and send blood pressures skyrocketing.
The best practice is to update systems in a controlled manner. Experts agree that it’s safest to make changes during a scheduled maintenance window, when customers are aware that there may be a disruption of service.
After applying updates, staff test and certify the upgraded system. If the team discovers a formidable problem, they roll the system back to the pre-update state to resume service.
Needless to say, automatic updates are the antithesis to a controlled upgrade process.
Indeed, automatic software updates will leave you wondering:
For how long will the software be unavailable during the update?
What happens if the upgrade fails?
How quickly will you be able to restore service if the new software doesn’t work?
Those are very difficult questions to answer when the upgrade process is out of your control.
Running 24/7 with AlwaysUp is at odds with automatic updates
If you’re using AlwaysUp to run an application 24/7, you will likely run into trouble if that application insists on randomly updating itself.
To explain why, let’s examine how most automatic software updates work (without AlwaysUp involved).
Once per day:
The application:
Checks online and realizes that an update is required
Downloads the latest package from the servers
Launches a “helper” application to perform the upgrade
Exits (because integral components cannot be updated while the application is running)
The helper:
Upgrades the application, adding and replacing executable files as necessary
Restarts the application
Cleans up and exits
Unless interrupted, the new version of the application continues to run until the next update is detected and the process above repeats.
Unfortunately the update process can go off the rails when AlwaysUp is ensuring that your application is running 24/7.
Specifically, the trouble starts when the application exits (step 1d). In response, AlwaysUp springs into action and quickly re-launches the application.
And when the helper tries to apply the upgrades (step 2a), it cannot update the executable files because they are in use by the (once again) running application. Ultimately, the helper fails, potentially leaving the application’s components in an inconsistent state. That could spell disaster for a business-critical application!
In fact, one of our customers recently experienced this peculiar predicament when running Dropbox as a Windows Service with AlwaysUp. After a failed auto-update, Dropbox simply refused to copy files to and from the cloud. Fortunately, a technician resumed normal operation by rebooting the server — but only after the customer’s pipeline had been idle for several, costly hours. It was not a good day. 🙁
The best solution: Turn off automatic updates
Naturally, the best solution for business-critical applications is to avoid automatic software upgrades entirely.
And if you’re lucky, your application provides a simple mechanism to disable auto-updates.
For instance, you can easily turn off automatic update checks for the Java Virtual Machine from the Java Control Panel:
For other applications, you may have to cripple (or remove) one or more scheduled tasks that periodically check for updates.
In particular, disabling the OneDrive Standalone Update Task will prevent OneDrive from trying to download and install the latest changes each day:
If you can’t disable automatic updates, configure AlwaysUp to tolerate them
To avoid drama with mandatory auto-updates, please make the following two changes to your AlwaysUp configuration:
1. Introduce a delay before AlwaysUp restarts your application
By default, AlwaysUp restarts your application immediately after it stops. But as we have pointed out, that rapid re-launch can cause headaches for the update process.
To get around that problem, instruct AlwaysUp to restart your application after waiting for a few minutes. Doing so should allow the update process to finish.
To make that change:
Edit your application in AlwaysUp.
Switch to the Restart tab.
Check the Not immediately and After boxes and specify a suitable delay. Five minutes should be enough for most automatic upgrades to complete:
Note however — this delay applies to all situations, not just for auto-upgrades. That is, if your application exits or crashes for any reason, AlwaysUp will pause before restarting it. Hopefully that behavior is acceptable in your environment.
2. Empower AlwaysUp to retake control after an automatic upgrade
After AlwaysUp waits for the update to complete, it will launch a new copy of the application. But that launch can fail if the application is already running.
To remove that potential hazard, we must instruct AlwaysUp to terminate all other copies of the application prior to starting its own copy.
To do so:
Edit your application in AlwaysUp.
Switch to the Startup tab.
Check the Stop all copies of the application running on this computer and Also whenever the application is restarted boxes:
This adjustment will allow AlwaysUp to “take control” of your application after the upgrade concludes.
The EventLog service manages event logs — repositories of events generated by services, scheduled tasks and applications working closely with the Windows operating system.
The service’s display name is Windows Event Log and it runs inside the service host process, svchost.exe. By default, the service is set to start automatically when your computer boots:
You can use the Windows Event Viewer to browse the event logs managed by the service. For example, here are some of the records captured in the Windows Security event log:
What happens if I stop EventLog?
You may find it virtually impossible to stop the Windows Event Log service.
That’s because the service supports several important system services. You can see that list on the service’s Dependencies tab:
And because of those dependency relationships, attempting to stop EventLog triggers a “cascade” that causes all dependent services to stop too. Here you can see Windows alerting us of that situation:
But after we clicked “Yes”, Windows failed to stop EventLog and the dependent services! A peculiar error was returned:
We tracked the issue to “Network List Service” (netprofm). That service refused every attempt to stop it, consistently failing with the error above. And since we could not stop “Network List Service”, we could not stop EventLog either.
Is it OK to disable the Windows Event Log service?
No — it’s not safe to disable the Windows Event Log service.
Indeed, in the very description of the service, Microsoft warns:
Stopping this service may compromise security and reliability of the system.
That advice makes sense because EventLog provides essential support for Windows Services, scheduled tasks, and other background programs. Those components typically run “headless”, without a user interface, and rely on the event logs to record important events.
If the EventLog service stops, those background components will have no way to chronicle their activities. There would be an ominous gap in the operating system’s low-level records.
With that in mind, it’s easy to see why the EventLog service is an alluring target for attackers looking to compromise a system. Once the service has been crippled, vital forensics records may not be captured and intruders could operate with impunity.
Questions? Problems?
If you would like to know more about the Windows Event Log service, or you have a specific problem, please feel free to get in touch. We will do our best to help you!
(888) 881-CORE
![Q&A: Why doesn't OneDrive Delete my Files when Running as a Windows Service? [RESOLVED]](https://www.coretechnologies.com/blog/wp-content/uploads/onedrive-delete-files-problem-150x150-1.png)
