Service on Windows Server 2025? Shouldn’t that happen automatically? Sometimes you want to run an executable as a service. Normally you get this feeling, when services you rely on do crash or are not running after a power outage. Running executables as a service can run without login and get functionality like automatic restart and even reboots. While NSSM “Non-Sucking Service Manager” has been a great tool in the past, it is long abandoned, so lets look at alternatives.

Windows Server 2025 might look shinier, but its Service Control Manager (SCM) is the same old workhorse that kept NT 3.1 alive during coffee breaks. If your homelab relies on applications that still ship as naked executables—hello, game servers and self-contained build agents—wrapping them into proper Windows Services is the difference between fire-and-forget and why-is-nobody-logged-in-after-the-reboot. Let’s explore modern wrappers (WinSW, Shawl) that replace the venerable NSSM, and we’ll teach the Satisfactory Dedicated Server to start, stop and update itself without human interaction.

Why run an executable as a Service on Windows Server 2025?

A service starts before any user logs on, reports its health to the operating system and can be automatically restarted if it crashes. In other words, the SCM is your best-paid intern who always shows up for the early shift.
For homelabs this pays off immediately: the power flickers, the UPS takes over, the server reboots and your game server is ready before the kettle finishes boiling. Plus, the process can run under an isolated account such as NT AUTHORITY\Local Service instead of your administrative credentials.

Windows Services: Self-Healing

When a Windows Service fails, it doesn’t have to drag the whole system down with it. With the right configuration, you can turn your services into self-healing entities—capable of restarting themselves, and if needed, rebooting the entire server to recover from persistent issues.

Windows Services support three levels of failure response and here are my default configurations

You can automate that easily with powershell and standardize your settings.

$serviceName = "YourServiceName"

sc.exe failure $serviceName reset= 86400 actions= restart/60000/restart/60000/reboot/60000
sc.exe failureflag $serviceName 1
sc.exe config $serviceName start= auto

Explanation:

• reset= 86400 → Resets failure count after 1 day
• actions= → First and second failures restart the service after 60 seconds; third triggers a reboot
• failureflag 1 → Enables failure actions
• start= auto → Ensures the service starts automatically on boot

And even add a custom reboot message to the event log

$serviceName = "YourServiceName"

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\$serviceName" `
  -Name "RebootMessage" -Value "Service failed repeatedly. System rebooting to recover." `
  -PropertyType String

I do use this in my Lab environments where uptime is more important than root-cause analysis.

What are the other options to configure a Service on Windows Server 2025?

There are multiple options and here are the most common ones I have been using and supported over the last years.

• NSSM—the “Non-Sucking Service Manager”; last release 2017. Stable, but abandoned.
• WinSW—actively maintained, XML configuration, log rotation; version 2.12 made available in 2023.
• Shawl—a single Rust binary, CLI-only, installable via Winget; version 1.7.0 shipped in January.
• Pure PowerShell—New-Service plus a home-grown watchdog. Works, but you maintain everything.

Why am I am using Shawl to create a Service on Windows Server 2025?

Keep it simple and easy to maintain is my focus for lab and also business projects. Shawl is maintained, has a simple command line interface and can be installed using Winget.

My biggest advantages:

• No Code Changes Required – Shawl wraps any executable (EXE, BAT, CMD, etc.) into a service without needing to modify the original code.
• Simple CLI Interface – create, install, and configure services with just a few command-line arguments
• Works Well on Windows Server 2025
• Self healing – Auto Restarts, Logging, custom working directories and delayed starts
• Winget – No Winget? No love!

How to run an executable as a service using Shawl?

This will be my example being used here:

SteamCMD lives in E:\SteamCMD
The executable FactoryServer.Exe is located in E:\SatisfactoryServer
Prerequisites for the have been fullfilled - list
Install Shawl to E:\Shawl\

We will start with installing the Shawl application using Winget. Once this has been completed you can use shawl as a command in your terminal session. If you want to check on how to configure the terminal application, please check my guide here.

winget install -e --id mtkennerly.shawl --location E:\Shawl\

Here’s the command to register the executable FactoryServer.exe as a Windows Server using Shawl:

E:\shawl.exe add --name "Satisfactory Dedicated Server" -- E:/SatisfactoryServer/FactoryServer.exe --restart

Shawl Command Flags Overview

Enable the service for autostart and initial start

sc config "Satisfactory Dedicated Server" start= auto
sc start "Satisfactory Dedicated Server"

This setup gives you a robust, self-healing, and log-friendly server service that’s perfect for unattended operation.

When you look at the commands above, I did a thing, that is important for me. Keep things clean and predicatable. By configuring Winget to install shawl to E:\ I now have the logfiles and information in one spot and this looks like this.

Conclusion

Using shawl and configuring Winget to use a specific volume, gave me a system that will automatically restart executables for me. This would normally require a specific configuration, but thanks to the wrapper by Matthew Kennerly, we can enable legacy applications with this functionality.

I used this to get a more resilent game server, so I don’t have to be called by the familiy and friends using it, but this will enable you to do the same for your homelab or business environment.

This also allows me to disable the autologon configured earlier in this guide to work around this temporarily.

Satisfactory Dedicated Server High CPU Utilization

If you are running version 1.1 of satisfactory and receiving high CPU utilization, please check this link and configure a new reliability port in your firewall / NAT configuration and your engine.ini. If you want to use port 45800 enter this in your ini:

[/Script/ReliableMessaging.ReliableMessagingTCPFactory]
PortRangeBegin=45800
PortRangeLength=512
ExternalPortRangeBegin=-1

References

NSSM description – https://nssm.cc/description
WinSW releases – https://github.com/winsw/winsw/releases
Shawl repository – https://github.com/mtkennerly/shawl
Satisfactory Wiki – https://satisfactory.wiki.gg/wiki/Dedicated_servers/Running_as_a_Service