The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation


AlwaysUp Feature Spotlight: Run your App Without Admin Rights

Run your App Without Admin Rights

Why should I run my application without admin rights?

A Windows Service typically runs in an account with extensive/elevated rights. In fact, most services run as LocalSystem — a built-in account with near total control of the computer.

But that power isn’t granted lightly. It’s actually given out of necessity.

The reality is that a service often requires broad access to your computer to tackle its complex tasks — like interrogating the network, terminating rogue processes or checking RAM levels. Unfortunately, working in a normal, non-admin context won’t cut it.

But even though it’s needed, there are serious risks when operating with so much latitude. That’s because awful things can happen if a fully-empowered service is compromised or becomes infected with malware!

Running applications without admin rights is safer

As reported by SoftPedia in 2015, almost all of the vulnerabilities detected in Windows could have been avoided by removing administrator rights from the programs involved:

Critical vulnerabilities involving admin rights

That is, running programs without administrator rights substantially reduces risk and makes your PC much safer to use.


How do I make AlwaysUp start my application with basic rights only?

It’s easy to make AlwaysUp launch your program with normal, unelevated rights. To do so:

  1. Edit your application in AlwaysUp (select Application > Edit/View from the menu.

  2. Move to the Logon tab.

  3. Check the Launch the application without admin rights box:

    Launch your app without admin rights
  4. Save your changes.

The next time your AlwaysUp service starts, it will launch your application with basic rights only.


What are your best tips for running my application without admin rights?

Tip #1: Test thoroughly

Are you sure that your application works properly without administrative rights? Unfortunately, not all applications do.

Be sure to test all functionality and confirm.

For example, can your application still read and write to the file system? Or will it fail because it cannot communicate with another program running in a different security context?

Tip #2: Examine your application’s security groups with Process Explorer

If you want to inspect your application’s permissions, you can open your app in Process Explorer and review the Security tab.

For example, here’s OneDrive running without admin rights. You can see that:

  1. The integrity level is Medium, indicating that the process isn’t elevated;

  2. The user has been denied access to well-known administrative groups, like “Administrators” and “Power Users”:

    OneDrive running without admin rights

Also, many of the low-level privileges are disabled.


Posted in AlwaysUp | Tagged , , , , | Leave a comment

Q&A: How do I make AlwaysUp run my Batch File as a Windows Service?

How do I make AlwaysUp run my Batch File as a Windows Service?
  We purchased AlwaysUp to run a batch file that runs a web front end for a database. But when we plug it in it doesn’t work. AlwaysUp tries to run the script but gives up after five tries.

The script contains a couple of commands:

cd "C:\Program Files\Simtec Viewer"
start /max simtecw.exe

Is there a way to get it to run constantly, as a service?

— Roy W.

Hi Roy, thanks purchasing AlwaysUp. We really appreciate your support!

Thanks also for including the batch file in your support request. Because of that, we were able to spot exactly what’s going wrong for you.

Let’s dig into the problem and highlight the solution.

The problem: The “start” command doesn’t wait for your application to finish

AlwaysUp has trouble because of how the batch file launches your executable — with the Windows start command.

Most importantly, the start command is non-blocking. That is, after it launches your application, it exits. It doesn’t wait for your application to complete its work and close.

With that understanding of the start command in place, here’s how things play out when you start your batch file entry in AlwaysUp:

  1. Your AlwaysUp Windows Service starts

  2. AlwaysUp launches your batch file

  3. The batch file executes

  4. The batch file runs the “cd” command, which changes the working directory to “C:\Program Files\Simtec Viewer”.

  5. The batch file runs “start /max simtecw.exe”

  6. The start command launches “simtecw.exe”

  7. The start command exits

  8. The batch file exits

  9. AlwaysUp detects that the batch file has exited

  10. AlwaysUp restarts the batch file (as configured on the Restart tab)

  11. Repeat the cycle, starting at step 3

After five attempts, AlwaysUp gives up at step 10 and shuts down the Windows Service. Your run ends in failure — all the time.

Fortunately the fix is very simple. You just need to add 6 characters to your script to make it work as desired with AlwaysUp. 🙂

The solution: Make the “start” command wait for your application to finish

The key is to get the start command to block while your main executable is running. That way the script won’t exit immediately and AlwaysUp won’t try to restart it again and again.

To get the start command to block, simply add the /wait parameter to the command line, like this:

start /max /wait simtecw.exe

And with that adjustment, a healthier pattern should unfold when you start the batch file in AlwaysUp:

  1. Your AlwaysUp Windows Service starts

  2. AlwaysUp launches your batch file

  3. The batch file executes

  4. The batch file runs the “cd” command runs which changes the working directory to “C:\Program Files\Simtec Viewer”.

  5. The batch file runs “start /max /wait simtecw.exe”

  6. The start command launches “simtecw.exe”

  7. The start command blocks waiting for “simtecw.exe” to exit

  8. “simtecw.exe” exits

  9. The start command exits

  10. The batch file exits

  11. AlwaysUp detects that the batch file has exited

  12. AlwaysUp restarts the batch file (as configured on the Restart tab)

  13. Go to step 3

The end result is that AlwaysUp will run your executable 24/7, quickly restarting it if it crashes or stops for any reason.

And you’ll be able to rest assured, knowing that AlwaysUp is on the case!

Posted in AlwaysUp | Tagged , , , | Leave a comment

AlwaysUp Feature Spotlight: Capture Console Output

AlwaysUp Feature Spotlight: Capture Console Output

What is the “capture console output” feature? Why would I use it?

When you run your application as a Windows Service with AlwaysUp, your app doesn’t come up on your desktop. Instead, your program runs invisibly in the background — on the isolated Session 0 desktop.

And even though running out of sight is fine for many situations, what if you need to see your application to make sure it’s working properly? That can be tricky — especially for Windows GUI programs.

However, there’s an easy workaround if you’re running a console application.

Simply instruct AlwaysUp to capture all the text that your application prints to the console and save that text to a file. Afterwards, you can read the file to see what your program printed.

For example, here’s the text that AlwaysUp saved when running Rclone as a service:

Rclone Output File

And capturing text helps our customers running Logstash in the background as well:

Logstash Output File

When to save console output to a text file

You should consider capturing your application’s console output whenever:

  • You’re running a text-based application, like a batch file — not a GUI program;

  • You must preserve all the messages your application reports;

  • Your application is failing and you’d like to know if it’s printing an error message;

  • You’re want to keep a close eye on your application, for example when troubleshooting a problem.


How do I capture console output in AlwaysUp?

The “capture output” feature is available on the Extras tab when configuring your application in AlwaysUp.

Simply enable the Capture output to this log file option and enter the full path to the file to record the text:

Capture console output from the Extras tab

Furthermore, if your application produces lots of text, you can check the Automatically box and determine what to do when the file gets large.


What are your best tips for capturing text?

Tip #1: Set a maximum size for the text file

The output file may be difficult to work with if it gets huge. To avoid that, you should specify a reasonable limit for the text file.

We recommend capping the file at 20 MB or less. That’s room for a lot of text!

Tip #2: Decide what to do if the file grows too large

If the file reaches its maximum size, AlwaysUp can either:

  • Trim the file, discarding the oldest 25% of the contents; or

  • Rollover the file, renaming it to include the current date and starting fresh with an empty file.

Be sure to choose the option that’s most appropriate for your situation. For example, you shouldn’t trim the file if you need to preserve all the entries written to the console.

Tip #3: Avoid locking the file while your application is running

An application that locks the output file will prevent AlwaysUp from adding new text to the file. If that happens, you may miss some of the data that your application has written to the console.


Posted in AlwaysUp | Tagged , , | Leave a comment

Essential Windows Services: Local Session Manager / LSM

Local Session Manager Service

What is the Local Session Manager (LSM) service?

The Local Session Manager is an important Windows Service that establishes a dedicated session/desktop whenever you log in to your computer. It’s involved however you sign on — to the physical console (with the keyboard and mouse) or through a remote connection technology, like RDP.

The service’s display name is Local Session Manager. It runs as LocalSystem inside the service host process, svchost.exe. By default, the service is set to start automatically at boot:

The Local Session Manager Windows Service

What happens if I stop Local Session Manager?

It’s not easy to stop the LSM service.

In fact, all the service’s operations are disabled and the action buttons are grayed out when you look at LSM in the built-in Services application:

All service operations are disabled

And the SC command confirms that the service won’t accept requests to stop:

You can't stop the LSM service

Microsoft has really locked-down the Local Session Manager!

But what about terminating the svchost.exe process behind LSM? Does that stop the service?

Surprisingly, yes.

How to stop the LSM service

First, we found the process identifier (PID) of LSM from the Services tab in Task Manager. It was 960 on our machine:

Find the LSM PID

Next, we switched to the Details tab and located the process with PID 960 in the list. From there, we right-clicked the row and chose End task from the menu.

After confirming that we really wanted to end the svchost process, Windows terminated PID 960:

Terminate the LSM process

And the LSM service stopped:

LSM service stopped

What happened after we stopped the LSM service

At first, there were no visible effects of stopping the Local Session Manager. We weren’t ejected from our RDP session and all our programs continued to operate normally. Everything was fine.

Yet, because of the tight security controls on the LSM service, we couldn’t restart it:

Unable to start the LSM service

In any case, everything was normal — until we decided to log off. When we signed out of our account, our RDP session hung with a black screen.

Afterwards, we simply couldn’t log in to our computer again. RDP connection windows appeared and quickly vanished without acknowledgement. And when we tried to log in directly on the console, Windows rejected us with a terse, unhelpful error message:

The RPC server is unavailable

We had to reboot our computer to restore access.

The behavior confirmed that:

  • LSM is critical in establishing a new login session, either via RDP or from the physical console;

  • However, once it’s established a session, LSM is not involved in the ongoing operation of that session.

So, in summary, if you stop the Local Session Manager service:

  1. Existing login sessions will be OK but no one else can log in to your computer.

  2. You may have trouble logging off your computer.

  3. You’ll have to reboot your computer to restart the service. Furthermore, holding down the power button (to kill the power to your PC) may be the only way to reboot.


Is it OK to disable the LSM service?

No — not if you want to sign on to your computer. As described above, you simply can’t log in when LSM isn’t running.

Indeed, Microsoft cautions against disabling Local Session Manager:

 Stopping or disabling this service will result in system instability.

You should heed that advice. It’s best to keep the LSM service enabled — and configured to start automatically at boot.


Questions? Problems?

If you would like to know more about the Local Session Manager service, or you have a specific problem, please feel free to get in touch. We will do our best to help you!

Posted in Windows Services | Tagged , , , , | Leave a comment

Q&A: Can AlwaysUp Close Dialog Boxes From My Application?

Can AlwaysUp Close Dialog Boxes From My Application?
  We’re running a VB application as a service with AlwaysUp. Everything seems to be working except for in one situation.

Can AlwaysUp detect when my program hangs with a dialog box waiting to press OK to continue? The application doesn’t work properly if the dialog stays open.

I found NirCmd, which can click buttons and send text to windows, but how do I use it with AlwaysUp?

— Rose

Hi Rose.

Unnecessary prompts are an enemy of 24/7 operation.

As you’ve seen, it can be very frustrating when a silly prompt holds up the action, waiting for you to click a button or hit the escape key!

Fortunately AlwaysUp can quickly dismiss those intrusive prompts on your behalf — even when you are not around.

Let’s dig into the details.


AlwaysUp automatically dismisses standard “application crashed” dialogs

When an application crashes, Windows may throw up a prompt to inform you of the problem. And you must acknowledge that prompt for the application to terminate.

But what happens if you’re not there to dismiss the crash dialog? Nothing good, unfortunately.

Until you dismiss the dialog, your application’s process will linger on in a “zombie” state — dead on its feet. You’ll see it in Task Manager but it will be completely unresponsive to network requests, file changes and any other operations that would normally trigger activity. And a lifeless program can cause problems for you and your team.

We built AlwaysUp to dismiss those dialogs on your behalf — quickly and automatically. To illustrate, here are three of the prompts that AlwaysUp handles.

Microsoft Visual C++ Runtime Library dialogs

Microsoft Visual C++ Runtime Library dialog

Windows shows the “Microsoft Visual C++ Runtime Library” dialog when your application causes a problem for the Visual C++ components.

AlwaysUp will automatically click the “OK” button for you.

Visual Basic run-time dialogs

Visual Basic run-time dialog

A Visual Basic application throws up this window when it runs into trouble.

AlwaysUp will automatically click the “End” button to exit the application.

Windows Error Reporting (Werfault.exe) dialogs

Windows Error Reporting (Werfault.exe) dialog

Windows Error Reporting shouts when your program crashes.

AlwaysUp will automatically click the “Aceptar” (OK) button to close the window for you.

So AlwaysUp covers the standard Windows dialogs. But what about application-specific prompts? We’ll deal with those in the next section.


Plug in an automation to complete fields and click buttons in any dialog box

While it can handle the standard dialogs, AlwaysUp needs your help to dismiss application-specific dialogs. Indeed, without your guidance, AlwaysUp has no idea what to do when faced with an arbitrary prompt from your program!

For example, suppose you’re running iTunes as a service and it starts by showing this prompt:

iTunes dialog

You must click the OK button to dismiss the window so that iTunes can proceed.

But when you start iTunes as a Windows Service with AlwaysUp, it runs in the background on an invisible desktop. Because of that, you won’t be able to see or click the OK button and iTunes will hang — indefinitely.

To overcome that problem, you’ll have to:

  1. Create a Windows automation that clicks the OK button on the iTunes dialog;

  2. Instruct AlwaysUp to run that automation periodically.

Creating an automation to dismiss a dialog with AutoIt

We recommend using AutoIt to create your automation. It’s popular, powerful and straightforward. For example, the AutoIt script to dismiss the iTunes dialog contains a single line of code:

; Sends the ESC key to dismiss any iTunes prompt.
ControlSend("iTunes", "", "", "{ESC}")

You can find more about using AutoIt with AlwaysUp here.

But you don’t have to use AutoIt. You can choose any automation utility you like. And NirCmd is a fine choice.

Creating an automation to dismiss a dialog with NirCmd

You use NirCmd to dismiss a dialog like this:

nircmd dlg [Process Name] [Window Title] [Action] [Parameters]

where:

Process Name: Specifies the process that created the desired window. You can specify only the process name or the full path of the process. If this parameter is empty string (""), the command will be executed on any process.

Window Title: Specifies the title of the window that you want to execute the action. If this parameter is empty string (""), the command will be executed on any window, regardless the window title.

Action: You can specify one of the following options:

  • click: Click the specified button. You can specify one of the following predefined values (For standard Windows dialog-boxes only!): yes, no, ok, cancel, retry, ignore, close, help. You can also specify any control ID as a numeric value.
  • settext: Set the text of the specified control. The first parameter of this action specifies the ID of the control, and the second parameter specifies the text.

For example, NirCmd will dismiss our iTunes dialog with the following command:

nircmd dlg "itunes.exe" "iTunes" click ok

Have AlwaysUp run your automation

And once you’ve created an automation that dismisses your dialog, you can plug it into AlwaysUp in a few steps:

  1. Save your automation in an executable or batch file.

    For AutoIt, you can use the AutoIt Script to EXE Converter to create an executable from your script:

    Convert your AutoIt script to an executable

    And for NirCmd, simply save your command to a batch file:

    NirCmd batch file

    Be sure to specify the full path to the NirCmd executable file in your batch file.

  2. Next, start AlwaysUp.

  3. Edit your application and switch to the Automate tab.

  4. Check the box at the top to enable automation. Afterwards, enter the full path to your automation executable or batch file.

  5. And finally, indicate how often you want your automation to run. For iTunes, we’d like to dismiss prompts every minute:

    Install your NirCmd automation batch file
  6. Save your changes.


And that’s it. With your NirCmd (or AutoIt) automation plugged into AlwaysUp, your dialogs will be automatically dismissed — without you having to do anything at all.

Enjoy!

Posted in AlwaysUp | Tagged , , , , , | Leave a comment