What’s the “set priority” feature? Why would I use it?
Is AlwaysUp running an important, CPU-hungry application for you? Does that application deserve more resources than other programs on the machine? If so, you’re in luck because AlwaysUp can speed up your mission-critical app by giving it more CPU cycles.
But before we dig into how to do that in AlwaysUp, let’s explore the Windows technology behind the feature.
How Windows runs applications
Windows is a multi-tasking operating system, where your machine’s CPUs are shared between all the programs running on your computer. Behind the scenes, each program gets a periodic slice of the CPUs as Windows cycles through them all.
By default, all programs are treated the same and the CPUs are allocated equally between them. For example, if there are a 100 programs running, each is offered 1/100th of the CPUs over the course of a minute.
But Windows understands that not all programs are equivalent. Some deserve more of your computer’s precious CPU cycles, while others need less.
To support those differing needs, Windows offers a flexible CPU scheduling priority system. With that, you’re able to tell Windows if your application needs more CPU, or less.
AlwaysUp taps into the Windows scheduling system, making it possible for you to tailor your application’s CPU use as it runs as a Windows Service.
Why set my application’s priority?
In general, you do it to make your AlwaysUp application run faster.
And why not give your program a boost — especially if it’s the most important application running on your computer?
We’ll show you how adjust priority in the next section.
How do I set my application’s priority in AlwaysUp?
You can set your application’s CPU priority on the General tab:
Select the best value for your application from the dropdown menu:
Here’s what each option will do:
Idle (only runs when the computer is idle)
Your application will only be assigned a CPU when no other program needs it. That is, only when the computer is idle.
This setting is great for background tasks that should always defer to programs.
Below Normal
Your application needs regular CPU cycles but it’s OK if other programs take most of the CPU. “Below Normal” is appropriate for low-priority tasks that are happy to wait while normal activities take precedence.
Normal
“Normal” is the default priority and most applications run at this level. Windows will allocate a fair and balanced amount of CPU to ensure that your application makes steady progress.
Above Normal
Windows will assign your application a bit more CPU than normal — but not so much that it “starves” other applications.
This is a safe choice if you want to provide a moderate boost for your application.
High
When you select “High”, Windows will move your application to the front of the line and give it the CPU whenever it can use it. That will certainly boost your application but it may prevent other, lower priority applications from running.
Real-time (highest – use with caution)
Set your application’s priority to “Real-time” in the rarest of circumstances. That’s because it’s the highest level and Windows will schedule you application ahead of vital system tasks, and that can lead to unwelcome behavior.
Keep in mind that while AlwaysUp provides the real-time option for completeness, we’ve never come across a real-world situation where it was the answer. Caveat emptor.
What are your best tips for setting CPU priority?
Tip #1: “Above normal” is enough for most applications
If you’re running an important application that should take priority over others, we recommend boosting priority to “Above normal”.
Doing so will ensure that your app takes precedence over all regular applications — but not at the expense of critical operating system functions.
You probably don’t need to go all the way to “High” priority, and almost certainly never to “Real-time”.
Tip #2: Consider limiting your application to specific CPUs too
In addition to setting CPU priority, AlwaysUp can also run your application on specific CPUs. You may find that level of control helpful when you’re managing many applications and need to constrain how CPUs are assigned.
You can find the CPU assignment controls on the Extras tab:
Just pick one or more CPUs and you’ll be good to go.
Why should AlwaysUp stop trying to restart my application?
Let’s be clear: AlwaysUp’s primary job is to make sure that your program is always running. At its core, the software will do everything in its power to prevent prolonged downtime, which can be costly to you and your team.
But even so, there are times when AlwaysUp isn’t able to fulfill its noble mission. And in those rare scenarios, it may be best to fail gracefully instead of continuing to fight an unwinnable battle.
Let’s explore the issue through an example.
Example: A critical network drive vanishes
In this scenario, you’ve already installed your program as a Windows Service with AlwaysUp. Even though it’s running on the PC in your cubicle, the executable sits on a network drive hosted by the file server in your office.
Overnight, a power surge knocks out the file server. It’s completely dead. Your IT team will have to restore it from a backup later that day.
Luckily your PC is still working. When it roars back to life, AlwaysUp immediately tries to start your application. But since the executable sits on the recently departed file server, AlwaysUp fails to start it. The error looks like this:
Undaunted, AlwaysUp will try again — and fail again. In fact, it will keep trying every second, thousands of times, filling up your event logs and not getting anything done. It’s the very definition of beating a dead horse, until you arrive at your desk and manually stop AlwaysUp.
To avoid that futile cycle, you should configure AlwaysUp to give up after a while. We’ll cover that prudent safety net in the next section.
How do I tell AlwaysUp when to give up restarting?
The mechanism is simple. Instruct AlwaysUp to stop trying to restart your application and exit if it fails several times over a given period.
The controls are on the Restart tab:
By default, AlwaysUp gives up if it fails 5 times in 1 minute. That’s proven to be a good safety net for many customers but please feel free to tune the values for your specific application.
Understand that once it hits the threshold you’ve defined, AlwaysUp will shut down. The Windows Service created to manage your application will stop. You’ll see an error like this in the activity report:
After you fix the underlying problem, you’ll have to manually restart AlwaysUp (or reboot your computer) to run your application as a service again.
What are your best tips for using the stop-restarting feature?
Tip #1: Set up email alerts to tell you when AlwaysUp gives up
If you’d like to be notified when AlwaysUp stops trying to restart your application and shuts down, you should configure email alerts.
The final email (after the stop-restarting threshold has been crossed) will clearly communicate what’s going on:
That way, you’ll know that you need to jump in to get your application going again.
Tip #2: If AlwaysUp gives up, troubleshoot your application
If your application repeatedly fails to start, it’s likely a serious problem. It’s certainly not one that AlwaysUp will be able to solve by itself.
You should jump in to troubleshoot. Here are a few things to try:
Start your application on your desktop (without AlwaysUp involved) and see if it reports any warnings or errors.
Try the same command line that AlwaysUp uses to launch your application. To do so, combine both the Application and Arguments fields, making sure to enclose the path in quotes if it contains a space:
Review any log files that your application writes.
Watch out for sneaky automatic updates that break things. For example, if an update relocates your application’s main executable file, you’ll need to update the path in AlwaysUp.
Stopping your application in AlwaysUp triggers a multi-step shutdown process. The goal of that process is to close your application gracefully, without data loss.
Behind the scenes, AlwaysUp sends multiple standard Windows messages to tell your program to wrap up whatever it’s doing and exit. Fortunately, most programs receive those requests, save their work, and quit without any drama.
But some applications would rather take a different approach. Instead of dealing with standard Windows methods, they provide a command-line to invoke a graceful shut down.
In fact, running a “stop command” is often the best way to close an application. That’s because the command often provides additional context and gives the program complete control over how to exit.
Furthermore, we can safely assume that the software implements the stop command for a good reason — and that it should be used when possible.
How do I make AlwaysUp close my application with a special stop command?
Before we get to AlwaysUp, compose the command line that you will use to stop your application:
Start with the full path to the executable to run. Enclose it in quotes if it contains a space.
Follow the executable with all the required parameters for the stop command. Again, be sure to quote parameters with spaces.
For example, if the VirtualBox instructions say to run “VBoxManage controlvm savestate”, your full command will look like ours:
Or to stop nginx, this command does the trick for us:
"C:\nginx\nginx.exe" -p "C:\nginx\htdocs" -s stop
Next, confirm that your command actually does the job. Open a command prompt and ensure that running the command closes your application, as expected.
For instance, we were able to close our VirtualBox machine from the command line just fine:
Edit your application in AlwaysUp.
Move to the Extras tab.
Check the Use this special command to stop the application box and provide the full command you created in step 1.
We entered our VirtualBox command:
Save your changes.
And with that change in place, AlwaysUp will invoke the command whenever it needs to stop your application.
What are your best tips when using a stop command?
Tip #1: Put your stop command in a batch file
Is your stop command complex? Or does it involve multiple operations? For example, do you need to set environment variables before running a program?
If so, you should:
create a batch file that stops your application, and
provide that batch file to AlwaysUp on the Extras tab.
That will be easier (and less error-prone) than trying to cram a complex command line into AlwaysUp.
Tip #2: Give your program enough time to exit
By default, AlwaysUp will wait for up to 30 seconds for your stop command to do its work. If the application is still alive after that period, AlwaysUp will fall back to its regular methods and your program may be forcibly terminated.
If your application needs more time to exit, you should set a suitable extension on the Extras tab:
Tip #3: Test your stop command from AlwaysUp
After installing the stop command, be sure to test that it works from AlwaysUp too.
Try stopping your application from AlwaysUp and make sure that your application concludes in a timely fashion, without errors.
Check:
your application’s log files, to confirm that it shut down properly;
the AlwaysUp activity report (select Application > Report Activity > Today to open it in your browser).
Our team uses AlwaysUp to run a few Python scripts automatically after a reboot. Everything works fine except for one of the scripts that prints to the console. We have AlwaysUp save it for us but we noticed an issue with statements not coming out in the log file. Is there any option in AlwaysUp to make sure that all print statements are saved to the file?
— Sylvia P.
Hi Sylvia, thanks for reaching out.
It’s good to hear that you’re using AlwaysUp’s capture-console-output-to-file feature. That’s the best way to record any text that your Python script prints.
And with that feature active, the file you entered should contain every single line that Python prints:
So your instincts are right: something strange is going on. You shouldn’t be missing any output.
Here’s what we found out when we investigated.
The problem: Python buffers output when not interactive
It turns out that Python handles calls to the print function based on how it’s running.
When you run Python interactively — by launching python.exe at the prompt and typing commands at it — all calls to the print function are immediately and fully processed. In that case, all print statements show up right away, as expected.
But in non-interactive scenarios — for example, when Python is invoked to process a script — Python may hold on to print output for a while before producing it. That’s called output buffering, and it’s in place to improve performance by consolidating many expensive output operations into a single one.
My guess is that you’re experiencing output buffering. Your script’s calls to print succeed, but Python is accumulating characters before efficiently printing them to the console all at once.
The good news is that if you’re happy to do without the performance benefits of output buffering, there are a few ways to ensure that print statements are processed immediately. Pick one of the three solutions we outline below to fix the problem.
Solution #1: Run Python unbuffered
To do away with all buffering when running your script, start Python in unbuffered mode.
You can do that in a couple of ways:
Specify the -u parameter on your python.exe command line, or
To apply the first option, edit your Python script in AlwaysUp and add the “-u” flag to the Arguments field, like this:
That’s probably the easiest fix to implement.
Solution #2: Update your script to call print with the “flush” parameter
Are you able to update the code?
If so, you have additional options instead of running completely unbuffered.
First, you can instruct each call to the print function to immediately produce its text. You do so by adding and setting the flush parameter to True.
For example, if you have this line of code:
print("Hello, World.")
Then this variation will ensure that the text is never buffered:
print("Hello, World.", flush=True)
The benefit of this approach is that you can limit your changes to only the information that you must see immediately.
For example, you can modify only the time-sensitive printouts while still getting the performance benefits of buffering on less important output.
Solution #3: Update your script to manually flush output
If you’re unable (or unwilling) to change the print statements, you can add occasional calls to the sys.stdout.flush() function instead. When you call flush, Python will immediately output all the text it has buffered from previous calls to print.
Simply call flush whenever you need to ensure that all text sent to AlwaysUp. Here’s an example:
Note that with this option, you have precise control over when to clear the output buffer.
For example, you can choose to call flush only after multiple prints (or function calls), like this:
import sys print("I watch the world go round and round,") print("and see mine turning upside down.") print("- Genesis, Throwing it all away") print_lyrics_copyright() sys.stdout.flush()
You’re in charge.
So there you have it, Sylvia. Please be sure to consider each of the solutions and choose the best one for your unique environment. We recommend running Python unbuffered (solution #1) — unless you have special performance requirements.
To the casual observer, a Windows Service seems simple on the surface. It has a name, a startup type, and maybe a logon account. But beneath that calm interface lies a complicated web of permission objects that govern who can start, stop, update, or delete Windows Services.
Most administrators never see this layer directly. But if you’re one of the unlucky few who must venture into service rights, you’ll be disappointed to learn that Windows doesn’t offer much guidance or help. Indeed, by not providing a straightforward user interface out of the box, Windows leaves us to struggle with permissions entirely from the command line.
And that’s exactly why our free Service Security Editor exists. It allows you to easily access what Windows hides — the fine-grained rights and permissions that control your critical background infrastructure.
Read on for a closer look at the hidden security layers controlling your Windows Services.
Windows Service security: The hidden permissions layer
Every Windows Service is protected by a security descriptor. That structure defines who owns the service and which accounts can:
Unfortunately, those permissions are not exposed in the built-in Services application. They’re stored deep in the registry and accessible only via the SC utility and through specialized Windows APIs.
And composing the SC command is crazy complicated. According to this technical post that tries to answer a simple question, here’s the arcane command line you’d run to allow a specific user to control a given service:
As you’ll see later, Service Security Editor translates that mess into clear, human-friendly rights — “Start Service”, “Stop Service”, “Change Configuration”, etc.
Where service permissions can hurt administrators
Misconfigured service permissions are one of the most overlooked causes of:
Failed remote control: A non-admin account can’t start or stop services even when you think it should.
Security vulnerabilities: Overly permissive rights allow attackers to replace or reconfigure critical service exe’s and DLL’s.
Broken automation: Scheduled tasks or scripts fail silently because of missing rights.
Unexpected downtime: Bad things can happen when someone stops a service that should run 24/7 — intentionally or unintentionally.
What Service Security Editor reveals
Our free Service Security Editor opens this hidden world in a simple, graphical interface. With it, you can see (and adjust) exactly who controls your services.
Easily see who can do what: Instantly see all accounts and their assigned permissions in a standard user interface.
For example, here’s Service Security Editor showing us that administrators (and no other individuals) can start, stop or update the Print Spooler service:
Edit rights safely: Grant or remove Start, Stop, Pause/Resume, Configure, and Query rights without touching low-level SDDL strings.
Just check the right boxes instead of fighting with complex, error-prone strings (like A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA) at the command line.
Understand ownership: See which account owns the service (often SYSTEM) and what that implies for administrative control.
Compare services: Spot inconsistencies in permissions across critical infrastructure.
In short, it’s like having a “security microscope” for your Windows Services.
A real-world example: Diagnosing “Access is denied”
One customer reported that a custom monitoring script running in a domain account couldn’t stop a troublesome service. Even though the account was part of the powerful Administrators group, Windows still denied access.
Using Service Security Editor, they quickly spotted the problem. The “Stop” right was missing for everyone except SYSTEM. It turns out that the service’s discretionary access control list (DACL) had been inadvertently customized.
One checkbox click later, their automation was back in business!
When to update Service security (and when NOT to)
Here are a few rules of thumb:
Do adjust when you need to delegate start/stop rights to a specific user or group (e.g. for a monitoring tool).
Do update if a third-party installer locks down configuration unnecessarily.
Do document changes, to keep track of updates. Service Security Editor makes it easy; just save a screenshot before modifying any permissions.
Do not lock yourself out! For example, if you remove your rights to update a service you won’t be able to go back in and make changes afterwards.
Trouble starting or stopping a service remotely?
If you’re looking to start, stop or restart a Windows Service over the network, you may have to jump through a few extra hoops.
To be clear, it’s vital that the account has the necessary permissions to work with the service. That’s non-negotiable, and we’ve seen how Service Security Editor will help you set those correctly.
But the situation is more complicated for remote operations by non-admin users. That’s because in recent version of Windows, only users who are local administrators on a remote computer can start or stop services on that computer. This article digs into the technical details.
Here again, Service Security Editor will help you cut through the complexity. Instead of monkeying around with the registry, just click the Add it button to open up remote access to the service for your non-admin users:
Start seeing what Windows is hiding
The bottom line is that Windows Service permissions are too important to stay invisible.
Idle (only runs when the computer is idle)
Our team uses AlwaysUp to run a few 
