The Core Technologies Blog |
Professional Software for Windows Services / 24×7 Operation
Posted on June 1, 2026  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 interactiveIt 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 unbufferedTo 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 Set the PYTHONUNBUFFERED environment variable to 1 before launching python.exe.
Either option will do the trick. 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” parameterAre 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 outputIf 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: import sys
print("Hello, world.")
sys.stdout.flush() 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. Best of luck with your Python scripts!
Posted on May 17, 2026 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 layerEvery Windows Service is protected by a security descriptor. That structure defines who owns the service and which accounts can: - Start or stop it
- Update its configuration (startup type, executable path, parameters, recovery options, etc.)
- Delete or disable it
- Query its status or read its configuration
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: sc sdset Service-Name D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CR;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)(A;;RPWPDTLO;;;User-SID)S:AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD) Easy peasy! 😩 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 hidingThe bottom line is that Windows Service permissions are too important to stay invisible. Download the free Service Security Editor and uncover what’s really protecting (or exposing) your background services.
Posted on April 6, 2026 Service Protector 11.5 is out! This release enhances Service Protector’s sanity checks — advanced tools that automatically detect subtle failures and restart faulty services. Here’s what the team worked on this time around.
Automatically restart your Windows Service if another service isn’t runningDoes your Windows Service rely on another service to do its work? And must that “supporting” service run all the time too? If so, you’re in luck because Service Protector 11.5 includes a powerful way handle that situation. We created a new sanity check that: Periodically checks if a supporting service is running, and Promptly stops/restarts your main Windows Service if that supporting service isn’t running
To set up this new capability: Edit your service in Service Protector. Switch to the Monitor tab. From there, check the Whenever it fails a periodic sanity check box and click the Set button on the right: In the Add Sanity Check window that comes up, choose Check that a Windows Service is running from the dropdown: Click Next to continue. At this point, Service Protector will show you a list of the Windows Services running on your machine. Choose the supporting service that you wish to monitor. For example, we selected the PostgreSQL Database service on our server: Click Next and follow the self-explanatory steps to complete the process and save your new sanity check.
That’s it. With the new sanity check in place, Service Protector will probe the supporting service every few minutes and take action if it ever stops (for any reason).
Check sub-processes for open network connectionsOne of the most popular sanity checks confirms that your Windows Service has open network connections. It’s great failure protection for network servers that must always be available for web browsers, mobile devices and other client software. Previous releases of Service Protector would only interrogate the executable directly started by the service. And if that executable wasn’t connected to the network, Service Protector would quickly restart it. That approach works for the vast majority of cases, where the service’s main executable does all the work. However, it’s insufficient for more complex situations where the top-level executable launches sub-processes to do the heavy lifting. To illustrate the problem, let’s look at the PostgreSQL Windows Service. As a database server, it must always be listening for connections from software searching through records. Microsoft’s Process Explorer shows us that the service starts “pg_ctl.exe”, which then starts “postgres.exe”. Additional sub-processes are spawned as well: Yet when we examine the tree of processes, we see that “pg_ctl.exe” has no network connections. It turns out that “postgres.exe” handles all communication: Because of that delegation, the old network connections sanity check didn’t work for PostgreSQL. Service Protector examined “pg_ctl.exe” and declared a failure because it has no connections — even though its “postgres.exe” sub-process was happily handling all requests. Oops. Service Protector 11.5 fixes that shortcoming. Instead of interrogating the top-level process alone, 11.5 can now audit the entire tree of processes. Just check the Also check sub-processes box to enable that new capability: Service Protector works for PostgreSQL when the new option is activated. It notices that “postgres.exe” — which was started by “pg_ctl.exe” — has open network connections and the sanity check succeeds. Much better!
Check sub-processes for resource handle leaksSimilarly, the sanity check that detects excessive resource consumption has also been extended to cover the entire tree of processes. When you check the Also check sub-processes box, Service Protector will visit each of the processes created by the service and declare a failure if any of them use more than the maximum number of handles:
Other fixes & improvementsAs usual, this release brings a few internal enhancements as well. Most notably: As usual, please review the release notes for the full list of features, fixes and improvements included in Service Protector version 11.5.
Upgrading to Service Protector 11.5If you purchased Service Protector version 10 (after May 10 2024), you can upgrade to version 11 for free. Simply download and install over your existing installation to preserve your existing services and all settings. That way, your registration code will continue to work. If you bought Service Protector 9 or earlier (before May 10 2024), you will need to upgrade to use version 11. Please buy upgrades here — at a 30% discount. See the complete upgrade policy for more details. Enjoy!
Posted on March 9, 2026 (Revised March 17, 2026) I am test running your Always Up program on two computers to see if we like what it does. The first computer went very smoothly but I get a “Trouble Validating Account” error when saving the user on the second: Everything looks right to me so what’s the problem? I am a member of the local Administrators group so it can’t be a permissions thing. — Sam P Hi Sam, thanks for trying AlwaysUp. Sorry that an error got in your way though! After consulting with our team, we identified five conditions that could cause the trouble. Maybe one of them will apply to your situation. So let’s review each potential reason — and finish off with an easy workaround to get you going again.
Reason #1: You’re not putting in a Windows accountAre you entering a Windows user name and password? It may seem like a silly question, but you’d be surprised how many folks put in credentials for the application they’re trying to run with AlwaysUp. To be clear: your Dropbox, OneDrive or Google Drive login information won’t work. You must provide a user name and password that logs you into your computer.
Reason #2: The account doesn’t have a passwordFor security purposes, AlwaysUp doesn’t support Windows accounts without a password. Your account must have that minimum level of protection. If against all advice you would like to employ an account without a password, you won’t be able to enter it directly into AlwaysUp. You’ll have to resort to the workaround below.
Reason #3: The password is incorrectBy now you’ve surely double and triple checked that you’re entering the correct password for your Windows account. But have you considered any of the following possibilities? Has someone else updated the password? If you’re working on a team, perhaps a colleague made a change recently. Has the password expired? Many systems are configured to demand a new password every few days or weeks, and that can interfere with your use of the account. Try logging in to the computer with your user name and password and see if Windows identifies any problems with the account. If you can’t log in interactively, AlwaysUp won’t be able to run your application in the account.
Reason #4: You’re missing the domainIs your account in a Windows domain? If so, you must enter the domain name as part of your user name, usually in the standard DOMAIN\USER format. For example, we have a user called “Mike Jones” on our systems and all accounts are in the “CTC” domain. Therefore, “CTC\Mike Jones” works in AlwaysUp:
Reason #5: You’re entering a gMSA in AlwaysUp 16 or earlierWhile earlier versions of AlwaysUp fully supported running in a gMSA, you could run into trouble configuring a gMSA. The trouble would come up on the Logon tab, when AlwaysUp verifies the credentials you entered. If you left the password field blank (as you should for a gMSA) that would sometimes confuse the code because it expects each account to be properly secured (see reason #1). Inevitably, verification would fail and you couldn’t set your application to run in the gMSA. The good news is that we fixed the problem in AlwaysUp version 17. You’ll be able to enter your gMSA just fine if you upgrade. And you’ll get many other goodies in the latest version too. However, if upgrading isn’t an option, please execute the following workaround to apply your gMSA.
Workaround: Enter your credentials into Services.mscEven though you cannot enter the account into AlwaysUp, all is not lost. The saving grace is that AlwaysUp creates true Windows Services — which you can manage with conventional administrative tools. And this time, the built-in Services application rides to the rescue. To run your AlwaysUp application in a given account, step by step: First, in AlwaysUp, stick with the Local System Account for your application so that you don’t have to enter any credentials. To do so, uncheck the box at the top of the Logon tab: Save your application in AlwaysUp. Afterwards, you’ll notice that your application’s Log On As column says “SYSTEM”, as it did for our “Transfer Files Python Script”: But don’t worry. We’ll soon set the correct account. Start the Services application (run “services.msc”). In the Services application, scroll the list to find the service that AlwaysUp created for your application. If your application is called “MyApp” in AlwaysUp, look for an entry called “MyApp (managed by AlwaysUpService)”. For example, you can see the entry for our “Transfer Files Python Script” application here: Double-click the service to open its properties. Switch to the Log On tab. Enter the user name and password of the account you’d like to use. To illustrate, we entered a gMSA on our server: Click OK to save your changes. Exit the Services application. Switch back to AlwaysUp. You’ll notice that your application’s Log On As column has been updated to show the new account:
And that’s it. At this point, you’re good to go. Thanks again for trying AlwaysUp and best of luck with your application!
Posted on February 10, 2026 AlwaysUp version 17 is now available to all customers. While the primary focus of this new release is to improve logging and monitoring capabilities for our security-conscious enterprise clients, we managed to squeeze in a couple fresh features as well. The end result is clear — higher uptime and greater security for anyone looking to run their important Windows applications 24/7. So, without further ado, let’s dive in and review the highlights of AlwaysUp 17.
AlwaysUp will automatically restart your script if it hangsWhile the vast majority of folks use AlwaysUp to run exe files, a good portion run scripts. And instead of running 24/7 continuously, those batch files, Python and PowerShell scripts are designed to perform a specific job and exit when done. It’s a beautiful arrangement, because AlwaysUp simply fires them up again a few seconds or minutes later. However, trouble takes hold when a script gets stuck and never completes its work. In that case, the job will remain stalled — and AlwaysUp will let it continue like that, indefinitely. For customers in that frustrating situation, introducing a periodic sanity check is a great solution. The idea is that the sanity check would eventually notice that the script isn’t doing its work and restart it. But it can be difficult to find the right sanity check for each situation. If your script doesn’t write a log file, consume too much resources or map a drive letter, what should you install to detect the misbehavior? It’s a challenge. AlwaysUp version 17 introduces a new option — a simple watchdog timeout. For example, suppose you have a batch file that typically takes about 30 seconds to do its work. To protect yourself against the script getting stuck and hanging until someone notices, you can instruct AlwaysUp to terminate and restart the batch file if it runs for longer than 5 minutes. That safety net will tolerate a long-running script (say, if it has lots of work to do) but provides a solid backstop that ensures the batch file will never flounder for too long. The new feature is available on the Monitor tab, where it’s very easy to set: Be sure to take advantage of it if you’re running a script that occasionally gets its knickers in a twist!
Full support for group Managed Service Accounts (gMSA)Group Managed Service Accounts (gMSAs) have become very popular with Windows administrators. With automatic password management, support for clustered services and built-in security features, what’s not to like? Recent versions of AlwaysUp are compatible with gMSAs but version 17 takes support up a notch. For example, AlwaysUp no longer prompts for a password when you enter a gMSA on the Logon tab: There are several internal improvements as well, to ensure smooth operation as AlwaysUp runs your application in the gMSA.
Extensive reporting to the Windows Event LogsThe experts agree: Logging is a foundational pillar of any effective information security system. Indeed, without the systematic, automated recording of system events, it’s nearly impossible to investigate potential threats and problems. You’re flying blind. Our team is well versed in bedrock ISO 27001 principles so we understand the importance of logging. And in AlwaysUp 17, we rewrote key components to report all sensitive operations to the standard Windows Event Logs. From there, enterprise administrators can pipe those events into Splunk, SolarWinds Security Event Manager, Graylog or any other SIEM compatible with the Windows operating system. Here’s a quick rundown of the major changes in this area: When writing to the Windows Application Event Log, AlwaysUp now sets a semi-unique Event ID value to classify the event. You can use that ID to trigger alerts downstream, as the data makes it to your SIEM. The Event Log Messages page documents the identifiers associated with each record reported by AlwaysUp. AlwaysUp sets the Task Category to “AlwaysUp Events” for every record it creates. Doing so makes it easy for you to identify and group all activity from AlwaysUp — across all applications installed as Windows Services. To improve oversight and accountability, AlwaysUp now reports important application/configuration updates to the event logs. For example, here is event 108 telling us that Administrator modified the Dropbox Windows Service: In version 17, there’s now a “User” column in the Activity Pane. It tracks who performed each activity. The Activity Detail window displays the name of the user as well: Of course, all that information is stored in the Windows Event Logs.
Autologon refinementsSeveral customers rely on automatic logon to run their applications in an interactive user session. Because of that, we continue to make sure that AlwaysUp works well with autologon — safely and smoothly. Version 17 brings one improvement in the area of feedback. If you happen to log in before autologon completes, your application will show a waiting icon that tells you what’s going on: Behind the scenes, there are a couple of code changes that bolster security. First, AlwaysUp now removes any leftover plain-text passwords it finds in the registry, opting for encrypted representations instead. Second, if you disable automatic logon from AlwaysUp, the encrypted password is removed from the secure secrets repository. Even though the password remains obfuscated, there’s simply no good reason to leave it behind.
Other fixes & improvementsCustomers running Python scripts as a Windows Service will notice that AlwaysUp 17 automatically closes Python scripts more gracefully now. There shouldn’t be any warnings about terminating python.exe. Tip: If you find that your script is still being abruptly killed, be sure to update your code to catch the KeyboardInterrupt exception and exit when it’s triggered. Unfortunately, new versions of OneDrive continue to experience trouble running in Session 0. And we remain flummoxed and frustrated with the folks in Redmond. Until there’s a solution, we updated the Application Advisor to warn users setting up OneDrive as a Windows Service that automatic logon may be required: The Google Drive for desktop application now uses Microsoft’s WebView2 component, which is allergic to running as an administrator. We added a warning to that effect when installing Google Drive as a Windows Service: To run more smoothly on Windows Secure Host Baseline (SHB) and other locked down versions of Windows, our developers rearchitected internal components to avoid conflicts related to Data Execution Prevention (DEP) and similar process mitigation technologies. But as much as we want to geek out, it’s far too technical (and boring) to go into the details now. We’ll stop here. Finally, AlwaysUp now supports online registration. You can assign your license directly from the software; all you need is your order reference: Some folks may find it more convenient than the traditional “offline” method.
As usual, please review the release notes for the full list of features, fixes and improvements included in AlwaysUp version 17.
Upgrading to AlwaysUp 17If you bought AlwaysUp version 16 (on or after February 7 2025), you can upgrade to version 17 for free. Simply download and install “over the top” to preserve your existing applications and all settings. Your registration code will continue to work as well. If you bought AlwaysUp version 15 or earlier (before February 7 2025), you’ll have to purchase a discounted upgrade to use version 17. Please purchase upgrades here — you’ll save 30% off the regular price. Please see the complete upgrade policy for additional details. Thanks for reading! Posted in AlwaysUp | Tagged alwaysup, application-advisor, autologon, event-logs, event-viewer, gmsa, google-drive, new-release, onedrive, online-registration, python, python-script, security | | |
