Wanted to know if there’s a way for Service Protector to not monitor a service during a patching period of time? Or any scheduled period of time without sending a million alerts?
Hi Mark. Apologies for the barrage of unnecessary emails! Unfortunately Service Protector doesn’t know that it is OK for your service to be down while you are patching. It is diligently doing its job.
To avoid the false alarms, we recommend shutting down Service Protector at the start of your maintenance window and reactivating it once patching has concluded. These operations can be performed from the Service Protector GUI or with the standard Windows NET command.
You see, Service Protector creates a Windows Service for each service it monitors. If your service is named “MyService”, then Service Protector creates a service called “ServiceProtector: MyService” to watch your target service. Here is what it looks like for the “Print Spooler” service on our Windows Server 2016 machine:
Note that the service name may not be the same as the friendly “display name” you see in Service Protector (and Services.msc). For example, the service name of the “Print Spooler” service is actually “Spooler”:
How to Stop Protection at the Start of Maintenance
Stopping From the GUI
Select Stop <ServiceName> from the Protector menu. This will shut down Service Protector but will leave your target service running:
Stopping From the Command Line
This command will stop the instance of Service Protector monitoring a service named “MyService”:
NET STOP “ServiceProtector: MyService”
Here is what the process looks like for the Spooler service:
Simply run the NET STOP command before patching starts.
How to Restart Protection at the End of Maintenance
Starting From the GUI
Select Start <ServiceName> from the Protector menu. This will fire up Service Protector — and your target service if it’s idle:
Starting From the Command Line
A slightly different version of the NET command will restart the instance of Service Protector monitoring a service named “MyService”:
NET START “ServiceProtector: MyService”
Restarting protection for the Spooler service looks like this:
Run the NET START command once your system is back to normal.
How to Stop and Restart Service Protection Automatically
For patching that occurs at a defined time, we recommend using the Windows Task Scheduler to automate the process. Create a pair of scheduled tasks — one to stop protection and the other to restart it.
For example, if maintenance occurs every Saturdays from 1 AM to 3 AM, your first scheduled task could run NET STOP at 12:59 AM. The second task could be configured to run NET START at 3:01 AM.
We’re happy to announce a new version of AlwaysUp — our popular application that runs any application 24×7 as a Windows Service. It has been more than 6 months since the last public release so here is what’s new:
Start your application without full admin rights
Windows services are trusted, advanced components. As such, they typically run with full rights. Security mechanisms that limit capabilities — like Microsoft’s User Account Control (UAC) — do not constrain services.
But there are legitimate cases for wanting to run an application in the context of a windows service but without full administrative rights. For example:
You don’t entirely trust the application. Even if it comes from a reputable source, are you 100% sure that it won’t modify private files or read sensitive data?
Your organization operates a “locked down” environment. Government agencies and large corporations often treat security as the number one priority.
Your application requires it. Such is the case with Microsoft’s popular cloud storage solution, OneDrive.
The typical approach for security-conscious folks is to create a new account with limited, non-admin rights and specify that account on the AlwaysUp Logon tab. But that often fails because the entire service is run without admin rights, limiting what AlwaysUp itself can do.
In AlwaysUp 10.5, you can specify an administrator on the Logon tab and check the new Launch the application without admin rights option to ensure that the application operates with limited privileges:
To explore the details behind this new capability, check out our free, standalone Run With Restricted Rights utility. It offers the same functionality, but for folks not using AlwaysUp.
Note: Not every program will function properly without admin rights. Be sure to test thoroughly to confirm that your application is compatible with this new setting.
Smoother shutdowns
Windows shutdown can be chaotic. The operating system must notify each application (and windows service) that it should close — while allowing a waffling operator to interrupt the process.
When AlwaysUp is running an application as a service, confusion can arise when the application receives the shutdown signal before AlwaysUp does. In that situation, AlwaysUp tries to restart the application, leading to unnecessary “thrashing” as the system closes.
AlwaysUp 10.5 does a better job of detecting that a shutdown is in progress — even before it is officially notified by Windows.
Improved support for Windows 10 SHB
The US Department of Defense (DoD) has mandated that “all physically domain-joined computers running a Microsoft Windows based operating system must transition to the Windows 10 SHB (Secure Host Baseline) operating system” — a pre-configured and security hardened version of Windows.
While AlwaysUp is fully compatible with all editions of Windows 10, the stringent security in SHB implementations exposed a couple of bugs in our code. In one situation, AlwaysUp’s main window would become unresponsive and in another, the licensing code would fail. Both of these deficiencies have been fixed and several customers are happily running services on Windows 10 SHB.
Other fixes & improvements
AlwaysUp routinely interacts with the Windows Event Logs. When these logs became unusually large (containing hundreds of thousands of entries), AlwaysUp would take a while to process the entries, causing the main window to occasionally hang. This is no longer an issue now that the underlying code has been streamlined and optimized.
Many customers rely on a sanity check plugin to detect when an application running as a service has failed. Output from those plugins are now captured and emailed, if so configured.
Customers looking to install AlwaysUp silently as a part of their own products had to tolerate an annoying prompt that interrupted the process. That prompt has been removed.
As usual, please review the version history for the full list of features, fixes and improvements included in this release.
Upgrading to AlwaysUp Version 10.5
As per our upgrade policy, customers who purchased AlwaysUp 9 (after September 2014) can upgrade to version 10.5 at no additional cost. Just download and install “over the top” to preserve your existing applications an all settings. Your registration code will continue to work.
Posted onNovember 13, 2017 (Revised April 19, 2022)
Sorry to hear that you are having a problem running your application with AlwaysUp! Windows services can be tricky beasts but our team of experts has spent many years wrestling them into submission. Rest assured that we will do our best to get you up and running ASAP.
As with most technical problems, the devils are in the details. Please answer these six questions to help us diagnose the problem:
What application are you installing as a Windows Service?
AlwaysUp runs thousands of programs, batch files and scripts, but each one brings its own unique challenges. Which one are you trying to run as a service? Is it publicly available? And what does it do?
What version of AlwaysUp are you running?
Each version of AlwaysUp is different. Knowing which build of the software you have installed enables us to offer you the best advice and the most helpful solutions.
To find the version number, start AlwaysUp and select About AlwaysUp… from the Help menu. The 4-digit version number is displayed in the window that appears.
Here you can see that we have 10.4.2.47 installed:
What version of Windows are you running?
The version of Windows installed on your PC can definitely impact your software’s ability to run as a background service. For example, Windows 10 might prevent you from interacting with your application, while older, less secure editions of Windows often behave very differently than their modern counterparts.
Run the helpful winver command to confirm the operating system you are running. A window like this should pop up to report the details:
How have you configured your application in AlwaysUp?
AlwaysUp offers over 40 practical settings to run your program securely as a Windows Service. Some applications run perfectly with only the basic settings applied while others need fine tuning to operate smoothly. We recommend that you send us what you have so far, for review.
To export your application’s settings to a XML file:
Highlight your application in AlwaysUp
Select Export… from the Application menu (shown here for Google Backup and Sync):
Save the XML file in a friendly location. Attach it to the email you will send with all these details.
We’ll take a look and let you know if we see anything fishy!
Are any errors reported in the AlwaysUp Activity Logs?
AlwaysUp writes errors and warnings to the Windows Event Logs — the recommended destination for notifications and alerts from Windows Services. While you can use the Windows Event Viewer to browse recent log entries, it is much easier to see that activity from AlwaysUp:
Highlight your application in AlwaysUp
Select Report Activity > Past Week… from the Application menu:
In a few seconds, your web browser will pop up with a page showing when your application/service was started, stopped, etc.:
Please save the web page (Ctrl+S) or take a screenshot of the browser window and send it to us for review.
What is your Windows user/account name?
Does your application work properly when you start it normally on your desktop? If so, then we know that the Windows account you are currently logged in to has the rights and capabilities required to run your application. It is useful to know if this is a different account than what you supplied to AlwaysUp (on the Logon tab).
To find the name of your Windows account:
Start a command prompt. (Click the Start button and type “command” to find it in the list of programs on your PC.)
Type whoami and hit the enter key. Your windows user name will be printed:
Please include the full account name in your email to our support team.
Send us these details and we’ll get back to you very soon
Your answers to these questions (along with the XML file from step 4) will give us an excellent understanding of what is going wrong. Please email your specifics to support@CoreTechnologies.com and we will review and respond promptly — usually within a few hours.
My company uses AlwaysUp CLT to run our script every 5 minutes as a windows service. The script starts running when the PC boots and repeats every 5 minutes throughout the day. It usually takes a few seconds to do its work on each run.
However we have a nagging problem. After some hundred or more cycles, the script occasionally gets stuck and never finishes! When this happens, my customers get upset because their kiosks aren’t updated.
How can I get AlwaysUp to kill the script and restart it whenever it hangs?
Hi Dan. I’m not sure what your script does, but it is very unlikely that AlwaysUp will be able to tell that the script isn’t working properly. However we can use AlwaysUp’s powerful Sanity Check feature to terminate (and restart) your script when it runs for too long.
To setup the sanity check with the AlwaysUp GUI (we’ll cover the CLT later):
Create a new batch file with a single command: exit 1
Save the batch file to a convenient location on your file system. We have saved ours to “C:\Scripts\hung-sanity-check.bat”. Note the full path to the new file as we’ll need it in a later step.
Start AlwaysUp. Highlight your application and select Application > Edit… to summon the “Edit/View Application” window.
Switch to the Monitor tab. Check the Whenever it fails a sanity check box and click the … button:
In the “Configure Sanity Check” window that comes up:
In the Run section, enter the full path to the batch file you created in the first step.
Using the Every controls, specify a time that you consider “too long” for your script to run. Since your script usually takes a few seconds to run, we recommend entering 2 minutes. That should give an unusually long run some extra time to complete, while ensuring that your customers never experience an outage lasting longer than a couple of minutes.
Also, specify 2 minutes in the Wait for setting and check the Also wait whenever the application is restarted box. These ensure that your script will have time to complete before performing the first sanity check:
Click the OK button and save your settings in AlwaysUp.
With the sanity check monitor in place, your script should never hang for longer than two minutes.
Command line switches for AlwaysUp CLT
To achieve the setup described above with AlwaysUp CLT, specify the following parameters to InstallService:
-t “<Full path to your batch file>”
-a 120
-xd 120
-xr
For example, our InstallService command line looked like this:
For a full description of these and other command line flags, please see the “Customized Sanity Checks” section (page 12) in the AlwaysUp CLT User Manual.
Email alerts?
You may also consider setting up email alerts — to inform you when your script had to be forcibly restarted. A timely notification may help you to diagnose and ultimately fix the underlying problem with your temperamental script. Until then, rest assured that AlwaysUp has you covered!
Windows 10 and Windows Server 2016 contain a curious problem affecting interactive windows services. When you switch to Session 0, you cannot use the keyboard and mouse. This frustrating flaw makes it impossible to interact with any window displayed in Session 0. You can’t even click the “Return Now” button to go back to your regular desktop!
Hopefully Microsoft will fix this bug soon. But if you are using RDP to connect to the server running AlwaysUp, you can use the free and reliable VNC software instead, to resume normal operation in Session 0.
What is VNC?
VNC (which stands for Virtual Network Computing) is a cross-platform technology facilitating remote desktop sharing and control. It is very similar to Microsoft’s RDP. With VNC, you install a software component on the machine you wish to view/control (“the server”) and run another component installed on your local computer (“the client”) to access the server’s desktop.
Which version of VNC should I use?
Several implementations of VNC are available for Windows. We have used (and can recommend) RealVNC, UltraVNC and TightVNC, but this article will focus on TightVNC because it is:
actively maintained
free for both personal and commercial use
fully supported on Server operating systems
already installed and in daily use on our Windows Server 2016 QA/test server! 🙂
Grab the latest 64-bit or 32-bit installer from the TightVNC download page. It will only be a couple of megabytes large.
We will run the installer on both the server and client machines.
Install TightVNC on the Remote Server
Run the installer on your server (the computer running AlwaysUp):
Accept the terms and click Next. When you get to the Choose Setup Type screen, click the Custom button:
On the Custom Setup Type screen, configure the tree so that TightVNC Server will be installed. We decided to omit the TightVNC Viewer since we have no need for that component on the server:
Click Next to continue.
We recommend sticking with the defaults on the Select Additional Tasks screen. It is best to run VNC as a windows/system service so that it starts promptly after a reboot, without anyone having to log in first:
The rest of the installation process should be straightforward so please proceed with your good judgment. Be sure to set strong passwords when you get to the Set Passwords step!
After installing, TightVNC Server will be running in the background as a windows service (and will start automatically when your server boots). Check it out in Services.msc:
Install TightVNC on the Client
Launch the installer to your client computer — most likely your PC with the physical keyboard and mouse attached.
When you get to the Choose Setup Type screen, once again click the Custom button:
On the Custom Setup Type screen, configure the tree so that only TightVNC Viewer will be installed: Click Next to continue.
Again, the defaults on the Select Additional Tasks screen are probably fine:
Follow the remaining prompts to complete the installation.
TightVNC Viewer will be available in the C:\Program Files\TightVNC folder. You may want to place a shortcut to the viewer application (tvnviewer.exe) on your desktop for convenience.
Run the Viewer to Connect to the Server & Switch to Session 0
Start the Viewer application (C:\Program Files\TightVNC\tvnviewer.exe) on your client PC. Type in the host name (or IP address) of the server and click the Connect button:
Next, enter the password you specified for the server (in step 2e) and click OK:
A window showing your server’s desktop will appear. Click the Ctrl+Alt+Del button on the toolbar to sign in to Windows:
Once you are in, switch to Session 0 — either from the Tools menu in AlwaysUp, or via our free Switch to Session 0 utility. You will be able to use your keyboard and mouse!
Here is our Windows Server 2016 machine with both winver.exe and Notepad running in Session 0:
Caveat: Not a solution for one computer
Using the VNC remote access software won’t work if you only have a single computer setup. VNC cannot view itself — not without incurring the wrath of infinity. 🙂 For the single computer scenario, you have to wait for the folks in Redmond to wave their magic wand and fix the bug…
(888) 881-CORE
My company uses 
