I’m wanting to know what permissions a user is required to have in order to stop and start AlwaysUp services. Is there a way to grant access to specific users as I don’t want to have to give them full Admin rights? I’ve created shortcuts but getting the “access denied” message. Thanks in advance.
— Bryant, Wide Bay Water
Hi Bryant.
Typically, only administrators have the power to control Windows Services. That is an appropriate stance, as most services are administrative in nature.
Indeed, it would be a huge mistake to allow non-privileged persons to stop any of the important tasks servicing the computer in the background. Think of the chaos it could cause!
But there are always exceptions. And the good news is that Microsoft provides the ability to set granular permissions on each Windows Service. You can leverage that API/functionality from command-line tools like Microsoft’s SubInACL but your best option is to work directly with AlwaysUp (which is much easier to use).
How to adjust the rights of an AlwaysUp Windows Service
Follow these steps to grant a non-admin user the ability to start and/or stop your service:
Start AlwaysUp.
Highlight/select the application you wish to grant access to. Stop it if necessary.
Select Application > Advanced > Service Security Settings from the menu.
In the Service Security Settings window that comes up, select the user in the top pane. You will have to add the account if it’s not there.
In lower pane, choose the permissions you wish the user to have.
Here you see us permitting user “Mike Jones” to read/access and start (but not stop) the Plex Media Server service:
Remember: The user must work with the full, quoted name of the service, with the “managed by AlwaysUp” suffix. For example, if your application entry is named “VirtualBox” in AlwaysUp, the service will be named:
“VirtualBox (managed by AlwaysUp)”
Easily adjust the rights of non-AlwaysUp Windows Services too!
The instructions above will work for AlwaysUp services, but our free Service Security Editor tool can adjust the permissions of any service. Check it out if you need a general, portable solution for all your Windows Services.
I’ve download the trial version of AlwaysUp and installed it on a Server 2016 standard machine. I’ve created a Windows service for Plex Media Server and all is working well except for shutting the service down (or restarting).
Every time I restart or shut down the service I’m getting this error:
The application has failed to stop gracefully and may be forcibly terminated. The following processes may be terminated: Plex Media Server.exe, PlexScriptHost.exe, conhost.exe, PlexScriptHost.exe, conhost.exe, Plex Tuner Service.exe, conhost.exe
Can you please let me know what’s wrong?
— Panja
Hi Panja. We can fix this 🙂
But first, a brief explanation of what is going on…
Plex Media Server (PMS) launches several processes
When you start PMS (either normally on your desktop or as a service from AlwaysUp), the main executable (Plex Media Server.exe) spawns a family of processes. Those processes work together, invisibly in the background, to share your files with hungry devices.
You can see the “tree” of up to 8 processes with Microsoft’s Process Explorer:
Exiting PMS from the tray icon closes all the processes
When Plex is running normally on your desktop, you close it by selecting “Exit” from the tray icon menu. The main process receives the signal and quietly closes the other 7 processes. You never witness the behind-the-scenes coordination.
AlwaysUp tries several methods to exit PMS and close all its processes
When you are running Plex Media Server as a background service, there is no tray icon. You must rely on AlwaysUp to shut down PMS and its family of processes.
AlwaysUp tries up to four methods to close the media server properly. The error message you see is reported because the first two methods are unsuccessful and AlwaysUp must move on to the last two, more “aggressive” tactics.
However, looking at the logs, the third stop-method works for Plex. The server isn’t actually being “forcibly terminated”. So though annoying, you can safely ignore the error — it is a false alarm.
But who likes to see a useless error message, right? Here are a couple of ways to eliminate it entirely. Choose one or the other; no need to do both:
Solution #1: Remove the “nointeractive” flag from the arguments passed to Plex
In our step-by-step tutorial, we recommend running Plex Media Server.exe with the -nointeractive flag. This tells Plex that it should not create a tray icon because we cannot access it when PMS is running in the background (in Session 0).
However, when the flag is specified, Plex doesn’t create a main window either. And without a main window, AlwaysUp cannot send Plex the “default” signal to close.
Without the flag, AlwaysUp is able to close Plex smoothly — sans error messages.
To remove the nointeractive flag, edit your PMS entry in AlwaysUp and clear the Arguments field:
There is only one (minor) downside to this solution. Without the flag, Plex will print a warning to its log file every few seconds. This won’t be a problem — unless you are a techie digging into the Plex internals — but it deserves to be mentioned.
To configure AlwaysUp to shut down Plex with taskkill:
Create a batch file with this line:
taskkill /t /f /im “Plex Media Server.exe”
As you can see from the taskkill documentation, this command will terminate PMS and all its child processes.
Start AlwaysUp and edit your Plex Media Server entry
Switch to the Extras tab.
Enter the full path to the batch file you created in step 1 in the Use this special command to stop the application field. And you might as well give taskkill up to 30 seconds to do its work by completing the field below that:
Save your settings
With this solution in place, the next time you stop PMS from AlwaysUp:
AlwaysUp will run the batch file
The batch file will run taskkill
taskkill will close all the PMS processes
AlwaysUp will see that PMS has closed and will set the state of the Plex Media Server entry to “Stopped”.
One of our file ingestion services can take a while to finish all pending database updates and exit cleanly. Sometimes when we reboot the server, Windows doesn’t wait for the service to finish, and we end up with database corruption, which is a huge pain.
How do I get Windows to wait until my service is done and not kill it while it’s still working?
— Jeff
Hi Jeff, sorry to hear of the database corruption!
For obvious reasons, Windows tries to shut itself down as quickly as possible. The goal is to complete the process in 20 seconds or less.
Applications and services that don’t respond within that time frame are classified as hung and are promptly terminated. As you have seen, this can lead to undesirable results.
Clearly this bias towards a quick shutdown makes sense for a desktop computer because a person is likely waiting patiently at the keyboard and mouse. However, it not ideal for servers running important background processes. In the server scenario, where interactive user experience is less of an issue, a safe shutdown should take precedence over a speedy one!
Fortunately there are a couple of ways to swing the balance of power to your Windows Service:
1. Extend the “Shutdown Timeout” for all Windows Services
As far as services are concerned, Windows follows this procedure when shutting down:
Windows informs each service that it should shut down
Windows waits until either:
all services have stopped, or
a fixed period has elapsed.
Windows forcibly terminates any services still running
By default, that “fixed period” is only 5 seconds — insufficient time for your busy service to wind down gracefully.
Fortunately we can extend that period by modifying this registry value:
In the right panel, find the WaitToKillServiceTimeout value. If you don’t see it, create it by:
Selecting Control on the left
Choosing Edit > New > String Value (not DWORD) from the menu
Naming the new value WaitToKillServiceTimeout.
Double-click the WaitToKillServiceTimeout entry to bring up the Edit String window. Enter 60000 in the Value data field (it’s in milliseconds) and click OK to save your change.
Reboot your computer. You don’t have to do that right now, but the new timeout setting will not take effect until Windows restarts.
Note that this modification will not make Windows wait indefinitely for your service to finish. If your service takes longer than 60 seconds, it will still be terminated. Be sure to choose a timeout value that is long enough to cover your scenario, but not too long to make shutdown intolerable.
2. Update your Windows Service to accept Preshutdown Notifications
Changing the WaitToKillServiceTimeout setting is a quick fix but the delay you specify will apply to all services. If another, non-critical service is hung, Windows will wait the full duration before terminating it.
To make sure that Windows waits for your specific service, you should update the code to accept preshutdown notifications.
Clean up and exit when it receives the SERVICE_CONTROL_PRESHUTDOWN notification.
This article reviews the code to be added in C# projects.
How preshutdown works
The preshutdown process was introduced in Windows Vista (circa 2007). As the name suggests, it runs before the regular shutdown process. Its purpose is to give mission-critical services an early start on exiting, ahead of less important modules.
The preshutdown process looks like this:
Windows notifies all services that have registered for preshutdown notifications to exit
For each of those services, Windows waits until either:
the service has stopped, or
a fixed period has elapsed.
Windows proceeds with the regular shutdown procedure (see above)
By default, that fixed period is 180 seconds (3 minutes) — more than enough time for most Windows Services to tidy up and exit gracefully.
But what if you need more than three minutes? Fortunately Microsoft has provided a solution there as well…
How to extend the preshutdown timeout beyond 3 minutes
With a simple code change, a preshutdown service can instruct Windows to wait more than the default 3 minutes for the service to end in the preshutdown phase.
You must add code to call the ChangeServiceConfig2 function with the SERVICE_CONFIG_PRESHUTDOWN_INFO level, and the timeout value in the SERVICE_PRESHUTDOWN_INFO structure set to an appropriate value.
Here is what the addition looks like in C++ (error checking omitted for brevity):
The new code is best called once when you install/setup your service, but it can be invoked during normal operation as well. Whichever works better in your situation.
Hopefully one of these two solutions will delay shutdown long enough to eliminate the database corruption. Please try them, and be sure to get in touch if you have any questions!
Automatically restart your application every 2, 4, 6, 8 or 12 hours
Are you running a legacy application that leaks memory or other resources? Does restarting it cure all ills?
If a daily restart is not enough, you can now recycle your program more frequently — as often as every 2 hours.
The new periods are available in the Every setting on the Monitor tab. Expand the drop-down to select the desired time frame:
Of course, please use this new power with caution. Very few applications need to be restarted 12 times a day! Be sure to consider the impact on your customers, who may be interrupted as your software goes up and down during working hours.
View relevant file information in the “Running” tooltip
When your application is running as a Windows Service in AlwaysUp, you can click the green “Running” circle () to show details of the running process.
That popup now includes additional information. It highlights key “metadata” of the executable file being run:
File description: A free-form description of the file — usually the name of the product or a component (e.g. “Dropbox” or “iTunes”).
File version: The version number of the file. Usually 4 digits in dotted notation (e.g. “5.45.3.1672”) but can also contain a build/version identifier.
File date: The date and time when the file was last modified.
Company: The name of the company that produced the file.
Here is what the new tooltip looks like (when running Plex Media Server as a service):
We added this information to help customers manage change. For example, if an automatic update installed new software and your setup isn’t working as expected, the version number and the date will alert you that the executable file was recently updated.
By the way, you can see most of these values in the executable file’s properties. In Windows File Explorer, right-click the file and select “Properties” to summon an informative popup. The metadata will be available on the “Details” tab:
Receive email alerts whenever the service stops
AlwaysUp can be configured to send you an email alert whenever your application stops. That option is available on the Email tab.
However, prior to this version, AlwaysUp would not send a message when the application was stopped because the underlying Windows Service exited. This was fine when the service was stopped from the AlwaysUp console, but not when the service was being closed by Windows (e.g. as part of a system shutdown). The behavior has been updated and email will now always be sent.
One note from our development team though: Emailing when the system is shutting down may not be 100% reliable. At shutdown, Windows may abruptly close AlwaysUp before it has had a chance to send the email. Furthermore, some supporting systems (which have been signaled to close) may not be available to deliver an email.
Other fixes & improvements
If your application is running and you change the startup type to “Disabled”, AlwaysUp will no longer stop the application. This new behavior is in line with Services.msc.
If an application/service marked as “Disabled” is running, it can now be stopped from AlwaysUp.
Command-line operations to start, stop or restart the application/service were ignoring the “silent” parameter and always showing the progress window. This has been fixed.
Microsoft Visual C++ Runtime Library errors/popups are now classified as fatal. If your application encounters one of these errors, and the “stop when the most serious are encountered” box on the Extras tab is checked, your application will be stopped and restarted as specified.
Several small under-the-hood tweaks for the March 2019 preview of Windows 10 are included in this release. (There were no significant changes to Windows Services in that iteration of the OS.)
As usual, please review the release notes for the full list of features, fixes and improvements included in this release.
Upgrading to AlwaysUp Version 11.8
If you purchased AlwaysUp version 10 (after January 2017) you can upgrade to version 11.8 at no additional charge. Simply download and install “over the top” to preserve your existing applications and all settings. Your registration code will continue to work.
I am evaluating AlwaysUp. I have a legacy application which must run as a local user. I can get it to run as a service using AlwaysUp.
The application works with parameters. These point to a domain folder (eg. \\MyServer\Data1\). There is an obvious contradiction on one hand, running an application as a local machine user, and on the other hand, trying to access a domain folder. Wondering if there is any way AlwaysUp can accommodate this?
I have mapped a drive from the local user to the network folder and cached credentials. This works. Only problem is cached credentials sometimes expire.
— David
Hi David.
Since your application must run as a local user, you should specify the account on AlwaysUp’s Logon tab:
Please enter the username and password for a user that has logged in and run your application successfully — likely the account you are logged into now.
With that account in place, AlwaysUp will run your legacy application in the context of that user. Your program will be able to read from and write to any files that the account has permission to access.
However, as you point out, using drive letters can be tricky. Beyond cached/saved credentials, drive mappings may not be automatically applied when you login as a service. For example, that “P” drive you see in Windows Explorer may not be available to your program running as a Windows Service.
Fortunately, AlwaysUp can usually re-create your drive mappings. Check the Attempt to automatically reconnect all network drives option on the Extras tab to enable that feature:
But as the text implies, automatically reconnecting doesn’t work in all situations. Sometimes a password is required.
To totally sidestep the issues of drive letters when running as a service, we recommend using UNC paths instead of mapped drives whenever possible. Since your account has permissions to the underlying resource, that shouldn’t pose a problem.
Will your application accept a UNC path? Please test to find out.
Troubleshooting network/mapped drives (and other issues)
Change the directory (CD) to the UNC path and confirm that the files are accessible
Run the full command to launch your legacy application with UNC path parameters. If it fails, you may have a permissions issue. Look to your application’s log files for clues.
Best of luck with your legacy program/service! Please get in touch if you have any other questions.