The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation

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]


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.


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

Q&A: My Google Drive keeps Disappearing. Help!

  Hi, Core Technologies support team.

AlwaysUp has been invaluable to our business, which is why I’ve bought several copies for different machines.

Recently I started running into a problem on my production PC. I searched for a bit through your FAQs and blogs but didn’t see this particular problem. Maybe you have a quick workaround?

I’ve set up Google Drive for desktop to run as a service. An application on that production PC depends on the G: drive being present.

But sometimes the G: drive disappears after a while, even though AlwaysUp shows Google Drive running.

When that happens, my application goes haywire. Eventually, I’ll have to debug to keep the app from crashing when the G drive is not available, but in the meantime, do you have an answer for what’s happening?

I will appreciate any help you can provide.

— Randy

Hi Randy, thanks for reaching out to report the problem. No one on our team has seen Google Drive failing as you described so we can’t say precisely what going on, sorry.

But we can offer a couple of solutions that should (1) lessen the occurrence of the problem and (2) quickly restore functionality when the problem arises.

Solution #1: Have AlwaysUp restart Google Drive every night

If Drive breaks after it’s been running for some time, the program may have a resource leak.

Perhaps Drive isn’t freeing all the RAM it’s requested. Or it may be holding on to a network port for too long. Or it could be something else. It’s difficult to pinpoint the issue because we don’t have access to the source code (or to decent log files, for that matter).

For mysterious situations like this, we recommend introducing a nightly restart. That is, you should have AlwaysUp automatically restart Google Drive at a set time when no one is likely to be using it.

The theory is that restarting Google Drive will clear out any resource leaks. Afterwards, the program will come up “fresh” and ready to do its work — at least for the next few hours.

To restart Drive nightly:

  1. Edit Google Drive in AlwaysUp (select Application > Edit/View “Google Drive for desktop” from the menu).

  2. In the Edit/View Application window that comes up, switch to the Monitor tab.

  3. Check the Every box, select Day from the drop-down and choose a convenient time to restart Google Drive. 2 AM works for us:

    Restart Google Drive every night at 2 AM
  4. Save your changes.

With that setting in place, AlwaysUp will restart Drive every night at 2 AM. And as a result, no instance of Drive will run for longer than a day. If we’re lucky, no resource leak will grow fast enough to cripple Drive within those 24 hours.

But if we’re not dealing with a resource leak and Drive can stop working at any time, a nightly restart won’t help much. Fortunately, the next solution tackles the problem more directly.

Solution #2: Install a sanity check to detect the failure and automatically restart Google Drive

We built AlwaysUp to handle a range of failures while running an application. For example, AlwaysUp can detect and automatically recycle programs that:

  • Use too much memory;

  • Run wild with the CPU;

  • Get stuck at a crash window;

  • Become unresponsive to input.

For those cases, you simply specify the restrictions (e.g. the maximum RAM to use) and AlwaysUp will deal with any violations on your behalf.

But none of those built-in capabilities will help with your Google Drive problem. When Drive fails, it’s not related to CPU, RAM or any of the metrics that AlwaysUp tracks. It’s about knowing when your G drive isn’t mapped.

To handle non-standard failures like yours, we must rely on AlwaysUp’s Sanity Check feature. We’ll write a batch file that detects when the G drive isn’t mapped and then show you how to plug that into AlwaysUp.

Download our sanity check to detect when your G drive isn’t available

Here is the batch file we developed for your situation:

@echo off
:: This batch file checks if a drive letter is mapped or not.
:: It exits with 0 if the drive is mapped and 1 if it isn't.
SET gdrive=G
if exist %gdrive%:\ (
    	echo The %gdrive% drive is mapped Exiting with 0 to continue running.
	exit /b 0
echo The %gdrive% drive is NOT mapped. Exiting with 1 to restart.
exit /b 1

As you can see, it simply checks if the G:\ folder exists and returns:

  • 0 if G:\ is accessible

  • 1 if G:\ cannot be accessed

Please download the script and save it in a known location on your computer running Google Drive. We’ll use it in the next step.

Plug the sanity check into AlwaysUp

Since we have a batch file to detect the problem, let’s tell AlwaysUp how to use it:

  1. Edit Google Drive in AlwaysUp (select Application > Edit/View “Google Drive for desktop” from the menu).

  2. In the Edit/View Application window that comes up, switch to the Monitor tab.

  3. Check the Whenever it fails a “sanity check” box and click the button:

    Install the sanity check
  4. In the Configure Sanity Check window that comes up, enter the full path to the batch file in the Run field and specify how often to perform the sanity check. Every 5 minutes should be enough so that’s what we entered:

    Configure the Google Drive sanity check
  5. Save your changes.

And with that sanity check in place, AlwaysUp will run the batch file every 5 minutes. If the batch file returns 0, indicating that the G drive is available, nothing will happen. AlwaysUp will continue to babysit Google Drive (and schedule the next check for 5 minutes later).

But if the batch file returns 1 — because it couldn’t access the G drive — AlwaysUp will promptly shut down Google Drive and start a new copy. Doing so should restore access to the G drive.

Happy Google Driving!

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

AlwaysUp 15: Helpful Diagnostics, plus Advanced Monitoring for Dropbox, OneDrive and Google Drive

AlwaysUp 15: Advanced Monitoring of Dropbox, OneDrive and Google Drive

Our team released AlwaysUp version 15 on December 8 — just in time for the holidays. 🙂

This time, we focused on making AlwaysUp better at identifying technical problems and providing excellent support when things don’t go as expected. Here are a few highlights:

AlwaysUp now collects helpful application diagnostics — so you don’t have to

Most customers have AlwaysUp installed and running their application as a Windows Service in a few minutes. But sometimes things get tricky and you need assistance from our excellent support team.

Previously, we’d ask you to collect relevant technical information yourself. It’s easy enough to do but it takes a few minutes.

Starting in version 15, AlwaysUp will collect all the information on your behalf. Simply select Advanced > Collect Diagnostic Information to bring up the step-by-step wizard (shown here interrogating OneDrive):

Collect OneDrive diagnostics

Click Next and in a few seconds AlwaysUp will deliver text describing your setup:

OneDrive diagnostics: Results

Save the text to a file (or copy it to the clipboard) and include it in an email to our technical support team. Easy peasy!

Find out more about this convenient, time-saving feature on the application diagnostics page.

Introducing advanced monitoring for popular applications: Dropbox, OneDrive and Google Drive

We have many customers running Dropbox, OneDrive and Google Drive for desktop as Windows Services.

To provide a better experience for those customers, AlwaysUp 15 includes code that works closely with those applications to detect (and shout) when things go awry.

For example, AlwaysUp will now warn you if OneDrive is showing an unrecognized prompt. We bring that to your attention because it might mean that OneDrive is stuck waiting for your input and isn’t synchronizing your files:

Warning: OneDrive is showing a prompt

We plan to build on this comprehensive detection framework in future releases — to reduce the number of headaches in your life.

Running an unstable application? Configure hourly restarts to keep it “fresh”

If you’re working with an application that can barely stay healthy for 60 minutes, you have our sympathies!

But even more than that, you now have a way to safely restart the application every hour — at the minute of your choosing.

The new “Every Hour” option is available for selection on the Monitor tab:

AlwaysUp hourly restart

Other fixes & improvements

  • Windows shutdown is unpredictable and often chaotic. In fact, applications can be terminated in random order, so you’re never quite sure how things will unfold.

    This version of AlwaysUp makes use of technical mechanisms to inform Windows what’s going on at system shutdown. And that can make a significant difference for applications that take a while to exit gracefully.

  • The Application Advisor — which makes it easy to set up a dozen popular applications as Windows Services — got smarter when installing OneDrive. A new two-minute restart delay tolerates unpredictable automatic updates, while a new shutdown command ensures that OneDrive closes smoothly when exiting.

  • We fixed a problem where an application with unusual characters in its name couldn’t write records to the Windows Event Logs.

  • You can now select a group managed service account when browsing for a user on the “Logon” tab.

As usual, please review the release notes for the full list of features, fixes and improvements included in AlwaysUp version 15.

Upgrading to AlwaysUp 15

If you purchased AlwaysUp version 14 (after November 2022), you can upgrade to version 15 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. Consequently, please purchase upgrades here — at a 50% discount.

See the complete upgrade policy for additional details.

Thank you for reading!

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

Q&A: How do I Enforce a Single Instance of my Python Script with AlwaysUp?

How do I enforce a single instance of my Python app with AlwaysUp?

I am trying the 30 day demo to see if AlwaysUp works for my application. I am running a couple of python scripts and so far your application works perfectly. I do however have an issue. It is critical that only one instance of my application runs when I run it from the command line my mutex works as it should.

My code looks like this:

Python code to manage a mutex

I am able to run a second instance from a command line. This will cause some serious misreporting if two applications are running. Is there anything I can do?


— Carl

Hi Carl, thanks for trying AlwaysUp. Thanks also for sending your code, which enabled us to identify the problem quickly. It has to do with how mutex locks work.

Your mutex isn’t visible across sessions

By default, mutexes have “session scope”. That is, they exist only in the login session where they were created. And that has important consequences.

For example, let’s say that Alice logs in to a computer. Obviously, she can start a copy of your Python script just fine. But when Alice attempts to launch a second copy, it fails — exactly as you’ve designed.

Now let’s say that Bill logs into his account on the same computer. Like Alice, he will be able to start only a single copy of your script.

But there will now be two instances of your Python script running on the PC — one for Alice and one for Bill. That’s probably not what you want, right?

In summary, your current single-instance enforcement mechanism will actually allow multiple copies because your application creates a different mutex in each login session.

Now, let’s review why that’s important when running your Python script as a Windows Service.

AlwaysUp runs your application in a different session

To start your Python script at boot, AlwaysUp runs it in the background in the isolated Session 0.

And when you log into your computer, Windows creates a new session for you — Session 1, 2, or 3, etc.

You’re able to “run a second instance from a command line” because the mutex doesn’t do its job across the two sessions.

Use a Global mutex to restrict all instances of your app

Fortunately the fix is simple. Give our mutex a “global scope” so that it applies across all login sessions.

Indeed, all you have to do is prefix the name of your mutex with “Global\” (no quotes). It’s a one-line update to your code, like this:

self.mutexname = app_name + “Global\_mutex_{eaf8379e-5231-412c-92da-a0328eacea9e}”

For additional context, check out Microsoft’s description of the situation in their technical documentation on mutex objects:

 On a server that is running Terminal Services, a named system mutex can have two levels of visibility. If its name begins with the prefix Global\, the mutex is visible in all terminal server sessions. If its name begins with the prefix Local\, the mutex is visible only in the terminal server session where it was created. In that case, a separate mutex with the same name can exist in each of the other terminal server sessions on the server. If you do not specify a prefix when you create a named mutex, it takes the prefix Local\. Within a terminal server session, two mutexes whose names differ only by their prefixes are separate mutexes, and both are visible to all processes in the terminal server session. That is, the prefix names Global\ and Local\ describe the scope of the mutex name relative to terminal server sessions, not relative to processes.

Hopefully that all makes sense now.

Please get in touch if you have any other questions running your Python scripts as Windows Services.

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