I’m hoping you can help me troubleshoot some issues we are experiencing with AlwaysUp. We are currently using version 12.9.0.46.
A user reported that something wasn’t working correctly with the application we’re running as a service. Upon investigating the issue, I noticed that AlwaysUp doesn’t appear to be writing any logs to the event viewer as stated on this page.
I thought I was maybe just missing any messages, so I stopped and restarted the service after about 1 minute. However, this also didn’t write anything to the Application Logs in Event Viewer.
Could you assist me in sorting out the reporting please?
— Lewis
Hi Lewis. Let’s dig into your situation.
Which account runs your application as a Windows Service?
Do you have a user specified on the Logon tab in AlwaysUp? That’s the account where your application will run.
For example, this screenshot shows OneDrive configured to run as a service in the “Mike Jones” account:
When we start OneDrive in AlwaysUp, the executable runs as “Mike Jones”:
And as Process Explorer shows, even AlwaysUpService.exe — the headless application that runs your application as a service in the background — operates as the same user:
Note that most Windows Services run in the LocalSystem account — a predefined local account used by the Service Control Manager. Indeed, AlwaysUp will run your application as LocalSystem unless you override it by providing an alternate account.
But running in a “regular” user account is often the best choice when installing an application as a service. That’s because most desktop applications are tied to the account where they were installed. Starting them in an account where they were not installed (and cannot find settings saved during installation and configuration) usually ends in failure.
That account must have permission to create event logs
As illustrated above, the service that AlwaysUp creates runs entirely in the context of the account specified on the Logon tab.
In your set up, the account doesn’t appear to have the necessary permissions to write to the event logs. That’s why you’re not seeing any records from AlwaysUp.
Test the account’s event log permissions with PowerShell
You can test this theory by running the following PowerShell command from the user’s account:
Write-EventLog -LogName Application -Source "APPNAME (managed by AlwaysUpService)" -EntryType Information -EventID 0 -Message "This event was created while testing with PowerShell. Please ignore."
Please replace APPNAME with the name of your application in AlwaysUp.
Essentially, the Write-EventLog command simulates how AlwaysUp works. If Write-EventLog fails, then AlwaysUp will fail too.
Here is the result of running the command from the “Mike Jones” account for our OneDrive service. Write-EventLog succeeded:
And a new event showed up in the Application log:
So everything looked good for Mike.
How to enable event logging from your AlwaysUp service
You can fix the permission problem in one of three ways:
Grant the user administrative rights. As an admin, they will definitely be able to write to the event logs. This may be your easiest way forward.
Leave the user as a non-admin but grant the account specific rights to the Application event log. Depending on where the issue is, you may have to update the registry and perform other administrative surgery. These links offer guidance:
Enter a different user with administrative rights on the AlwaysUp Logon tab. That account shouldn’t have any problems creating records in any event logs.
Start Services. Click the Start button, type services.msc in the search field and hit return.
From the Action menu, select Export List:
Choose the format (tab delimited text or CSV), enter a file name and click Save to create the file.
Your file will contain the following five columns of data, which you cannot customize:
Name (Note: This is the service’s display name, not its unique name used by Windows)
Description
Status
Startup Type
Log On As
If that’s all you need then you’re good to go!
2. Export to CSV or XML with PowerShell
Even though it’s easy to do, exporting with the Services application may not provide all the information you would like to capture. For example, the service name is not included and neither is the command line used to start the service.
If you’d like more columns, then PowerShell is another option.
For example, this command lists all the services on your machine:
Note that you can add or remove properties from the Select-Object section as you see fit. Feel free to include any property listed in the Win32_Service class documentation.
And once you’ve settled on a command that prints the necessary information, call the Export-CSV module at the end to send the results to a file.
For example, this command exports the list of services to “C:\output-file.csv”:
We created Windows Service Auditor to help protect against changes to your important Windows Services but it has the ability to export the list of services to an XML file as well.
After downloading and starting Windows Service Auditor, simply select Export (XML} from the All Services menu to create the XML file:
The XML will be very detailed, with all aspects of your Windows Services recorded. Here is an example:
Because its output is so detailed, Windows Service Auditor is your best option if your goal is to take a snapshot of your services and all their settings.
Hopefully one of these three methods works for you!
Hi. I think I’ve written a batch file that your AlwaysUp software cannot run as a service.
Here are the contents of my file:
@echo off > usermessage.vbs ECHO Set wshShell = CreateObject( “WScript.Shell” ) >>usermessage.vbs ECHO wshShell.Popup “My Text line 1” ^& vbCrLf ^& _ >>usermessage.vbs ECHO “My Text line 2” ^& vbCrLf ^& _ >>usermessage.vbs ECHO “My Text line 3” ^& vbCrLf ^& _ >>usermessage.vbs ECHO “My Text line 4” ^& vbCrLf ^& _ >>usermessage.vbs ECHO “My Text line 5” ^& vbCrLf ^& _ >>usermessage.vbs ECHO “My Text line 6” ^& vbCrLf ^& _ >>usermessage.vbs ECHO “My Text line 7” ^& vbCrLf ^& _ >>usermessage.vbs ECHO “My Text line 8” ^& vbCrLf ^& _ >>usermessage.vbs ECHO “My Text line 9”, 120, _ >>usermessage.vbs ECHO “My Window Title”, 64 WSCRIPT.EXE usermessage.vbs DEL usermessage.vbs
I searched the internet for hours using various terms and finally found a suggestion that your software would solve my problem.
It runs perfectly if I just click on it. But I could not make it run as a service. I’m not a pro at this.
Any Ideas?
— John
Hi John. Thanks for trying AlwaysUp and for getting in touch.
What’s the batch file doing?
We’re not VBScript experts so it took us a while to understand what your batch file is doing!
However, it soon became clear that the batch file:
Constructs a VBScript file named usermessage.vbs on the fly.
Adds a line to usermessage.vbs to create a Windows Script shell object.
Adds lines to usermessage.vbs that call the Popup function with several lines of text.
Runs usermessage.vbs, which shows a popup window with the specified text. The popup will stay on screen for up to 120 seconds, or until the user clicks the OK button.
Deletes the usermessage.vbs file.
In summary, the purpose of the batch file is to show this message box for up to 2 minutes:
It seems a bit contrived, but perhaps this code is a sample you created for testing? No doubt your “real” code is more practical and exciting. 🙂
AlwaysUp runs your batch file properly
AlwaysUp launches the batch file as a Windows Service just fine. And it has no problem running the dynamically created VBScript file either. We’re lucky to have hundreds of customers using AlwaysUp to launch their batch files, every day.
Indeed, we were able to setup your batch file in AlwaysUp and confirm that it runs as expected. Process Explorer showed AlwaysUp running the batch file, which launched the Windows Script Host executable (wscript.exe) to display the popup window. You can see this arrangement in the tree of processes on the left:
All good, right? Well, not entirely…
Session 0 Isolation prevents you from seeing the popup window
Even though your script is running, you will not be able to see the popup window on your desktop. That is because of Session 0 Isolation — an important security measure that constrains Windows Services.
You won’t see the popup because:
your batch file is running in Session 0, on the special background desktop where all Windows Services operate, and
Windows isolates applications running in Session 0, meaning that they cannot show up alongside the other windows on your screen.
Once upon a time, you were be able to switch to Session 0 to see the popup but no longer. Unfortunately, Microsoft removed that capability a few years ago. As a result, there is no way to see a window displayed in Session 0.
So in summary, your batch file will not pop up a window on your interactive desktop when you run it as a Windows Service. And that’s true even if you don’t use AlwaysUp because the restriction is built into Windows itself.
I hope this makes sense. Unfortunately, Session 0 Isolation can be tricky to comprehend. Please check out these FAQ entries if you want to dig into the details (caveat emptor):
For a few years now, our company has been using AlwaysUp to run an internally developed C# console application as a service. The application checks a folder for incoming files and processes anything it finds. It runs every 30 seconds.
The application itself works fine. New files are discovered quickly and we have a system that works reliably 24/7.
The only problem is that we’re seeing hundreds of errors in the activity report:
Have you ever had this reported before? Can you recommend some ways to help us avoid the errors?
— Clayton
Hi Clayton. Thanks for supporting our software!
By default, AlwaysUp’s mission is to run your application 24/7 — with no interruptions.
However, your program runs periodically. That’s perfectly fine, but you should make a couple of tweaks to have AlwaysUp tolerate the frequent stops and starts.
Tweak #1: Minimize the logging around expected starts & stops
First, understand that AlwaysUp is a chatty babysitter. 🙂
Whenever the application it’s watching starts or stops, AlwaysUp writes an informative entry to the Windows Event Log.
For example, you will see one of these messages when AlwaysUp starts (or restarts) your C# program:
The application has been started
The application has been restarted (run #number)
And AlwaysUp writes similar entries when the application crashes or stops for any reason.
For customers running applications continuously — like Dropbox, OneDrive or VirtualBox — those messages are helpful. They highlight the rare occasions where the application runs into trouble and needs attention.
But your scenario is different. AlwaysUp launches your application every 30 seconds. As a result, AlwaysUp will inundate your activity log with useless messages.
Fortunately, our team has already designed an easy way to eliminate the spurious log entries. Please:
Edit your application in AlwaysUp
Move to the Restart tab
Check the Minimize event logging as the application starts & stops box:
Save your changes.
That adjustment will prevent AlwaysUp from filling up your event logs. Restart your C# application and you will notice that the activity report is much less verbose.
Tweak #2: Make AlwaysUp tolerate “quick exits”
From the detailed logs you sent, each of the three runs completed in less than 1 second. That’s very fast, and the quick turnaround confuses AlwaysUp.
In fact, because your C# application does its work and exits so quickly, AlwaysUp thinks that your application failed to start at all!
And with that conclusion, AlwaysUp immediately runs your program again.
The result is the cycle you see in your logs — the repeated, rapid fire running of your console application.
The solution to the problem is to tell AlwaysUp to not to panic if your application completes quickly. To do so:
Create an empty file called alwaysup-dont-panic-on-quick-exit.txt in your AlwaysUp installation directory (likely C:\Program Files (x86)\AlwaysUp):
Restart your application in AlwaysUp.
The presence of that “magic” file signals AlwaysUp to tolerate your application’s speedy exit and avoids the unnecessary restarts.
(888) 881-CORE
Hello,
For a few years now, our company has been using AlwaysUp to run an internally developed 
