Better support for Dropbox, Google Drive and other Applications
Programs that allow you to run only a single copy at a time would occasionally prevent AlwaysUp from starting its own copy in the background. For example, if someone started a copy of Dropbox on their desktop, trying to launch a second copy under AlwaysUp would lead to Dropbox exiting quickly and the service failing to start.
Checking the new Stop all copies of the application running on this computer setting on the Startup will resolve the issue. Instead of simply trying to launch a second copy of your program, AlwaysUp will first stop any existing instances, ensuring that its own copy will start smoothly.
We recommend using this setting with the following applications:
… and any others that should only run a single instance.
Additional Power Management Options
To prevent your computer from automatically going to sleep while your important program is being run by AlwaysUp, check the corresponding box on the Extras tab:
Reduced Event Logging
As it runs your application as a Windows Service, AlwaysUp writes information, warnings and errors to the Windows Event Log. Usually this is a good thing, keeping you up-to-date on your application’s comings and goings, but it becomes rather “noisy” for applications designed to start and stop frequently. For example, if you have a batch file configured to run every ten minutes, more than 20 events will be generated per hour!
Check the new Minimize event logging as the application stops & restarts box on the Restart tab to improve the situation. Afterwards, you should only see a message when the application starts or terminates unexpectedly. Normal/expected stops and restarts will not be recorded.
Be sure to check out the AlwaysUp Version History for the full list of features, fixes and improvements included in this release.
Posted onDecember 1, 2014 (Revised September 4, 2021)
If you find that your application is starting and then quickly stopping when you run it with AlwaysUp, your application may be trying to report an error message that you simply cannot see. In this situation, we recommend starting your application from a command prompt running as a service, to find out if something useful is being written to the console.
How to start CMD.EXE as a service on your desktop
Highlight your troublesome application in AlwaysUp and select Add Copy… from the Application menu.
(In this guide, our “StartServer” batch file is failing for some unknown reason so we’ll work with that entry…)
In the Add Application window that comes up:
In the Application field, enter the full path to the windows command prompt. This is:
C:\Windows\System32\cmd.exe
If there is anything in the Arguments field brought over from the application you copied, please remove it.
Change the Name field to something meaningful. We have entered “CMD Testing” in this guide.
Set the Start the application field to Manually, from AlwaysUp. We don’t want this command prompt service to start automatically at boot.
If you have specified a user on the Logon tab, switch over there and re-enter the password (a security measure).
Those are all the changes we need to make so click the Save >> button to record your new service. It will show up on the AlwaysUp console soon.
Next, start the new CMD service on your desktop by selecting Application > Start “CMD Testing” in this session:
In a few seconds, the familiar black box will pop up on your desktop:
And finally, in the command box, type in the full command line you gave to AlwaysUp — application & arguments. Be sure to specify the exact values that you had supplied to your AlwaysUp service! Please cut & paste to ensure accuracy.
Hit Enter to run your application and pay special attention to what is written to the command prompt.
Hopefully at this point your application will tell us what is wrong! In our case (pictured below), the batch file can’t find the JAR file it is expecting…
Once you’ve fixed the problem and verified that your application can start normally with AlwaysUp, please feel free to remove the CMD service by highlighting the entry in AlwaysUp and selecting Application > Remove.
The next version of Windows, dubbed Windows 10 is expected to be released in the second half of 2015. On October 1, Microsoft provided software makers with an early look at the new OS, so that we can test and certify our applications in advance of the launch. And like a kid in a candy store, we downloaded and eagerly installed the Windows 10 Technical Preview on a VirtualBox VM. The most noticeable change? The return of the Start menu! Finally, Microsoft has come to its senses.
Next, it was on to testing our software. Service Protector, which monitors and automatically restarts failing windows services, passed with flying colors. There with no issues whatsoever. Here it is happily monitoring the Print Spooler service:
However, things did not go as smoothly for AlwaysUp, our popular utility that runs any application as a windows service. We set up Notepad.exe as a service but quickly ran into trouble starting it:
After a couple of hours of debugging the code, it turns out that the problem is related to to the little-used user reboot notification feature recently introduced in Windows 8 & Server 2012. To avoid getting too technical, let’s just say that the new capability is simply not accepted by Windows 10. Using it causes AlwaysUp to fail to transition the service into the running state and remain in the starting state. And since no controls are accepted in the starting state, all the action buttons are grayed out and the service will remain stuck starting forever! The only way to stop the service is to disable all recovery actions for the service and forcibly terminate AlwaysUpService.exe from the Task Manager. A real mess!
We have reported the problem to Microsoft and hopefully they will resolve it before the official release of Windows 10 next year. If not, a change to our code to eliminate the user reboot notification feature will also fix the problem, so not to worry. We’ll stay on top of it 🙂
A windows service, designed to run “headless” and unattended in the background, cannot easily employ conventional popup windows to report its activities as a user may not even be logged on. Instead, a service is encouraged to send important communication to the Windows Event Log – an administrative utility that collects and stores messages and events. Once recorded, these messages can be very helpful in troubleshooting problems, for example when a service stops unexpectedly or when it fails to start at all.
Viewing Events from Windows Services
Use Microsoft’s Event Viewer to see messages written to the Event Log. Start the application by clicking on the Start button and typing in Event Viewer, or from the Control Panel (search for it by name). The somewhat cluttered window should come up after a few seconds:
The left hand side shows a tree grouping the various logs captured on your machine. The events from Windows Services (and other applications running on your PC) are filed under Windows Logs > Application. Navigate to that section to load the events in the center of the window, with the entire list in the top and details of the highlighted event underneath:
Messages from your windows service will have the display name of the service in the Source column.
Important Components of an Event
The Event Viewer shows over 10 pieces of information associated with each event, including:
Level – How important is this event?
Each event is classified into one of three categories:
Information: An informative yet unimportant event. You will probably see a lot of these, and they can be safely ignored unless you are digging into a specific issue from an application or service.
Warning: A moderately important event. These don’t necessarily signify a failure, and your software will probably limp along, but they should be reviewed regularly to see if anything mentioned can be resolved.
Error: Indicates a critical problem or failure that may deserve your immediate attention!
Date and Time – When did this event occur?
Source – Which application reported this event?
As mentioned before, an event written by a Windows Service will contain the service’s display name as the Source.
Description – Which happened?
The full description shown prominently in the lower pane will (hopefully) provide the relevant details of the event.
For example, this information event is from the Interactive Services detection service (“UI0Detect”) reporting that Notepad is showing itself in Session 0:
Viewing Events about Windows Services
While the Application log keeps track of events from a running service, the Windows Logs > System area records when services are started, stopped, crash or fail to start. Look for events with the Source set to Service Control Manager (SCM). For example, here is the SCM telling us that the Windows Print Spooler service has crashed:
Viewing Events from AlwaysUp and Service Protector
Both AlwaysUp and Service Protector write messages to the Application section of the event logs (Windows Logs > Application).
For AlwaysUp, events from your application named “My Application” will be logged with Source set to My Application (managed by AlwaysUpService). The Event Log Messages Page lists and explains the events reported.
For Service Protector, events related to your service named “MyService” will have a Source of ServiceProtector: MyService.
And for both applications, events related to the starting and stopping of the underlying services themselves appear in the Windows Logs > System section. Look there if you have a problem with AlwaysUp itself failing to start at boot.
Posted onSeptember 21, 2014 (Revised April 29, 2021)
You need to start your application at boot, even if no one logs on
A regular application will only run after a user has logged in and started it. Not so for Windows Services, which are automatically started by the operating system whenever the computer reboots and run happily without anyone having to do anything. Services are the true set-it-and-forget-it approach.
Your application must be available 24/7
The automatic, extensible failure protection system built into AlwaysUp will help to minimize the downtime for your legacy application — even if it’s buggy, leaks memory or stops working for no good reason!
You don’t have the time, resources or access to the source code to re-write the application as a Windows Service
The boss needs your software to be a Windows Service to win the next contract, but your development team is swamped and no one wants to mess around with the code anyway. Use AlwaysUp to “wrap” your application to operate as a Windows Service so you can satisfy the client and keep your boss happy, all in a day’s work.
You are managing an unreliable application that keeps crashing
Support calls for buggy applications have ruined too many evenings and nights! AlwaysUp automatically restarts unstable applications whenever they stop for any reason. You can enjoy an uninterrupted dinner with your family for a change!
You prefer to run your program in the background, away from inexperienced users
Mission-critical applications visible on the desktop run the risk of being accidentally shutdown by a user or closed when he logs off. However, a windows service runs on a “hidden” desktop where it is well insulated from those using the computer.
(888) 881-CORE
