We manage a third-party package that installs a Windows Service with a generic name. I keep having to explain what it means to my team/customers, which can be a pain. How do I change the name of the service to include our company name?
— Garth P
A service actually has two names — the “Service Name” and the “Display Name”.
Both names are prominently displayed in the Services utility:
The Service Name
The Service Name is the unique identifier of the service. As a result, no two services can have the same Service Name (even with differing case).
And Windows restricts the Service Name in a couple other ways too, specifically:
Its maximum length is 256 characters.
Forward-slash (/) and back-slash (\) characters are not permitted.
So the Service Name is the “real” name of the Windows Service.
All command line programs — including the built-in NET and SC utilities — will accept the Service Name as an identifier of the service. And the Service Name identifies the service in the Windows Registry (in < HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services).
However, because Service Names are used in command line operations, they tend to be terse, technical and downright cryptic. To illustrate, here the Service Names of five important services installed on Windows 10:
Only the Windows OS geeks among us will be able to guess what those services do! 🙂
The Display Name
To counteract the caginess of the Service Name, the Display Name records a “friendlier” value, mainly for user interface programs to identify the service. For example, here are the corresponding Display Names of the services listed above:
User Profile Service
TCP/IP NetBIOS Helper
More meaningful, right? When picking from a list, it’s almost always better to show the Display Name instead of the Service Name. That’s what the Services utility does.
Note that the length of the Display Name is also limited to 256 characters but all characters (including forward-slash and back-slash) are allowed.
And perhaps surprisingly, there is no issue with two services having the same Display Name. However, that can be troublesome for lists that rely on Display Name, as we see here with Services:
So which name would you like to change? The Service Name or the Display Name? Or both?
How to change the Service Name
Unfortunately Microsoft has not provided a great way (i.e. an API) for changing the Service Name. No operating system tools will allow you to change that value — not SC, Services or any other application.
However it is possible to adjust the Service Name — provided that you don’t mind working with the Windows Registry.
To change the Service Name:
Open the Registry Editor.
To do so, press the Windows + R keys to open the Run window, and then type regedit.
On the left, navigate to the section where Windows Services are recorded:
We have a service that should restart whenever another service writes a particular event to the Event Viewer. How can I do that?
To create that workflow, you can introduce an “Event Trigger” with the Windows Task Scheduler. However, that will only work if your triggering event is well defined, with a unique, non-zero identifier.
For example, event 1026 — reported when a .NET application crashes — is an excellent candidate:
However, you are out of luck if your entry has a generic ID or is 0, as pictured here:
Unfortunately there is no good way to create a trigger based on a poorly defined event.
How to setup an “Event Trigger” Task that restarts your Windows Service
Assuming that your event has a unique ID, here’s the step-by-step process to recycle your service when the event arrives:
First, create a batch file that restarts your service.
The file should contain two commands — one to stop your service and another to start it again, like this:
For example, here is the batch file we created to recycle the Print Spooler service:
Launch the Windows Event Viewer.
To do so, press the Windows + R keys to open the Run window, and then type eventvwr.msc.
In the Event Viewer, navigate to find and highlight an instance of the entry that should trigger your service to restart.
To illustrate, we’ll work with event 1026 in the Application log:
Right-click the event’s row and select Attach Task To This Event:
That will launch the Create Basic Task Wizard, which is part of the Task Scheduler.
In the wizard, give your task a friendly name. We’re called ours “Restart Service When Event 1026 Occurs”:
Click Next to continue.
Confirm the details of your trigger and click Next to move on:
Choose Start a program and click Next to continue:
Enter the full path to the batch file you created in step 1.
Click Next once done.
Review the summary and make sure everything looks good. This is your last chance to go back and make changes before creating the task.
Check the Open the Properties dialog for this task when I click Finish box. We’ll need to tweak a few settings to ensure that your service restarts smoothly from the batch file.
In the Properties window, 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 restarting your service likely requires administrative rights.
Click OK to continue.
As a security precaution, please enter your password:
And finally, the Event Viewer confirms that it has created your new task:
Click OK to wrap up.
The next time the event enters the Windows Event Logs, the Task Scheduler will run the batch file, which will restart your service.
Managing the new “Event Trigger” Task
The new task will reside in the Event Viewer Tasks section of the Task Scheduler:
You can make adjustments to the task there.
One final Task Scheduler tip: If you see a link labeled Enable All Tasks History in the Actions section on the right, be sure to click it:
That setting tells Task Scheduler to keep a record every time a task runs. And with that tracking in place, after your event has been reported you can check the task’s History tab to confirm that the task ran and your batch file executed successfully.
Bonus #1: Send an email alert when the service restarts
Would you like to be notified whenever the event appears and the service restarts?
If so, you should update your script to call a command line tool that will deliver an email message.
Bonus #2: Use ServicePilot to restart a “slow” service that takes a while to stop
The NET command can run into trouble if your service takes more than 30 seconds to stop. In that scenario, NET STOP gives up and the subsequent NET START will fail because the service isn’t in the right state. The end result is a dead service!
In that case, we recommend using our free ServicePilot utility instead of the NET command.
For example, here is our script that replaces NET with ServicePilot:
Notice the option to give the service up to 120 seconds to stop. You should specify a duration that works for your service.
My company uses AlwaysUp to run 4 applications on our lab server. Every few weeks, one of the applications stops running and I have to log in and restart it. Why doesn’t AlwaysUp automatically restart it?
Here is what I see in the logs:
Hi Sandy, thanks for reaching out. The whole point of using AlwaysUp is to keep your application running 24/7/365 so you are right to be puzzled!
Before digging into the details, let’s review the basics of AlwaysUp.
How AlwaysUp works (a quick summary)
When you configure an application in AlwaysUp, a true Windows Service is created. Let’s call it the AlwaysUp service.
For example, if you setup Dropbox in AlwaysUp, you will see an AlwaysUp service called “Dropbox (managed by AlwaysUpService)” in the Services utility:
When your computer boots, the AlwaysUp service:
Starts before anyone logs in
Launches your application
Constantly monitors your application, quickly restarting it if it crashes or dies for any reason.
The AlwaysUp service is the key to running your application 24×7.
(If you are curious to find out more about the inner workings of AlwaysUp, check out our detailed How AlwaysUp Works explainer.)
What your logs tell us
The activity report shows AlwaysUp running your application continuously for a few days. Then at 7:03:11 AM, your application suddenly stops. And soon after, the AlwaysUp service stops as well.
Your application is not crashing or failing in any way. No errors or warnings were reported and nothing out of the ordinary occurred.
From that benign sequence, we can conclude that someone (or something) intentionally stopped your AlwaysUp service.
And with the service stopped, the only way to restart your application is to restart the AlwaysUp service.
Who stopped your AlwaysUp Windows Service?
Unfortunately the logs don’t say who (or what) stopped the service.
However, there are at least 4 ways that the service could have been stopped:
From the Services application.
For example, clicking the Stop button will terminate the AlwaysUp Dropbox service:
Are there any batch files that manipulate services?
Watch out for maintenance scripts and other background tasks.
Investigate with Windows Service Auditor
If it’s time to put your detective hat on and figure out who’s stopping the service, our free Windows Service Auditor tool should be able to help. It will record all operations performed on the AlwaysUp service.
After downloading and starting Windows Service Auditor, enable extended auditing for the AlwaysUp service. Periodically review the service’s security events, watching for “Stop the service” operations, like this:
Keep the service running with Service Protector
If you are unable to prevent the service from shutting down, consider deploying Service Protector as a second layer of defense.
Install Service Protector, select Protector > Add and choose your AlwaysUp service from the list:
After you save, Service Protector will babysit the AlwaysUp service — to quickly restart it if someone stops it:
Hopefully you will get to the bottom of this unwelcome behavior soon. Please be sure to get in touch if you notice any errors or warnings in the activity reports.
If necessary, click More details to reveal additional information:
Switch to the Details tab and look for the Dropbox.exe process(es) in the list. We found a few on our system:
If you don’t find any instances of the executable in Task Manager, it means that Dropbox isn’t running. Since you’re using AlwaysUp, check for errors — by selecting Report Activity from the Application menu — and see if you can figure out why the service is failing to start.
Note that when Dropbox is running properly, you should find 3 copies of the executable in Task Manager. That is completely normal — it’s just how the file synchronization software works.
Test #2: When you add a file online, is it copied down to your PC?
Now that you know that Dropbox is running, let’s check if it’s copying files from cloud storage to your local computer. Please follow these steps:
Once again, the test was successful on our system. The file appeared as expected:
However, if you don’t see your file, please wait a bit longer. You can confidently declare a failure if the file doesn’t show up after 10 minutes.
Test #4: When you remove a file from your PC, is it removed online?
Local file deletions should be quickly reflected in the cloud. To check on that, please:
Start File Explorer on your PC and navigate to your Dropbox folder.
Delete a file that you don’t need — perhaps the one that you created in test #2.
Note: If you see a confirmation window like this, be sure to check the Don’t ask me this again box before clicking the Delete everywhere button:
If you don’t check that option, the pesky popup may resurface and stall file synchronization. You won’t be there to dismiss it when Dropbox is running invisibly in the background as an unattended service!
Wait for up to 5 minutes. It can take a while for the file synchronization components to recognize the deletion and spring into action.
Go online and confirm that the file has been removed from your cloud storage.
Test #5: When you delete a file from the Dropbox cloud, is it deleted from your PC?
Finally, whenever a file is deleted from your cloud storage, it should soon disappear from your PC’s shared folder. To verify that:
Open your web browser and go to your cloud storage page.
Find a file that you don’t need and delete it from the repository.
For example, we chose to remove the file we created in test #3:
Wait up to 5 minutes for the deletion to propagate to your PC.
Open File Explorer on your computer and confirm that the file has been removed from your local Dropbox folder.
If the file remains after 10 minutes, something is wrong.
Get in touch if any test failed
Did one or more of the tests fail? Please let us know and we’ll be happy to help.
We use Srvany to run our Java application as a service. It starts fine but when we stop the service our Java application does not close. We have to kill the java.exe process in Task Manager. That’s not supposed to happen, right? Is there a registry setting that we are missing that will shut down our application properly when we stop the service?
If Srvany fails to start the application (which will happen if the application/path doesn’t exist), Srvany will:
Inform the SCM that the service has stopped.
Exit, ending the srvany.exe process.
On the other hand, if it successfully launches the application, Srvany will:
Inform the SCM that the service is now running.
Continue to run, listening for subsequent commands from the SCM.
Testing service start with Notepad
To confirm this behavior, we installed a new service (with Instsrv) and configured it to run the Windows Notepad text editor:
We started the service.
With the help of Microsoft’s excellent Process Explorer, here is what the process tree looked like after a few seconds. As expected, there was a srvany.exe process that had spawned a notepad.exe child process:
And Notepad was happily running in the background, on the isolated Session 0 desktop.
When we stopped the Notepad service, Notepad.exe was terminated as expected.
But what happens when running a Java application/service?
Since stopping your Java application didn’t go smoothly, we decided to dig into that specific scenario.
We installed a new service and configured it to launch a Java JAR package:
When we started the service, we saw srvany.exe launch java.exe. No surprises there:
And when we stopped the service, the java.exe process ended and Srvany exited — all good.
So how come it isn’t working for you?
What about a Java application started from a batch file?
After some head scratching, we realized something important. Many of our customers running Java as a service with AlwaysUp don’t run java directly. Instead, they start java via a batch file because it gives them the opportunity to set important environment variables in advance. Could that be an issue?
To answer that question, we created a simple batch file that launched java and installed a new service to run the batch file:
We started the service. Srvany launched the batch file (cmd.exe), which in turn launched Java — all as intended:
However, when tried to stop the service, something unexpected happened. The service stopped and srvany.exe and cmd.exe closed, but java.exe did not exit! The Java process remained running, even after the service had transitioned to the stopped state. It was exactly as you described.
So from these tests, it seems that Srvany will terminate the process it launched (i.e. its direct child process) but will not terminate any descendant processes.
Do you think this is what you are experiencing? If so, please read on for a couple of potential solutions.
Solution #1: Run the Java executable directly from Srvany
Instead of starting Java from a batch file, let Srvany run your Java.exe command line itself. As we have shown above, Srvany is able to terminate Java when it launches it directly.
However, this option may be impractical if your batch file performs lots of setup. But if the batch file focuses on setting environment variables (e.g. CLASSPATH), you can get around that by:
Permanently setting the environment variables in a specific user account, and
Running Java in that account (by specifying the user’s details on the service’s Log On tab).
Solution #2: Install your Java application as a service with AlwaysUp instead of Srvany
Alternatively, if this is a professional setting and a commercial option is acceptable, you can replace Srvany with our AlwaysUp utility.
When you stop a service created by AlwaysUp, all descendant processes are terminated. That is, AlwaysUp will close cmd.exe, java.exe — and any other processes that your Java application spawns. You will never have a situation where your service is stopped but some processes remain alive.