Service Protector 9.0 is now available for download. Here’s what’s new in this version:
Moving to another computer? Easily import protectors “in bulk” — instead of one at a time
The best way to copy (or move) a Service Protector configuration to a different computer is to:
Export the protector to an XML file from the existing installation, and then
Import the XML file to create a new protector in your new installation.
This works fine if you’re protecting one or two services, but importing files one by one creates significant overhead if you have 20+ services to restore!
The new “bulk import” capability aims to reduce that overhead. With the new feature, you simply select the files you wish to import and walk through the step-by step wizard to protect the same services on your new computer.
Here’s a brief overview of the new import process:
Choose Import from the Protector menu:
Select the files that you exported from your other installation of Service Protector.
Service Protector will start processing your files:
From there, follow the self-explanatory prompts to create protectors for all the files you selected.
Note that as part of the import process, Service Protector may ask you to resolve conflicts.
For example, you may have to choose a new service if the one in the XML file is already protected:
Click Edit & Fix and select a different Windows Service from the list.
Or if a protector is configured to send email but the XML file doesn’t contain the password for your email account, you will be prompted to add it:
Click Edit & Fix and move to the Email tab to enter your password.
As you can see, the new feature is very easy to use. We hope that it will be a time-saver for our customers working with many Windows Services.
Other improvements
Improved the handling of non-English text throughout the application, including when sending email and reporting activity.
Service Protector will now log an entry to the Event Viewer whenever Windows starts a protector at boot. That makes it easy to identify when protection was started manually (by a person or process) versus automatically after a reboot.
To help customers who buy upgrades, we added the ability to remove the software’s registration code. Doing so will return Service Protector to the unregistered state and give you the opportunity to enter a new registration code.
Fixed an issue with the registration window being “cut off” on high-resolution, 4K screens.
The “About” window now mentions the major version number licensed.
As usual, please review the release notes for the full list of features, fixes and improvements included in Service Protector version 9.0.
Upgrading to Service Protector 9.0
If you purchased Service Protector version 8 (after November 2021), you can upgrade to version 9 for free. Simply download and install over your existing installation to preserve your existing services and all settings. That way, your registration code will continue to work.
If you bought Service Protector 7 or earlier (before November 2021), you will need to upgrade to use version 9.
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:
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.
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.
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.
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:
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:
The version of Windows your computer’s running
The version of OneDrive installed (click the OneDrive tray icon; select the gear in the upper left; choose “Settings”; go to the “About” tab)
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
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.
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:
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.
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
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.
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.
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
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.
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.
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. 🙂
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:
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:
The AlwaysUp Windows Service starts;
AlwaysUp launches your batch file;
The batch file starts your Java application;
Java tries to open a specific numeric port so that it can accept network requests from clients;
Windows detects that the port is already in use by another application and returns an error to the Java app;
Because the Java application cannot open it port, it exits;
And since all the commands in the batch file have completed, the batch file exits too;
AlwaysUp detects that the batch file is done;
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”:
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.
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:
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:
Write a batch file that terminates any process already listening on the port
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
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:
Double-click your batch file entry in AlwaysUp to open its properties;
In the Edit/View Application window, switch to the Startup tab;
Check the Run the following program/batch file box;
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;
After the path, enter the Java application’s listening port number. We’ve entered 8008 for our application;
Check the Also whenever the application is restarted box as well:
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:
The AlwaysUp Windows Service starts;
AlwaysUp launches the “terminate process by port” batch file;
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;
AlwaysUp launches your “main” batch file;
The batch file starts your Java application;
Since the port is available, your Java application secures the port and starts properly;
AlwaysUp monitors the “main” batch file and restarts it if it stops for any reason.
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.
What is the User Profile Service (ProfSvc) service?
The ProfSvc Windows Service is responsible for loading and unloading user profiles — collections of settings and information associated with each Windows account. It’s also an integral component of SharePoint server.
The service’s display name is User Profile Service and it runs as LocalSystem inside the service host process, svchost.exe. By default, the service is set to start automatically when your computer boots:
What happens if I stop ProfSvc?
The service’s description cautions:
If this service is stopped or disabled, users will no longer be able to successfully sign in or sign out, apps might have problems getting to users’ data, and components registered to receive profile event notifications won’t receive them.
If none of that functionality seems important to you and you try to stop the service, doing so will force several dependent services to stop as well. There are three of those on our Windows 11 PC:
However, even after clicking “Yes” to proceed, User Profile Service failed to stop. The following error was presented:
And even worse, trying to stop the service left our machine in an inconsistent state. From then on, Windows refused to start some applications (like Task Manager):
We had to reboot to restore normal operation.
Apparently the User Profile service is more important than it appears!
Is it OK to disable User Profile Service?
At the very least, disabling the service will prevent anyone from logging in to your computer.
Unless you’re deliberately trying to block all access, including your own, that’s probably not a good idea.
It’s best to leave the service enabled and set to start automatically at boot.
Questions? Problems?
If you would like to know more about the User Profile service, or you have a specific problem, please feel free to get in touch. We will do our best to help you!
(888) 881-CORE
![Q&A: Why doesn't OneDrive Delete my Files when Running as a Windows Service? [RESOLVED]](https://www.coretechnologies.com/blog/wp-content/uploads/onedrive-delete-files-problem-150x150-1.png)
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.
