How do I run my application in a normal user account with AlwaysUp?
Most Windows Services run in the powerful LocalSystem account. And that’s the default account used by AlwaysUp when you install your application as a service.
Indeed, you can see that preference on the Logon tab when adding your application in AlwaysUp:
As the instructions say, simply leave the checkbox at the top unchecked and Windows will run your application in the LocalSystem account.
However, if the LocalSystem account isn’t appropriate and you’d like to run your program a different account, you must override the default and specify the credentials for another account. You’ll have to enter a user name and its corresponding password:
Why not run in the LocalSystem account?
We’ve identified a couple of reasons why you may want to avoid the LocalSystem account.
Reason #1: Your application may fail outside of the account where it was installed
Many applications run in the LocalSystem account just fine. They start normally and do what they’re supposed to do, without any problems.
But some programs won’t work as LocalSystem for one simple reason: they were never installed in that account.
You see, when you install an application, it may do a lot more than simply copy its files to your hard drive. In fact, there’s a good chance that it will update your system in one or more of these ways:
Save important information in the Windows Registry. For example, it could record an account number under your personal HKEY_CURRENT_USER key.
Create or update environment variables with crucial configuration details. For example, it could append a folder to your PATH variable, to dictate what programs you can run.
Map a network drive, perhaps to give you access to a repository in the cloud.
The trouble is that those changes may only be visible to the person who installed the software. And when you start the software in a different account, it fails because it can’t find those essential settings.
In summary, if your application’s configuration is tied to the user who installed it, that application won’t function properly as LocalSystem. It’s best to run that program in the account where you installed it.
Reason #2: You may improve security by using a less powerful account
LocalSystem is a mighty, administrative user with full control over your computer. An application running in that account can do almost anything it likes.
While that arrangement may be convenient, what happens if the application is compromised by a security attack? Or if it contains a bug that wreaks havoc by deleting system files?
To remove those undesirable possibilities from the table, you should run your application in a normal user account, with ordinary permissions. Doing so will constrain your application, ensuring that it’s limited by the access rights and privileges associated with the account. In that way, your program won’t be able to do maximum damage if an attacker takes control.
Will AlwaysUp accept a domain account?
Yes, you can enter a domain account on the Logon tab. Simply provide the full user name, with the domain.
Note that AlwaysUp supports user names in the two main formats used by Windows. You can enter a down-level logon name (such as DOMAIN\UserName) or a user principal name (like UserName@example.company.com).
And if you rather not type, you can click the … button to the right of the User name field and select the user from the appropriate location:
Are Microsoft Entra ID/Azure Active Directory accounts supported?
Well, you can certainly specify an Entra ID/Azure AD account on the Logon tab. But, unfortunately, your service may not be able to start with those credentials.
While we’ve not been able to reproduce the problem ourselves, a few customers using Azure AD have reported that AlwaysUp failed to start their service and consistently returned a puzzling error:
The message clearly implies that Entra/Azure AD has a dependency on one or more Windows Services. However, the service has no dependencies and Microsoft has not documented any implicit relationships either. A head-scratching situation, to say the least.
Note that the dependency problem has nothing to do with AlwaysUp. In fact, the folks who encountered the issue got the same error when they used the Azure AD account with any Windows Service — without AlwaysUp involved. It’s an Azure AD account thing.
What happens to my AlwaysUp application/service if the account’s password changes?
If you change your password, your AlwaysUp application/service will continue to run normally. Windows won’t stop or interrupt it in any way.
However, once the service stops, you won’t be able to start it again. Windows won’t be able to launch it at boot either.
AlwaysUp will report a logon failure, like this:
While the built-in Services application will throw Error 1069:
And, unsurprisingly, the NET START command will also fail, citing Error 1069:
You’ll have to edit your application in AlwaysUp and supply the new password to fix the problem. Once you do that, AlwaysUp, Services and NET.EXE won’t have any trouble starting the service.
Please keep that in mind for the next time you update your password!
Posted onSeptember 12, 2024 (Revised October 20, 2024)
Recently, customers using AlwaysUp to run OneDrive 24/7 have been reporting a puzzling problem. Even though OneDrive starts as a Windows Service in Session 0, it doesn’t do its job. Files aren’t synchronized and AlwaysUp reports that “OneDrive has no network connections to the cloud”.
Our team jumped in quickly to investigate. Here’s what we’ve learned so far:
The problem seems to be related to newer builds of OneDrive (or a recent Windows update) published after June 2024.
The issue affects customers on Windows Server 2019 and 2022. To date, all the complaints have come from folks running those operating systems.
Not all customers on Windows Server are affected. Some customers on Server 2019 and 2022 continue to run OneDrive in the background just fine.
We’ve not been able to reproduce the network failures. Indeed, OneDrive will run continuously in Session 0 on our Windows Server machines, syncing files for many days:
OneDrive fails only in Session 0. If you start OneDrive in your current session (by selecting “Start in this session” from the “Application” menu), files are synchronized without issue.
Troubleshooting the problem
OneDrive is notoriously difficult to debug. The reality is that Microsoft doesn’t provide any documentation or insight on the inner workings of its flagship file synchronization software. And the sparse release notes aren’t helpful either.
That lack of guidance leaves small, independent developers like us scrambling to understand how the OneDrive works — and trying desperately to figure out exactly what’s changed as the developers in Redmond tinker with the software.
At this point, the technical log files are our primary source of inspiration. Fortunately we were able to examine the files provided by a couple of customers.
A few clues from OneDrive’s log files
One of the log files we examined suggested that OneDrive has trouble automatically signing in when running in Session 0.
From what we can tell, OneDrive tries to log in by calling AcquireCredentialSilently — a function that attempts to authenticate the user. Apparently an appropriate token is found but it needs to be refreshed. And eventually, the function fails without finding credentials in the cache.
This excerpt from the OneDrive logs tells the story:
But we only saw that behavior a couple of times. And unfortunately we don’t yet know how to remedy those authentication problems.
We need your help!
Since OneDrive works perfectly in Session 0 on our servers, we must depend on the benevolence of our knowledgeable customer base to help us troubleshoot. Indeed, here are the top three ways that you can help us figure out the best way forward.
1. Try early, “Insider” releases of OneDrive
Our fervent hope is that Microsoft fixes the problem in their code and restores OneDrive functionality in Session 0. That would be the best outcome for us all.
You see, Microsoft produces an updated version of OneDrive every few days. And you can find those new builds at Hans Brender’s site:
Those “Insider” versions are early, hot off the press releases. They contain the latest changes from Microsoft, which are destined to make it into a “Production Ring” release and ultimately deployed to everyone.
Maybe we’ll get lucky and the logs will highlight how things are failing on your system — and point our development team in the right direction.
3. Allow us to connect to your server remotely to troubleshoot
Experiencing the problem firsthand — and being able to try potential solutions — gives us an excellent opportunity to devise a solution.
If you can, please arrange for someone from our team to access your server remotely. We’re happy to work at a time of your choosing and under your supervision — whatever’s convenient for you.
We’re generally available between 9 AM and 4 PM US Pacific time (GMT-7/8). Contact us here.
A workaround: Setup automatic logon to launch OneDrive in a normal, interactive session
In all our tests, OneDrive works perfectly when it runs in a normal login session. Indeed, if you start OneDrive in your current session (by selecting “Start in this session” from the “Application” menu) from AlwaysUp, your files will be synchronized quickly and completely.
With that adjustment in place, OneDrive will start properly at boot and you won’t have to deal with the peculiarities of the isolated Session 0 anymore. Most importantly, you can stop worrying about OneDrive — and move on to tackle your next, pressing dilemma. 😕
Posted onAugust 6, 2024 (Revised November 11, 2024)
We’ve been deploying AlwaysUp with our products for years. We use it to run as services, many small programs we have developed as simple “stay in the tray area” windows applications.
But lately, my co-workers have been criticizing that approach. They say that what AlwaysUp does is “dirty” because “Windows Services should not have any user interface”. They are afraid that one day Microsoft will want to enforce this by making it impossible to run any application that tries to open a user interface as a service. And then AlwaysUp wouldn’t work for our programs.
Do you think this true or are my colleagues mistaken?
By the way, I’m kinda reluctant to convert all our small programs — developed in Delphi — to proper services because debugging a Windows Service in Delphi is a huge pain and very rarely works (no matter what Embarcadero says). Thanks for creating a pragmatic alternative!
— Carlo
Hi Carlo, thanks for reaching out.
Your colleagues are mostly right when they say “Windows Services should not have any user interface”. Indeed, that’s very common advice given to developers constructing services today.
But in reality, that statement is overly restrictive and misses the mark. A careful reading of Microsoft’s technical articles and documents reveals that interfaces alone aren’t bad. And Microsoft’s actual advice to those developing services is “don’t design a Windows Service that must interact directly with a logged-in user”.
And, in light of that more accurate statement, you’ll be happy to know that there’s no indication that Microsoft will ever prohibit a Windows service from creating an interface. It simply won’t happen.
Let’s dive into the details to understand why.
What are the problems with a Service having a UI?
Back in the ancient days of Windows XP, Microsoft was happy for any Windows Service to present a user interface. It was even encouraged and many, many applications took advantage of that convenient design.
You see, Windows Services run in Session 0 — the session created when your PC boots. And because of that, all windows created by a service show up in Session 0. That’s always been the case — and remains so today.
In XP and before, the user logging in to the console would also be assigned to Session 0. All their desktop applications would run in that shared session too. As a consequence, that user would see any windows created by a service alongside his own, running on his desktop. This picture from Microsoft’s blog illustrates the arrangement:
Unfortunately, that lax architecture created a couple of problems.
Problem #1: Support for multiple simultaneous logins complicated interactive services
The visibility of interactive services was clear when only a single user could log in to Windows. The user who logs in could see any UI elements the services created.
But with the advent of Fast User Switching — where multiple people can log into a PC simultaneously — the situation became murky. Important considerations like these arose:
Why does a service’s UI only show up for only one person at a time?
Why can’t everyone logged in see the windows from an interactive service?
How can we make sure that the “right” user sees the service’s windows?
Unfortunately, there were no good answers for those questions. And as a result, we had strike one against interactive services on modern computers.
Problem #2: Mixing services and regular programs invites misbehavior
Second, and more importantly, the issue of security came to the forefront.
As mentioned before, Windows Services and all the programs launched by the first logged-in user would run in the same session (Session 0). But as it turns out, there are serious shortcomings of that architecture!
In “Exploiting design flaws in the Win32 API for privilege escalation”, Kristin Paget showed how a normal user could gain powerful admin rights by exploiting a Windows Service running interactively on his desktop. The attack was straightforward and Paget easily demonstrated how a virus lurking in an untrusted application could gain full access over your PC and create chaos. Ouch!
After initially downplaying the situation, Microsoft admitted that its flagship operating system was vulnerable. They moved quickly to patch it. And sure enough, the next version of Windows (Vista) eliminated the problem.
Microsoft solved both problems by isolating Session 0
The folks in Redmond negated both the interface and security problems in one fell swoop — by locking down access to Session 0. In no subtle terms, they pledged to reserve Session 0 for Windows Services and prohibit users from logging into that protected area.
In a nutshell, there would be no mixing of secure services and regular, potentially insecure applications in the same session. Services would run in Session 0 and user initiated programs would run in Session 1 and higher.
And with isolation in place, all talk of a service showing a UI has been rendered moot because no user would be able to see that UI.
Kudos to Microsoft for addressing both problems in a simple and effective way!
But Microsoft chose not to outlaw interactive services
Despite all the adjustments, it’s important to note that Microsoft didn’t plug the security hole by preventing a Windows Service from creating a UI.
Even though enforcing such a restriction would have disarmed Paget’s shatter attack, it wouldn’t have addressed the root problem — the dangerous mixing of highly privileged services and untrusted programs in the same security context.
It’s clear that if that risky co-mingling was allowed to persist, it would only be a matter of time before unscrupulous characters found another way to break in to powerful services running in the same session. So Microsoft focused on that problem.
Indeed, the engineers realized the truth — that interactive services pose no danger once they’re protected from untrusted code.
Today, Microsoft has no compelling reason to prevent a Windows Service from having a UI
With the security holes plugged and application developers no longer having to wrestle with the complexities that stem from visually interactive services, Microsoft has zero incentive to prevent services from creating UI elements. There is simply no upside for them.
On the other hand there is tremendous downside from shackling services in that way. Without a doubt, many of today’s services would break, thereby causing unnecessary nightmares for Microsoft and the thousands of independent programmers who’ve written services for the platform.
Furthermore:
All the documentation for Win32 GUI functions would need to be updated to signal that they don’t work in services or Session 0;
Programmers would face increasing complexity, forever burdened with having to understand where API functions work and where they don’t;
New API-level error codes would need to be introduced to signal when the new UI restrictions were violated.
In summary, it would be a significant undertaking to prevent services from creating a UI. And to what end?
Yes, Microsoft is far from perfect. The 2024 CrowdStrike outage reminded us of that. But they’re certainly smart enough to avoid intentionally shooting themselves in the foot for no good reason, which crippling Windows Services would surely do.
What is a scheduled restart and how can it help me?
We designed AlwaysUp to run your important programs 24/7, 365 days a year.
However, few Windows applications are built to run continuously for days and weeks. Sure, they start out great at first but soon enough they use up all your RAM, bog down the CPU, stop responding to network requests, or misbehave in some other way. Eventually, they break down.
If you’re lucky, that deterioration takes a long time. Indeed, you probably won’t even notice a slow decline if you routinely close the program before it becomes unusable.
But memory leaks and other imperfections eventually come to the forefront when you leave some programs running for a long time.
Regularly restart your program, to keep it “fresh”
The solution for a leaky program is to restart it every now and then. If you don’t give it a chance to run for too long, it won’t have time to deteriorate and fail.
How do I make AlwaysUp restart my application at a regular time?
To make AlwaysUp restart your application periodically, you have to:
Configure AlwaysUp to stop your program at the desired time, and
Tell AlwaysUp to restart the application whenever it stops.
Here’s how to do that.
Step #1: Configure AlwaysUp to stop your program at the desired time
To stop your application on a schedule, edit your application in AlwaysUp and switch to the Monitor tab. From there, check the Every box to enable the “scheduled stop” functionality:
If you expand the Day drop-down, you’ll see that AlwaysUp can stop and restart your program at different intervals. That includes:
Multiple times per day — every 1, 2, 4, 6, 8 or 12 hours;
Once every day;
Once per week, on the day of your choice.
Choose the period that works for your situation. From what we have seen, many customers favor once per week, with Sunday being the most popular day.
After selecting the period, you should set the time you want AlwaysUp to stop your application. Be sure to pick a time that minimizes disruption for anyone using your application.
Note that for hourly periods, the time is the first time to recycle your application. For example, if you choose to restart every 2 hours and you set the time to 5:00 PM, the first restart will take place at 5 PM, the second at 7 PM and the third at 9 PM. And AlwaysUp will continue that cadence until it’s interrupted.
Next, you can tell AlwaysUp to avoid restarting if your program is busy or someone is using the computer. Just check the But only if the following conditions are met box, choose your metrics and define your thresholds:
And finally, check the Reboot the computer option if you want AlwaysUp to restart the PC. Sometimes that’s necessary if the operating system becomes sluggish or unresponsive over time.
Step #2: Tell AlwaysUp to restart the application whenever it stops
By default, AlwaysUp will restart your application immediately after it stops. Because of that, you may not have to make any changes here.
You can find the setting on the Restart tab:
Once you’ve checked the box at the top, you’re good to go. If it isn’t checked, AlwaysUp will not revive your application after the stop you configured in step 1.
Can you show me a few examples?
Sure!
Example #1: Restart every Sunday at 3 AM
Here’s what it looks like to stop your application once per week, early on Sundays:
Example #2: Restart hourly starting at midnight
If you’re running an unstable program, please accept our sympathies!
In that unfortunate situation, you can have AlwaysUp reset the buggy app every hour, at the top of the hour, like this:
Example #3: Reboot your computer daily at 1 AM
If restarting your application isn’t enough, you can setup an off-hours reboot like this:
What are your best tips for scheduling a restart?
Tip #1: Choose a “quiet” time to restart your application
Stopping and starting your application can be disruptive. What if someone is using the software at the time?
To reduce the chance of interruption, please stop your application at a time when no one is likely to be using it. At a minimum, try to avoid normal business hours. And if you can, confine the drama to the weekend or maintenance window. What time works best for you and your team?
Tip #2: When rebooting, only proceed if no one is logged on
Instead of simply restarting your application, you can choose to reboot the entire PC. But do you really want to do that if someone is logged in? That may result in frustration — and lost work.
So if you’re going to reboot, please consider activating the No one is logged on to the computer condition:
Can you tell our readers a bit about Visual Approvals?
Visual Approvals is dedicated to empowering Australia’s building surveying businesses by simplifying the intricate building approval processes. Our mission is to reduce risk and foster growth within building certification businesses. We envision our software setting new standards of excellence in the building certification and regulatory sectors.
Streamlining approvals through extensive experience
Since our founding in 1998, we have deeply engaged with the building certification industry. From the outset, we have collaborated closely with essential stakeholders like building certifiers, engineers, architects, and town planners. This hands-on experience provided us with invaluable insights and feedback about the building approval process’s complexities and requirements. Leveraging this knowledge, we developed our software to streamline business processes and enhance efficiency.
Simplifying approvals with robust software
The complexity of the building certification process meant our goals were not achieved overnight. However, through continuous industry collaboration and rigorous software testing and refinement, we have succeeded. Today, we proudly offer a comprehensive building approval software solution that streamlines the entire process and equips certifiers with the tools they need to excel.
Committed to meeting industry needs
Our commitment to meeting the evolving demands of the building certification industry drives us to continually engage with industry stakeholders and seek improvement opportunities. Visual Approvals is dedicated to adapting to the changing building approval requirements and regulatory standards across all states and territories, delivering significant efficiency savings to the building and construction industries.
Why does Visual Approvals use AlwaysUp?
Many of our customers rely on Dropbox or OneDrive for their documentation, requiring them to be always operational. AlwaysUp ensures that the tools run continuously, regardless of whether the user is logged in, as long as their machine is turned on.
When a new or existing client opts to use Dropbox or OneDrive for their documentation, we install AlwaysUp to support this requirement.
We’ve been using AlwaysUp for the past ten years, and it has consistently met our needs.
What business problem does AlwaysUp solve?
We needed a solution to ensure that Dropbox or OneDrive were always running, facilitating seamless document transfer between the cloud and the customer’s PC.
To explain a bit more, understand that our customers are constantly on the road performing building inspections. Each person uses an iPad to complete necessary documents which are then copied to the cloud (OneDrive or Dropbox) and shared with the main office. It’s important that those documents are uploaded quickly and seamlessly.
By running AlwaysUp on the PC in the main office, we can rest assured that the documents edited on the iPad will make their way to the customer’s office, even if no one is in the office (or logged on to their main computer).
How many installations do you manage?
We’ve purchased an Unlimited OEM license for AlwaysUp, allowing us to install as many as needed to support our growing client base.
Did you evaluate any competitors of AlwaysUp?
Not really. We started out thinking we’d have to develop our own solution but we decided against that once we found AlwaysUp. We didn’t feel the need to look elsewhere because:
#1: AlwaysUp provides exactly what we need
We were able to install OneDrive and Dropbox in AlwaysUp in minutes. Any software we developed would be doing exactly the same thing — but then we would be responsible for maintaining it ourselves, and that would distract us from our main work.
#2: We received excellent product support
The team at Core Technologies is very attentive. They get back to us promptly whenever we have a question or hit a problem. For example, when Dropbox stopped working as a Windows Service for some of our customers a few years ago, Core Technologies was able to resolve the problems in a few weeks.
What are your favorite features of the software?
The most appreciated feature is its reliability. AlwaysUp keeps Dropbox running smoothly and notifies us if the system stops. While it likely offers more functionalities than we use, the features we rely on are stable and dependable.
Any other comments?
Working with Core Technologies has been a great experience. Their support team is responsive and helpful. We would highly recommend AlwaysUp to others needing a solution for continuous program operation.
In particular, AlwaysUp has been crucial for our iPad app, which uploads and downloads documents to and from Dropbox or OneDrive. The continuous availability ensured by AlwaysUp allows our clients to sync documents at any time, day or night, enhancing the overall solution we provide.
(888) 881-CORE
We’ve been deploying 
