As a member of the Windows Insider program, we’ve had the opportunity to test drive the new operating system for the past couple of months. Our verdict? Windows 11 provides a welcome facelift to Windows 10, while leaving the low-level internals and APIs largely untouched. It’s more evolution than revolution.
Let’s dig into the details of Windows 11 — and investigate how our software performs on the brand new operating system.
Support for moving the taskbar to different locations on the screen (e.g. top, left, or right) has been removed. That was convenient for our team, especially when making screen recordings.
Internet Explorer has been disabled and replaced by Microsoft Edge. Finally! We won’t miss IE around here…
Right-clicking on the taskbar calls up a menu with a single entry — Taskbar settings. We’ll miss the convenience of quickly summoning Task Manager, showing the desktop or effortlessly arranging windows from the Windows 10 taskbar. 🙁
To find out if your computer supports TPM, run tpm.msc from a command prompt. Here you can see that our Windows 10 desktop (purchased in 2019) supports TPM version 2.0:
Note that TPM is a requirement for physical hardware, not for virtual machines. We had no trouble installing Windows 11 on a VirtualBox virtual machine, even though TPM is not supported there.
One oddity to watch out for: Windows 11 Home edition requires internet connectivity and a Microsoft account to complete setup on first use. Apparently Microsoft is very keen to bring you into their online ecosystem!
What’s changed for Windows Services?
As far as we can see, Windows 11 does not introduce any changes to the Windows Services API, nor to the service-related tools distributed with the operating system.
And finally, the practical NET and SC commands don’t present any new options either.
Does AlwaysUp run on Windows 11?
Other than a minor inaccuracy detecting the operating system version in internal logging components, AlwaysUp version 13.0 (to be released in October 2021) performed perfectly on Win 11.
And over the course of the past 7 weeks, we have run OneDrive, Dropbox, Java and VirtualBox continuously as Windows Services. All have performed flawlessly through multiple reboots, automatic updates, deliberate crashes and other challenging scenarios.
Does Service Protector work well on Windows 11?
With the underlying Windows Services architecture remaining intact, we detected no issues running Service Protector 7.0:
What about your other software? Are they all compatible with Win11?
To date, here are the results of our testing on the new operating system:
The only application that did not pass with flying colors is MyFolders. Unfortunately the MyFolders menu is not visible when you right-click in File Explorer! And in order to reveal the MyFolders menu, you must select Show more options:
Afterwards, the familiar menu from Windows 10 will appear and you will be able to interact with MyFolders as normal:
We’ll see if there is a way to eliminate the inconvenience of that extra click.
Best of luck with Windows 11 if (when) you decide to upgrade!
Rest assured that AlwaysUp manages your Windows securely. Here are some of the measures in place to protect your valuable credentials.
AlwaysUp hides your Windows password on the Logon tab
As a first line of defense, the field that captures your Windows password “masks” the characters, showing asterisks (“*”) instead of the characters you type:
By doing so, AlwaysUp does not reveal your password to casual onlookers.
Windows stores your password — not AlwaysUp
Next, and more importantly, AlwaysUp never keeps, tracks or transmits your Windows password after it creates (or updates) a service.
Instead, AlwaysUp hands your password to the Windows Services layer (via the CreateService or ChangeServiceConfig API functions), which stores the password securely. In that way, your password is handled just as safely as it is with the trusted operating system tools, like the Services application.
Specifically, the Service Control Manager — which launches and initializes services — stores the password with LsaStorePrivateData. And when it’s ready to start a service, the SCM calls LsaRetrievePrivateData to retrieve the service’s password. After the initial creation, AlwaysUp is simply not involved.
AlwaysUp doesn’t include your password when you export
As another important security measure, AlwaysUp does not (actually, cannot) include your Windows password when you export your application to an XML file. Instead, you will see ENTER A PASSWORD in the password field:
Because AlwaysUp saves a placeholder instead of your password, you will have to re-enter your password when you import the XML file. However our team thought that was a small inconvenience to avoid leaking a sensitive password.
A note on Excel as a service
Please be sure to follow our tutorial showing how to run Excel 2013 with AlwaysUp. Please heed the comment about automation at the top of the page. Unfortunately, not all Excel functions operate properly in the context of a background Windows Service.
Our build server has a ton of services installed and it takes a while for them to start whenever the machine boots. One of the services doesn’t connect to the database if it starts too soon. When that happens, I have to log in and start it manually. Is there a way to delay the service until the other services are up and running?
— Christos D.
After some brainstorming, our team has come up with four potential solutions for you.
Solution #1: Set your Service to “Automatic (Delayed Start)”
The simplest way to delay a service is to adjust when it starts at boot. Instead of starting as soon as possible, you can tell Windows to launch the service about 2 (or more) minutes after boot.
To make that change:
Start the Services utility.
To do so, press the Windows + R keys to open the Run window, and then type services.msc.
Find your service in the list. Double-click its row to open the service’s properties.
In the Startup type field, select Automatic (Delayed Start) from the list:
Click OK to save your change.
Need to wait for longer than 2 minutes?
By default, all “delayed start” services are launched a couple of minutes after boot. Fortunately, that wait time is configurable and you can set it to longer if you like, but that setting applies to all delayed start services. There is simply no way to adjust the wait time of a single delayed start service.
Solution #2: Specify a Dependency between Services
Another option for delaying the start of a service is to mark it as dependent on another service.
To explain, let’s take two services, Service1 and Service2. If Service1 must start before Service2, you would update Service2 to add Service1 as a dependent. You would say that Service2 depends on Service1.
I know that may be a bit confusing, so let’s look at a real-world example.
Microsoft’s “System Events Broker” depends on a couple of services: “Remote Procedure Call (RPC)” and “RPC Endpoint Mapper”. You can see the relationship in the service’s properties (in the Services application):
Because of those dependencies, Windows will always start the two RPC services before launching the “System Events Broker” service.
Note however, there are significant side effects of setting up a dependency relationship between two services.
For example, the screenshot above also shows that “Task Scheduler” depends on “System Events Broker”. As a result of that relationship, stopping “System Events Broker” will stop “Task Scheduler”, as the Services application informs us here:
You see, the dependency relationship is about much more startup sequence. It implies that “System Events Broker” is critical for “Task Scheduler” to operate.
So if you mark your service as dependent on another service, stopping that other service might stop your own. Make sure you’re OK with that.
Solution #3: Launch your service from an “at startup” scheduled task
Instead of having the Windows Services launch your service, you can shift that responsibility to the Windows Task Scheduler. And in doing so, you can introduce a post-boot delay to start the service after your machine settles down.
Here’s how to create a scheduled task that starts your service a few minutes after boot:
Launch the Task Scheduler.
To do so, press the Windows + R keys to open the Run window, and then type taskschd.msc.
On the right, click Create Basic Task to launch the wizard:
Give your task a meaningful name. For example, we’re restarting the Print Spooler service 10 minutes after boot:
On the summary screen, check the Open the Properties dialog… box. We still need to make a few adjustments to the new scheduled task:
Click Finish to exit the wizard.
In the Properties window that comes up, affirm a couple of options:
Run whether user is logged on or not. Otherwise, your service will only restart when you’re logged on.
Run with highest privileges. Necessary because starting your service likely requires administrative rights.
Switch to the Triggers tab and edit the At startup trigger.
In the Edit Trigger window, check the Delay task for box and enter your delay in minutes. You may have to type the time as not all values appear in the dropdown:
Click OK to save your change.
Back on the Properties window, click OK to close out of the task. You will probably have to enter your password:
And now that you have a scheduled task to start the service when you want, you should prevent the service from trying to start automatically at boot. Open your service’s properties and change the Startup type to Manual:
Finally, please reboot and make sure that your service starts in the expected time frame.
Solution #4 (for AlwaysUp services only): Pause before starting
If your service was created by AlwaysUp, you are able to stall your application via a configuration setting.
To do so:
Edit your application in AlwaysUp.
Switch to the Startup tab.
In the Pause for field, enter a suitable delay in seconds:
Check the But only after a reboot box — to avoid the pause when you start the service/application manually.
Click OK to save your settings.
The next time your computer boots, Windows will start the AlwaysUp service. And, as you instructed, AlwaysUp will pause for a while before launching your application.
Hopefully one of these methods will work in your situation!
My team manages a few third-party Windows Services. We plan to write scripts that start, stop and restart the services as part of regular maintenance through batch files. Should we use NET or SC? What’s the difference? Is one more reliable?
Yes, both commands are adept at manipulating the state of a Windows Service. For example, both NET STOP and SC STOP will cause a service to shut down.
And both NET and SC are mature, stable and reliable utilities. Apparently Microsoft has worked out all the bugs over the past 30 years. 🙂
However, as far as developing batch files to start, stop and restart services, there is one subtle but important difference between the two utilities.
NET makes a request and waits to confirm…
When you issue a NET START or NET STOP command, NET.EXE:
Rejects the operation if the service is not in a compatible state. For example, if a stop was requested but the service is already stopped, an error is returned (likely exit code 2).
Requests that the service transitions to the appropriate state (with ControlService).
Returns success (exit code 0).
SC does not wait for the service to stop or start.
What the difference means for your batch files
Because SC does not wait for the service to transition to the desired state, you have to be careful when you use SC in batch files.
For example, to restart a service, this sequence looks like it should do the trick:
SC STOP ServiceName SC START ServiceName
And it works, for many services!
Indeed, here is the Print Spooler service quickly transitioning through the PENDING states and ending up running, as desired:
However, things go awry if the service takes a few seconds to stop.
For example, our CloudFileServer service takes 2-5 seconds to terminate (while it closes and uploads transient files to a remote site). The SC script doesn’t fare as well with that service:
As you can see, SC STOP succeeds and the service promptly transitions to the STOP_PENDING state. Unfortunately, the subsequent SC START fails with the “already running” error because the service is still shutting down — it has not yet stopped. And the final result (not pictured) is a dead service — the opposite of what we were hoping to achieve!
On the contrary, the equivalent sequence with the NET command worked much better:
However, NET will run into the same problem as SC if the service takes longer than 30 seconds to stop.
You should pause or confirm when using SC
Of course, you can have SC behave like NET by adding extra code to your script. For instance, adding the TIMEOUT command (which pauses for a fixed period) will give a slow service the chance to stop gracefully before attempting to restart it:
Despite being almost 20 years old, Microsoft’s free Srvany utility is still a surprisingly popular tool. Every week, we come across at least one person using the ancient service wrapper to install an executable or batch file to start at boot as a Windows Service.
Truthfully, Srvany is fine for many situations. It’s basic, and it works. And the price is right.
However, the utility has several shortcomings that aren’t immediately obvious. Here are the top 3 that we (and our customers) have encountered over the years:
Problem #1: Srvany may continue to run even though your application is dead
When it is started, a Srvany service immediately launches its target application. And if the application starts properly and runs without interruption, everything is great.
But what happens if the application crashes or stops running?
To find out, we created a new service that runs the Windows Notepad text editor:
When we started the service, Srvany launched notepad.exe as instructed. Here you can see the service in the “Running” state with Notepad operating in Session 0:
Next, we forcibly terminated Notepad.exe. As expected, the process disappeared.
However, even after Notepad had exited, the service remained in the “Running” state. Misleading, to say the least.
Basically, you cannot rely on the state of a Srvany service to reflect the state of the target application. Just because the service says its running doesn’t mean that the application is!
Problem #2: Srvany may leave your application running after the service stops
As described in this article, when you stop a Srvany service, only the target application is closed. If the target application had launched other applications, those others will not be stopped.
This can be a problem for batch files and applications involving multiple processes.
To illustrate, we installed a new Srvany service that runs a batch file. The batch file starts Notepad:
When we started the service, Srvany launched the batch file, which started Notepad. So far so good:
However, when we stopped the service, only the batch file (cmd.exe) was terminated. Notepad continued to run, alive and well — despite the service being in the stopped state.
Here again, the state of the service does not reflect the state of the target application. But there are unwelcome side effects too.
If we start the service again, Srvany will launch a fresh copy of Notepad. And then we have two copies of Notepad running. This “duplicate” scenario can create chaos for more complex situations, for example with applications that should not run multiple instances. Watch out!
Problem #3: Srvany isn’t particularly user friendly
According to our customers, Srvany comes up short in three areas of usability:
There is no GUI to install your application as a service. You must use a separate command line tool (Instsrv) to create a new Srvany service, which is less than ideal.
To configure the application to run, you have to create keys and values with the Windows Registry Editor — an administrative tool that can cripple your PC if you use it incorrectly.
Srvany is difficult to troubleshoot because it doesn’t write a log file or provide helpful feedback when things go wrong. As a result, frustration often ensues.