We have installed AlwaysUp in a number of our Windows servers, and it works great.
We have a specific application that outputs debugging messages that are usually visible in the Windows Debug console view via the Sysinternals DebugView or DebugView++ desktop applications.
When we start the same application from AlwaysUp, I don’t see the debug messages in the DebugView console. Do you know where they go?
— Giovanni
Hi Giovanni, thanks for getting in touch.
We’ve seen this problem before. To explain in a sentence, you’re not seeing your applications debug messages because AlwaysUp is running your application in Session 0 while DebugView is monitoring your logon session.
But that’s a mouthful! Let’s try to explain what it means. 🙂
Windows Sessions, in a nutshell
To understand what’s going on, it’s important to be aware of Windows sessions and how they work. In case you could use a refresher on this very technical topic, here are a few facts about sessions:
When you log in to your computer, Windows creates a new session for you. That session stays open until you log out — or Windows restarts. You can think of a session as the “container” for your entire login experience.
A session holds your desktop and all the programs you launch. Indeed, every application you start runs in your session.
By design, Windows allows programs running in the same session to communicate freely. However, because of security restrictions, applications running in different sessions cannot easily interact.
For example, an application running in your session cannot use the popular EnumWindows API function to list the top-level windows in someone else’s session. Windows simply disallows that overreach.
Sessions are numbered. The first person to log in to the computer is given Session 1 (“the session with ID 1”). The next person to log in is assigned Session 2, and so on.
When your computer boots, Windows automatically creates a special session, called Session 0. All Windows Services — which may start at boot before anyone logs on — run in Session 0.
Session 0 is sometimes called the “console” or “background” session because of the special role it plays.
And with that framework in place, let’s return to your specific situation.
DebugView and your application are running in different Windows sessions
When you logged into your PC — either using the keyboard and mouse or remotely via RDP — Windows created a new session for you. Let’s say it’s Session 1 (but it could just as well be Session 2 or 3 if you weren’t the first person to log in after boot).
So when you start DebugView on your desktop, Windows launches it in Session 1. DebugView comes up visibly on your desktop, like any other application you start.
Similarly, when you start your application normally (without AlwaysUp), it will likely pop up on-screen as well. And DebugView will log its debugging messages, as expected.
But the situation is different when AlwaysUp runs your application. Instead of starting it visibly on your desktop, in Session 1, AlwaysUp starts your application in Session 0 — the session created at boot. Recall that’s where all Windows Services operate.
In that situation, DebugView will not capture messages from your application. That’s because DebugView is only monitoring applications running in Session 1 — the same session where it’s running.
The solution: Configure DebugView to capture messages from Session 0
Fortunately there’s a simple fix:
Start DebugView.
Select the Capture menu and ensure that Capture Global Win32 is checked:
With that option active, DebugView will capture messages from all Windows sessions — not only the session where it’s running.
If you run DebugView in a remote logon session of Windows 2000 Terminal Services, DebugView adds a Capture Global Win32 menu item to the Capture menu. Whereas the Capture Win32 menu item and associated toolbar button enable and disable capture of debug output in DebugView’s local logon session, the Capture Global Win32 menu item lets you enable and disable the capture of debug output that is generated in the console (global) session. Win32 services run in the console session, so this feature lets you capture the output that services generate even when you are running DebugView in another logon session.
You can capture debug messages from all sessions with DebugView++ too
DebugView++ provides a similar Capture Global Win32 option, which is on by default. It’s available under the Log menu:
So you’re free to use either tool when running your application as a Windows Service with AlwaysUp.
If you’d like to start, stop or restart a Windows Service on a schedule, do yourself a favor and check out our free Service Scheduler utility. You’ll be up and running in no time!
Version 3 of our easy-to-use program — which was released on November 4 — allows you to temporarily disable your tasks (so that they don’t run) and includes additional helpful enhancements to control your services. The release notes documents all the changes in this new version but we’ll review the top three highlights for you here.
#1: Easily disable your Windows Service tasks
Service Scheduler now supports disabling your service tasks. And that may come in handy during maintenance or at other times when your services shouldn’t run.
For example, suppose you’ve set up a task to restart the Print Spooler service every morning at 8 AM. That’s a good idea, to ensure that your printing systems are refreshed and ready for a full day of work.
But what happens if you decide to take the spooler down for a day to perform necessary upgrades? If you don’t do anything, Service Scheduler will still try to start the service at 8 — which might cause problems.
With previous versions of Service Scheduler, the only way to avoid the errant restart would be to remove the service task. And once the maintenance was complete, you’d have to set it up all over again. Even though that’s not difficult to do, it’s not the most efficient solution.
By supporting the ability to disable and later enable your tasks, Service Scheduler version 3 offers a much better approach. In the spooler scenario above, you’d simply disable the task at the start of your maintenance window and re-enable it afterwards.
You can quickly disable a task from the menu. Simply highlight the entry and choose Disable from the Service Task menu:
Once disabled, the entry will be displayed in an italics font — to indicate its inactivity:
In this state, your service operation won’t be triggered and the task will remain dormant. Indeed, you’ll notice that the “Next” column is empty because no runs are planned.
When you’re ready to reactivate the task, choose Service Task > Enable:
Afterwards, your task will be queued to run at the given time (which you will see in the “Next” column):
Note that you can also enable or disable your task when editing it:
As you’ve seen, the new feature is very easy to use.
#2: Hide the header
One of our colleagues relies on Service Scheduler to trigger over 50 service operations. She can barely fit the rows on screen!
To make life a bit easier for her, we added the option to remove the header above the list of service tasks. To do so, simply select un-check the View > Header menu item:
Afterwards, you’ll have more screen space to devote to your service task rows:
#3: Run worry-free on Windows Server 2025
Finally, we’ve made sure that Service Scheduler runs flawlessly on preview releases of Windows Server 2025. You shouldn’t have any trouble when Microsoft releases their new operating system later this year (or early next year).
I do not recall seeing a way to configure AlwaysUp to run a batch file once a day and not bother about trying to keep the batch file always running.
Did I miss a configuration setting that lets me run a batch file once a day and not restart it when it finishes, until the next scheduled time?
— RF
Hi RF, thanks for getting in touch.
Yes — AlwaysUp can definitely help you run your batch file reliably each day. Here’s how to put that in place.
Step 1: Install your batch file as a 24/7 Windows Service with AlwaysUp
The first thing to do it to install your batch file in AlwaysUp. Our easy to use Application Advisor will help you get you set up in a few minutes.
Please:
In AlwaysUp, click the “magic wand” icon () on the toolbar to launch the Application Advisor.
Advance past the welcome page, choose Batch file from the list of applications, and click Next to proceed:
Enter the full path to your batch file:
Next, enter the password for your Windows account:
Step through the rest of the process and click the Save button to add your batch file to AlwaysUp.
At this point, you have installed a batch file that AlwaysUp will run 24/7 — automatically restarting it if it ever stops for any reason. But that’s not what you want, right? Not to worry — we’ll address that overzealousness in the next step.
Step 2: Adjust your batch file to run once per day, at a set time
AlwaysUp features basic (but convenient) scheduling that allows customers to run programs periodically. You can find the relevant controls on the Restart tab when configuring your application.
To run your batch file once daily — say, at 7 AM, before you get into the office:
Edit your application in AlwaysUp (by selecting Edit/View Application from the Application menu).
Switch to the Restart tab.
Select the Not immediately, but option, select At and enter the time to run your batch file (7 AM):
Save your settings.
Going forward, AlwaysUp will now launch your batch file at 7 every morning.
One more consideration: Should your batch file run immediately when your AlwaysUp service starts?
If your goal is to run your batch file only at 7 AM, we actually have a bit more work to do. Let me explain.
As you probably know, AlwaysUp installed a Windows Service to manage your batch file. That service is will ensure that your batch file runs every morning at 7. But there’s one more time when the service will run your batch file: when the service starts.
For example, let’s say that your server reboots at 4:30 AM. Here’s what would happen:
4:31 AM: Windows starts your AlwaysUp batch file Windows Service.
4:31 AM: The AlwaysUp service starts your batch file.
4:36 AM: Your batch file exits (it ran for 5 minutes).
4:36 AM: The AlwaysUp service notices that your batch file has exited. It queues up the next run for today at 7 AM.
7:00 AM: The AlwaysUp service starts your batch file.
7:05 AM: Your batch file exits (it ran for 5 minutes).
7:05 AM: The AlwaysUp service notices that your batch file has exited. It queues up the next run for tomorrow at 7 AM.
So the question for you is: Is it OK for AlwaysUp to run your batch file when the service starts? Those extra, unscheduled runs can happen at any time — not only at 7 AM.
How to avoid unscheduled runs when the AlwaysUp service starts
If those additional, irregular invocations are unacceptable, then you must make one more change.
Edit your entry in AlwaysUp, return to the Restart tab and check the This delay applies to the first run as well box:
With that change in place, here’s what would happen at our hypothetical reboot at 4:30 AM:
4:31 AM: Windows starts your AlwaysUp batch file Windows Service.
4:31 AM: The AlwaysUp service schedules your batch file to run at 7 AM.
7:00 AM: The AlwaysUp service starts your batch file.
7:05 AM: Your batch file exits (it ran for 5 minutes).
7:05 AM: The AlwaysUp service notices that your batch file has exited. It queues up the next run for tomorrow at 7 AM.
As you can see, the extra run at 4:31 AM wouldn’t happen.
After months of coding and testing, our team published AlwaysUp version 15.5 on October 4, 2024.
Version 15.5 makes it easy to install your PowerShell scripts as services. Beyond that, it delivers timely fixes and improvements to address real-world issues faced by our customers. Indeed, this work is all part of our ongoing commitment to making sure that AlwaysUp runs your applications so smoothly that you forget it’s even there. 🙂
Let’s dig into the details.
Install your PowerShell script as a Windows Service, with ease
We’re pleased to announce that the easy-to-use Application Advisor now supports PowerShell scripts!
To use this new feature, start the Application Advisor (by selecting Application > Advisor from the menu) and choosing PowerShell from the list of applications:
Afterwards, AlwaysUp will ask you to pinpoint the PowerShell script you’d like to run as a service:
Click Next and follow the straightforward prompts to complete the process. In a few seconds, you’ll have a new Windows Service that starts your PowerShell script at boot and runs it continuously in the background.
When installing OneDrive with the Application Advisor, we no longer recommend stopping OneDrive by running the executable with the “/shutdown” flag. It turns out that running that command could lead to an ill-timed (and lengthy) automatic update — just when you want the program to quit quickly.
So with that understanding, it’s best for AlwaysUp to close OneDrive by sending it the standard WM_CLOSE message — as it does for other applications. If you have an existing OneDrive configuration that uses the custom stop command (“OneDrive.exe /shutdown”), please feel free to remove it.
Even though it’s running in the background and you can’t see it, OneDrive may occasionally try to get your attention. And when that happens, OneDrive will probably be stuck, not synchronizing your files.
AlwaysUp 15.5 will try to inform you whenever OneDrive is waiting for your input. For example, if OneDrive forgets your credentials and would like you to sign in again, you may see this message in the activity window:
We’ll continue to improve this kind of detection in future releases — and automatically take action whenever it makes sense.
Other fixes & improvements
AlwaysUp now launches the sanity check on the interactive desktop, to satisfy programs like cscript that won’t run on a non-interactive desktop.
AlwaysUp will wait a bit longer (45 seconds instead of 30) when stopping a Windows Service. This may be impactful if you have a service that takes a while to stop.
The application diagnostics that AlwaysUp collects now includes domain and role information. Those extra details will help us identify and troubleshoot account-related problems.
As usual, please review the release notes for the full list of features, fixes and improvements included in AlwaysUp version 14.5.
Upgrading to AlwaysUp 15.5
If you purchased AlwaysUp version 14 (after November 2022), you can upgrade to version 15.5 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 13 or earlier (before November 2022), you will need to upgrade to use version 15.5. Consequently, please purchase upgrades here — at a 50% discount.
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!
(888) 881-CORE
We have installed AlwaysUp in a number of our Windows servers, and it works great.
