The Core Technologies Blog

Professional Software for Windows Services / 24×7 Operation


OneDrive Version 23.48: Trouble Running in Session 0 [RESOLVED]

OneDrive Version 23.48: Trouble Running in Session 0

This week, several AlwaysUp customers reported that OneDrive suddenly stopped copying their files. It seems that the trouble began after OneDrive automatically updated itself to version 23.048.0305.0002, which Microsoft started pushing to everyone on March 21st.

Needless to say, we’re actively investigating. Here’s what we’ve learned so far:

  1. For some customers, OneDrive fails to synchronize any files when AlwaysUp runs it in the background in Session 0. The OneDrive executable actually starts normally and keeps running — it just doesn’t do its job.

  2. Not all customers are impacted. Many AlwaysUp installations continue to sync files happily, with the latest version of OneDrive starting at boot in Session 0.

  3. OneDrive is completely fine when it’s started in the interactive session from AlwaysUp — by selecting “Start OneDrive in this session” from the “Application” menu. The fault only appears in Session 0.

  4. Our development team hasn’t been able to reproduce the problem. OneDrive 23.048 works flawlessly on all our Windows 10, 11 and Windows server 2022 computers.

    For example, here is a look at OneDrive passing all our file synchronization tests:

    OneDrive 23.48 working in Session 0 on Windows Server 2022

Temporary solutions

Until we get to the bottom of the problem, please run OneDrive normally on the desktop. Of course, you will have to stay logged in to your computer (which we know is less than ideal).

Another option is to roll back to a previous version of OneDrive that works in Session 0. You can download old versions from the release notes page. If you go that route, you will probably have to uninstall your current OneDrive before installing the old version. Also, you will need to disable automatic updates or else OneDrive will soon reinstall the faulty version.

Trouble running OneDrive with AlwaysUp?

If you’re suddenly having problems running OneDrive with AlwaysUp, be sure to get in touch. Please let us know:

  1. The version of Windows your computer’s running

  2. The version of OneDrive installed (click the OneDrive tray icon; select the gear in the upper left; choose “Settings”; go to the “About” tab)

  3. When you think your problems started

We’ll review your situation and do our best to help.

Hopefully Microsoft will soon fix the problem that surfaced in OneDrive version 23.048.0305.0002. In any case, we’ll keep pushing for our own solution too. Fingers crossed!


March 25 2023: Update

  1. The problem seems to occur on Windows Server 2019 and 2022. All the reports we’ve received have been from customers running those operating systems. However, some customers running 2019 and 2022 are fine! Perhaps it’s related to recent Windows updates?

    In any case, if you’re seeing the problem on Windows 10 or 11, please let us know.

  2. We’ve confirmed that the issue is not unique to AlwaysUp — it’s a problem running OneDrive in the context of a Windows Service in Session 0.

    Indeed, we tried many similar tools (including Microsoft’s PsExec) and none were able to launch OneDrive in the background. Most times OneDrive quickly crashed with a strange exception hinting that user interface elements may be involved in the drama:

    Faulting application name: OneDrive.exe, version: 23.48.305.2, time stamp: 0x454d6e69
    Faulting module name: Windows.UI.Xaml.dll, version: 10.0.22621.1344, time stamp: 0x95ad35df
    Exception code: 0xc000027b
    Fault offset: 0x00000000008704e0
    Faulting process id: 0x0x23D0
    Faulting application start time: 0x0x1D95F784F0ABAC4
    Faulting application path: C:\Program Files\Microsoft OneDrive\OneDrive.exe
    Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll
    Report Id: a47c6cb6-66fc-4244-81b5-94df6437460c
    Faulting package full name:
    Faulting package-relative application ID:
  3. Since the trouble is in Session 0, one solution is to setup automatic logon and have AlwaysUp launch OneDrive in the auto-logon session. That way OneDrive will start automatically after a reboot.

    The autologon approach is described here in our FAQ. Again, it’s less than ideal to have a user logged on but it may be OK for a while. Note that you can lock the screen automatically after login if that helps.

  4. Special thanks to Perry Nelson for providing us with a Server 2022 machine that exhibits the issue. That has been super helpful as we’ve still not been able to reproduce the failure on our 2019 and 2022 test servers.


April 2 2023: Update

  1. Unfortunately the latest pre-release version of OneDrive (23.066.0326.0005, released on April 1) still fails to copy files when run in Session 0. With an abundance of optimism, we’ll continue to test Insider builds as they become available. The best fix will come from the OneDrive developers themselves.

  2. So far we’ve only had one report of trouble on Windows 11 — but that turned out to be a false alarm. All other reports have been on Windows Server.

    Curiously, our Windows Server 2019 and 2022 machines (with all required & recommended patches applied) continue to work flawlessly. We have no idea why.

  3. We’ve asked for help on Microsoft’s OneDrive forum. Hopefully some kind and knowledgeable soul will provide insight soon.

  4. Do you have a support contract with Microsoft? If so, can you please try to get them to look into what changed in OneDrive? Perhaps they will move quickly for a paying customer.


April 12 2023: Update

  1. We’ve heard from several customers that the latest Insider/pre-release builds of OneDrive work properly in Session 0. Most folks reported success after version 23.071.0402.0001, which was released on April 7.

  2. Indeed, our team was able to confirm OneDrive version 23.073.0404.0001 (April 10) working in Session 0 “with our own eyes”. Thanks again to Perry Nelson for his generosity in making a system available for testing.

  3. Unfortunately we have no idea how long it will take for Microsoft to move the fix through the delivery pipeline and into a production release. Until then, we recommend that you manually install OneDrive version 23.073.0404.0001 or later.

Thanks to everyone for their patience and support throughout this drama! Apparently our little solution to the real-world problem of running OneDrive unattended lives to fight another day. 🙂

Posted in AlwaysUp | Tagged , , , | 21 Comments

Q&A: Why won’t AlwaysUp Start my Java Application?

Why won't AlwaysUp Start my Java Server Application
  I have two Java socket applications installed in AlwaysUp. Even though they are similar and both are started from batch files, AlwaysUp runs one fine but has trouble with the other.

Whenever I look in AlwaysUp, one Java entry always says “Waiting”. But if I open the browser I can connect to the server just fine. Why does AlwaysUp think that it’s not running when it is?

— Jeff

Hi Jeff.

I suspect that your Java application is being blocked by another instance of itself. And when that happens, AlwaysUp just keeps trying to restart it. Let’s dig into the details.

Why AlwaysUp can’t start your Java application and constantly says its “Waiting”

First, understand that AlwaysUp only shows the “Waiting” state when it’s waiting to restart your application. You must have configured a delay on the Restart tab, as pictured here:

AlwaysUp delay after restarting

But AlwaysUp only waits before restarting the application. So the question is, why is your application stopping?

Since you mentioned that your Java server uses TCP/IP sockets, we have a hunch that there is a conflict with a network port. The problematic sequence probably plays out like this:

  1. The AlwaysUp Windows Service starts;

  2. AlwaysUp launches your batch file;

  3. The batch file starts your Java application;

  4. Java tries to open a specific numeric port so that it can accept network requests from clients;

  5. Windows detects that the port is already in use by another application and returns an error to the Java app;

  6. Because the Java application cannot open it port, it exits;

  7. And since all the commands in the batch file have completed, the batch file exits too;

  8. AlwaysUp detects that the batch file is done;

  9. Instead of restarting the batch file immediately, AlwaysUp pauses for a while as specified on the Restart tab (see the screenshot above). The AlwaysUp GUI application shows the state as “Waiting”:

    Waiting to restart the application
  10. Once it’s done waiting, AlwaysUp launches the batch file again (step 1) and the cycle repeats itself.

Indeed, AlwaysUp’s activity report — available by choosing Report Activity > Today from the Application menu — will likely confirm the futile attempts to start your application every minute. You probably have hundreds of entries in the Windows event logs too!

Why your application works even though AlwaysUp failed to start it

Your browser tests succeed because there is another copy of your Java application running. It’s listening to the port and responding to your browser’s requests.

You can confirm this situation by:

  1. Opening the Task Manager (or better yet, Microsoft’s amazing Process Explorer) and locating the java.exe process already running;

  2. Using the netstat command to find out which application already has the port open.

    For example, this command identifies the process listening on port 8008:

    netstat -ano -p tcp | find ":8008"

    As you can see below, the culprit was the process with ID 3484 on our Windows 11 PC:

    NETSTAT for port 8008

But why doesn’t AlwaysUp “discover” the existing Java server and manage it?

First, realize that the current instance of your Java application was not started by AlwaysUp. That is, it’s running independently of AlwaysUp.

Second, you’ve got to understand how AlwaysUp works.

AlwaysUp is designed to start an application and ensure that it’s always running. Most importantly, AlwaysUp does not “discover” or “latch on” to an application that is already running. AlwaysUp can only manage and babysit applications that it starts itself.

The fact that a process on your machine is responding to your browser means nothing to AlwaysUp because that process was not started by AlwaysUp.

How to fix the problem

The solution is straightforward.

Simply terminate the current instance of the Java application running on your machine. Doing so will free up the port and allow a new instance started by AlwaysUp to secure the port and start properly.

How to ensure that AlwaysUp always starts your Java app

As you have seen, AlwaysUp will fail to start your Java app if there is another copy already running. The solution is to stop the existing server before AlwaysUp launches its own instance.

But what if this happens again and you’re not around to kill the non-AlwaysUp process? That may leave your system in a vulnerable state, with your Java application unprotected from crashes and other interruptions.

Fortunately, there’s a two-step fix. You can:

  1. Write a batch file that terminates any process already listening on the port

  2. Have AlwaysUp run that batch file right before it starts your application

That way, your Java application always starts properly because there won’t be anything holding on to the port.

Download our batch file that terminates the application listening on a given port

Good news!

We’ve gone ahead and created a batch file that stops the process listening on a given port.

Batch file to end a process by port

Download the batch file and save to a folder on your computer.

Plug the “terminate process by port” batch file into AlwaysUp

To make AlwaysUp run the “terminate process by port” batch file before it fires up your “main” batch file:

  1. Double-click your batch file entry in AlwaysUp to open its properties;

  2. In the Edit/View Application window, switch to the Startup tab;

  3. Check the Run the following program/batch file box;

  4. Enter the full path to the “terminate process by port” batch file you downloaded. Be sure to surround the value with quotes if it contains a space;

  5. After the path, enter the Java application’s listening port number. We’ve entered 8008 for our application;

  6. Check the Also whenever the application is restarted box as well:

    Plug in the terminate-port-process batch file
  7. Finally, save your changes.

With the “terminate process by port” batch file involved, here is the new sequence when you start your Java entry in AlwaysUp:

  1. The AlwaysUp Windows Service starts;

  2. AlwaysUp launches the “terminate process by port” batch file;

  3. The batch file checks for an application listening on the designated port. If an instance of your Java app is already running on the port, the batch file terminates it;

  4. AlwaysUp launches your “main” batch file;

  5. The batch file starts your Java application;

  6. Since the port is available, your Java application secures the port and starts properly;

  7. AlwaysUp monitors the “main” batch file and restarts it if it stops for any reason.

You will be good to go!

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

Our Software is TAA Compliant

Our Software is TAA Compliant

What is the TAA?

TAA refers to the Trade Agreements Act (19 U.S.C. & 2501-2582), which was enacted by the U.S. government in 1979 to foster fair and open international trade.

The TAA requires that the U.S. Government acquire “U.S. made” products — ones that are produced or undergo a “substantial transformation” within the United States or a designated country.

TAA compliance make it possible for U.S. government agencies and educational institutions to do business with USA-based companies like Core Technologies Consulting. Federal procurement contracts that require TAA compliance include GSA (General Services Administration) Schedule contracts, IDIQ (Indefinite Delivery, Indefinite Quantity) contracts, and most DoD (Department of Defense) contracts.

AlwaysUp, Service Protector and all our software comply with the TAA

Core Technologies Consulting’s software solutions are designed, implemented and supported entirely in the United States. As such, our software meets and exceeds the TAA standards outlined above.

Please contact us if you have questions about TAA compliance

If you need more information about TAA compliance, please get in touch. We’ll be happy to provide an official, signed statement suitable for government agencies.

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


Q&A: How can a Non-Admin User Start my AlwaysUp Service?

How can a Non-Admin User Start my AlwaysUp Service?
  Hi — long time user of AlwaysUp here!

I followed your suggestion in the FAQ to allow my non-admin user to control the Windows Service that AlwaysUp created. Now he can run the NET command to start and stop our application in Session 0 whenever he likes, which is great. But we’re still having one problem.

Sometimes the user needs to start the application in the current session to make changes. The user manual says that running AlwaysUp.exe with the “-restart-in-current-session” parameter will do the trick.

And that command works fine for me (I’m an admin). However, the non-admin user is prompted for admin credentials because his account doesn’t have the rights to run AlwaysUp.

Is there any way to start AlwaysUp.exe without needing admin credentials?

— Steve

Hi Steve. Thanks for getting in touch — and for being a loyal customer!

Permissions is always a thorny topic but we can help you. Let’s start by reviewing why there is no direct remedy from the AlwaysUp executable (AlwaysUp.exe).

AlwaysUp needs admin rights to do its work

Unfortunately it’s not possible to launch AlwaysUp without elevated rights. That’s because AlwaysUp needs to:

  1. Read, create and update your Windows Services

  2. Interrogate the Windows Event logs for errors and warnings

  3. Carefully monitor your important applications and react quickly when they use too much memory, hog the CPU, hang or crash.

Typically only administrators — with broad access to low-level systems — can perform those actions.

So your non-admin user won’t be able to run AlwaysUp.exe. But as you know, there are other ways to start or stop the Windows Service created by AlwaysUp. Let’s explore the NET command since you’re already familiar with how it works.

Use NET to start your application in a given session

To recap, you’re already using the NET command to start your application. If your application is called “MyServer” in AlwaysUp, then this command will do the trick:

NET START "MyServer (managed by AlwaysUpService)"

Notice that you must add the "(managed by AlwaysUpService)" suffix as that is how the service is named in the Service Control Manager.

In any case, running that command instructs AlwaysUp to start your application in Session 0 — the background desktop hosting Windows Services. You won’t see the application on your normal desktop.

Fortunately slight variants of the NET command will enable you to launch your application in a specific session.

Provide a Session ID

To start in a specific session, add the session’s numeric identifier (the Session ID) to the command. The format is:

NET START "<ApplicationName> (managed by AlwaysUpService)" /<SessionID>

For example, to start “MyServer” in Session 2, run:

NET START "MyServer (managed by AlwaysUpService)" /2

That will launch your application in Session 2, regardless of who is logged in there.

Provide a Windows username

Alternately, you can pass a username to start the application in the session occupied by that Windows user. The format of that command is:

NET START "<ApplicationName> (managed by AlwaysUpService)" /"user:<UserName>"

For example, to start “MyServer” in the session where “psmith” is logged in, run:

NET START "MyServer (managed by AlwaysUpService)" /"user:psmith"

Note that if the given user is not logged in, AlwaysUp will start the application in Session 0.

How to use NET to start your application in the current session

To achieve what you’re trying to do, we recommend going with the username variant of the NET command.

This command — which features the USERNAME environment variable — will start your application on the current user’s desktop:

NET START "<ApplicationName> (managed by AlwaysUpService)" /"user:%USERNAME%"

Again, if your application is called “MyServer”, the precise syntax is:

NET START "MyServer (managed by AlwaysUpService)" /"user:%USERNAME%"

When you run the command, %USERNAME% expands to the username of the account invoking the command. In that way, the command works for whoever runs it.

We recommend saving the command to a batch file and placing the file on the user’s desktop, for easy access. With that, your application will only be a double-click away.

Enjoy!

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