The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation

Q&A: Why can’t AlwaysUp run my Batch File?

Posted on August 15, 2022

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):

And please be sure to get in touch if you have any other questions.

Best of luck with your project!

How to Restart a Windows Service Every Day (or Week)

Posted on August 6, 2022

The easiest way to restart your Windows Service is with our Service Scheduler tool.

It’s completely free, super simple to use and you can schedule your service in less than a minute.

For example, here’s how to restart the Windows Time service every day at midnight:

Download Service Scheduler. Save the executable file on your desktop, or to a well-known folder on your computer.
Double-click the ServiceScheduler.exe file to launch the program. If necessary, confirm the standard User Account Control (UAC) security prompt.
Choose Service Task > New from the menu (or click the button):
In the Add Service Task window:
1. Choose Restart
2. From the list of services, select Windows Time (W32Time)
3. Choose Every and Day
4. And finally, set 12:00 AM in the time control:
Click the Save button. A new entry to restart the Windows Time service will appear in the list:
And that’s it! Going forward, the Windows Time service will restart every day at midnight.
Note that it’s just as easy to set up a weekly or monthly restart. Simply choose the appropriate day when configuring your service:

Enjoy!

Q&A: How do I Eliminate Errors from my C# Console App Windows Service?

Posted on July 18, 2022

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:

Activity report: Unable to restart the application

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.

Best of luck with your C# console application!

Essential Windows Services: Security Center / wscsvc

Posted on July 4, 2022

In this article…

What is the Security Center (wscsvc) service?
Technical information
What happens if I stop Security Center?
Is it OK to disable the Security Center service?
Questions? Problems?

What is the Security Center (wscsvc) service?

The Security Center service is an important “watchdog” focused on protecting your computer.

From the service’s description:

The Security Center service monitors and reports security health settings on the computer.

Those health settings include:

Firewall (on/off)
Antivirus (on/off/out of date)
Antispyware (on/off/out of date)
Windows Update (automatically/manually download and install updates)
User Account Control (on/off)
Internet settings (recommended/not recommended)

In summary, Security Center’s purpose is to let you know when your computer’s defenses are down.

To illustrate how the service works, we turned off the Windows Firewall (which protects your PC from outside attackers). A couple of seconds later, Security Center raised a warning on our desktop, urging us to re-enable the firewall:

Technical information

The service’s name is wscsvc. It runs inside the shared services host process, svchost.exe:

The service’s startup type is Automatic (Delayed Start). As a result, Windows launches the service a couple of minutes after your machine boots.

wscsvc runs in the built-in Local Service account:

What happens if I stop Security Center?

Since Security Center safeguards your machine, stopping the service may leave you in the dark about your computer’s defenses. For that reason, Microsoft has made it very difficult for you to stop the Security Center service.

In fact, not even members of the powerful Administrators group can stop (or change) the service! If you open the Services application, you will notice that all the command buttons are disabled:

Security Center: Administrator permissions

In our research, we identified only three obscure, built-in Windows accounts that have enough rights to stop Security Center. Those accounts are DcomLaunch, SecurityHealthService and TrustedInstaller:

Clearly, Microsoft has taken great pains to “lock down” the Security Center service. Best to heed their advice; do not try to stop it.

Is it OK to disable the Security Center service?

Again, because of tight security settings, you will not be able to disable the service from the Services application. And the SC command won’t work either:

However, if you are hell bent on hobbling the service, you can try hacking the registry. Setting the Start value in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wscsvc key to 4 should do the trick. You may have to reboot afterwards.

But don’t be surprised if that fails too. For example, Windows 11 restricts access to the registry key to a few built-in accounts. Not even an administrator can update the registry entry. And as you can see, Windows rebuffed our attempt to change the registry value:

Caveat emptor!

Questions? Problems?

If you would like to know more about the Security Center service — or if you have a specific problem with it — please feel free to get in touch. We will do our best to help you!

Q&A: Why does AlwaysUp Fail to Run my Program?

Posted on June 21, 2022

I set up our application with AlwaysUp but it doesn’t work. When I try to start it, it runs for a few seconds then fails with this error:

AlwaysUpService was unable to start the application properly, failing at least 5 times in 1 minute. AlwaysUpService will now stop.

How do I fix this?

— Mark

Hi Mark.

AlwaysUp can fail to run your application for a variety of reasons. Here are the most common.

Reason #1: Your application cannot run in the account specified on the Logon tab

By default, Windows Services run in the LocalSystem account — a special, predefined account created and managed by Windows itself.

LocalSystem is a fine choice for the builtin Windows Services. That’s because it exists on every computer, doesn’t require a password, and is powerful enough to perform a wide range of administrative tasks.

Consequently, when you setup your application with AlwaysUp, the default is to run in the LocalSystem account. You can see that position on the Logon tab, where the box to override using LocalSystem is not checked:

But for many applications, running in the LocalSystem account will not work. This is particularly true for regular, desktop applications that are designed to operate in the account where they were installed.

For example, let’s review a scenario with Dropbox, the popular cloud storage program.

You’ve installed Dropbox on your PC. You’ve also configured it to synchronize your important folders with the cloud. Everything works well and Dropbox copies your files as expected. Happy day!

Later that week, a co-worker logs on to your PC. They open File Explorer, browse to the Dropbox folder and double-click Dropbox.exe (the executable that runs Dropbox). Dropbox starts, but it comes up “blank”. The files and folders you have configured are nowhere to be seen!

No, Dropbox isn’t broken. On the contrary, it’s working exactly as designed.

You see, when you installed and set up Dropbox, the program saved your configuration in a section of the Windows Registry that only your account can access. And when your co-worker logged on and started Dropbox, they did not see any of your settings because they don’t have access to your private area in the registry where Dropbox stored your settings.

Well, the same is true of the LocalSystem account. It cannot access your Dropbox private settings either. So if you start Dropbox in the LocalSystem account, Dropbox will come up “blank” as well.

In essence, the account where you run your application as a Windows Service can have an enormous impact.

Solution

The remedy is simple. Run your application in a Windows account where you know it works.

In fact, if your application runs fine on your desktop right now, you should use your current account.

To specify your account in AlwaysUp:

Start AlwaysUp
Double-click your application to open the Edit/View Application window
Switch to the Logon tab
Check the Instead of running the application… box at the top
Enter your user name and password:
Don’t know the user name of your current? Run whoami at a command prompt to find out.
Save your settings

Hopefully your application will behave better now that you’re running it in the correct account.

However, if you’re still having problems, try starting your application in the current session which will make it visible on your desktop. Select Start in this session from the Application menu to try:

And now that you can see your application, watch out for warnings and errors that are holding up the action.

Reason #2: Your application has a problem unrelated to AlwaysUp

An application that fails to start with AlwaysUp often fails to start without AlwaysUp as well!

For example, that your application can fail to start because:

It was never installed and configured properly in your account
A recent update (or a Windows patch) broke the software
It’s encountering an error that prevents it from working

Solution

Put AlwaysUp aside and launch your application normally on your desktop.

Does it start? Do you see any errors?

How about in the application’s logs? If your application writes to a log file, be sure to check the file for telltale warnings and errors.

If you find a problem, you must fix it before re-engaging AlwaysUp.

As you can imagine, if your application doesn’t run properly by itself, it won’t magically work as a Windows Service with AlwaysUp either!

Reason #3: Your program starts and completes rapidly

When you run your application normally on your desktop, how long does it take to complete?

If it only runs for a few seconds, AlwaysUp may be misinterpreting the quick exit as a failure to start at all!

We saw this scenario most recently with a customer running a Python script with AlwaysUp. The script would check a folder for new files and close within 1 second if no files were found. And when it exited, AlwaysUp would log an error saying that the script failed to start properly and try to restart it again. The end result was to give up after 5 attempts, just as you reported.

Solution

One quick fix is to ensure that your application takes a bit longer to run. For example, if you’re running a batch file, you can add a TIMEOUT statement right before your script exits.

Similarly, you can delay your C++, C# or VB application by calling Sleep (or an equivalent) to introduce a delay prior to a speedy exit.

However, if you cannot modify your application, you can modify how AlwaysUp works. By creating an empty file named alwaysup-dont-panic-on-quick-exit.txt in your AlwaysUp installation directory (by default, C:\Program Files (x86)\AlwaysUp), you will signal AlwaysUp not to treat a quick exit as a failure.

Hopefully one of these solutions addresses your problem. Please be sure to get in touch again if not!

The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation

Q&A: Why can’t AlwaysUp run my Batch File?

What’s the batch file doing?

AlwaysUp runs your batch file properly

Session 0 Isolation prevents you from seeing the popup window

You may also like...

How to Restart a Windows Service Every Day (or Week)

You may also like...

Q&A: How do I Eliminate Errors from my C# Console App Windows Service?

Tweak #1: Minimize the logging around expected starts & stops

Tweak #2: Make AlwaysUp tolerate “quick exits”

You may also like...

Essential Windows Services: Security Center / wscsvc

What is the Security Center (wscsvc) service?

Technical information

What happens if I stop Security Center?

Is it OK to disable the Security Center service?

Questions? Problems?

You may also like...

Q&A: Why does AlwaysUp Fail to Run my Program?

Reason #1: Your application cannot run in the account specified on the Logon tab

Solution

Reason #2: Your application has a problem unrelated to AlwaysUp

Solution

Reason #3: Your program starts and completes rapidly

Solution

You may also like...

Products

Topics/Tags

Categories

Archives

Search This Blog