(888) 881-CORE
I set up our application with AlwaysUp but it doesn’t work. When I try to start it, it runs for a few seconds then fails with this error:AlwaysUpService was unable to start the application properly, failing at least 5 times in 1 minute. AlwaysUpService will now stop.
How do I fix this?
— Mark
Hi Mark.
AlwaysUp can fail to run your application for a variety of reasons. Here are the most common.
Reason #1: Your application cannot run in the account specified on the Logon tab
By default, Windows Services run in the LocalSystem account — a special, predefined account created and managed by Windows itself.
LocalSystem is a fine choice for the builtin Windows Services. That’s because it exists on every computer, doesn’t require a password, and is powerful enough to perform a wide range of administrative tasks.
Consequently, when you setup your application with AlwaysUp, the default is to run in the LocalSystem account. You can see that position on the Logon tab, where the box to override using LocalSystem is not checked:
But for many applications, running in the LocalSystem account will not work. This is particularly true for regular, desktop applications that are designed to operate in the account where they were installed.
For example, let’s review a scenario with Dropbox, the popular cloud storage program.
You’ve installed Dropbox on your PC. You’ve also configured it to synchronize your important folders with the cloud. Everything works well and Dropbox copies your files as expected. Happy day!
Later that week, a co-worker logs on to your PC. They open File Explorer, browse to the Dropbox folder and double-click Dropbox.exe (the executable that runs Dropbox). Dropbox starts, but it comes up “blank”. The files and folders you have configured are nowhere to be seen!
No, Dropbox isn’t broken. On the contrary, it’s working exactly as designed.
You see, when you installed and set up Dropbox, the program saved your configuration in a section of the Windows Registry that only your account can access. And when your co-worker logged on and started Dropbox, they did not see any of your settings because they don’t have access to your private area in the registry where Dropbox stored your settings.
Well, the same is true of the LocalSystem account. It cannot access your Dropbox private settings either. So if you start Dropbox in the LocalSystem account, Dropbox will come up “blank” as well.
In essence, the account where you run your application as a Windows Service can have an enormous impact.
Solution
The remedy is simple. Run your application in a Windows account where you know it works.
In fact, if your application runs fine on your desktop right now, you should use your current account.
To specify your account in AlwaysUp:
Start AlwaysUp
Double-click your application to open the Edit/View Application window
Switch to the Logon tab
Check the Instead of running the application… box at the top
Enter your user name and password:
Don’t know the user name of your current? Run whoami at a command prompt to find out.
Save your settings
Hopefully your application will behave better now that you’re running it in the correct account.
However, if you’re still having problems, try starting your application in the current session which will make it visible on your desktop. Select Start in this session from the Application menu to try:
And now that you can see your application, watch out for warnings and errors that are holding up the action.
Reason #2: Your application has a problem unrelated to AlwaysUp
An application that fails to start with AlwaysUp often fails to start without AlwaysUp as well!
For example, that your application can fail to start because:
It was never installed and configured properly in your account
A recent update (or a Windows patch) broke the software
It’s encountering an error that prevents it from working
Solution
Put AlwaysUp aside and launch your application normally on your desktop.
Does it start? Do you see any errors?
How about in the application’s logs? If your application writes to a log file, be sure to check the file for telltale warnings and errors.
If you find a problem, you must fix it before re-engaging AlwaysUp.
As you can imagine, if your application doesn’t run properly by itself, it won’t magically work as a Windows Service with AlwaysUp either!
Reason #3: Your program starts and completes rapidly
When you run your application normally on your desktop, how long does it take to complete?
If it only runs for a few seconds, AlwaysUp may be misinterpreting the quick exit as a failure to start at all!
We saw this scenario most recently with a customer running a Python script with AlwaysUp. The script would check a folder for new files and close within 1 second if no files were found. And when it exited, AlwaysUp would log an error saying that the script failed to start properly and try to restart it again. The end result was to give up after 5 attempts, just as you reported.
Solution
One quick fix is to ensure that your application takes a bit longer to run. For example, if you’re running a batch file, you can add a TIMEOUT statement right before your script exits.
Similarly, you can delay your C++, C# or VB application by calling Sleep (or an equivalent) to introduce a delay prior to a speedy exit.
However, if you cannot modify your application, you can modify how AlwaysUp works. By creating an empty file named alwaysup-dont-panic-on-quick-exit.txt in your AlwaysUp installation directory (by default, C:\Program Files (x86)\AlwaysUp), you will signal AlwaysUp not to treat a quick exit as a failure.
Hopefully one of these solutions addresses your problem. Please be sure to get in touch again if not!
