donislawdev/BetterWindowsServices

Better Windows Services is services.msc rebuilt for people who administer Windows machines - a window and a command line over one engine. Ask the machine a question instead of scrolling eight hundred rows. See what a change will do before you press anything. And the part services.msc never had: freeze every service into a file, and a week later ask what changed.

⭐ If it found the service that was not supposed to be running, leave a star. That is how the next administrator finds out it exists.

What it can do

• Ask, instead of scroll - start:auto !status:running is what should be up and is not. One language, in the search box and in bws list --query, with the fields offered as you type.
• Show the plan before anything happens - every stop, start, restart and start type change is previewed with the services it takes down with it, and the preview is what runs.
• Tell you what drifted - bws snapshot create freezes the machine into a file, and bws snapshot diff says what changed since, configuration apart from what merely started or stopped.
• Stop a service that will not stop - it asks politely first and ends the process only if that fails, naming every other service that lives in it.
• Show what services.msc hides - who signed the binary and whether Windows trusts it, triggers, privileges, the security descriptor, the process and its memory. As columns, and as things to search on.
• Say when it could not read something - a field it could not read is reported as not read, never shown as empty. A snapshot taken without administrator rights says so inside the file.
• Fit into scripts - --json on every command, an exit code for every ending, and 5 when a diff finds drift.
• Run from one file, offline - no installer, no .NET to install, and it never talks to the internet. Reading needs no administrator rights. GPL-3.0.

A real session, on a Windows installed in Polish - the display names come from Windows, so they are in its language. Every plan is shown before anything happens, and the command line in it asks for exactly the same thing.

Grab the latest build from the Releases page:

Windows 10 1809 or Windows Server 2019 and later, 64-bit. Each archive unzips to a folder holding the executable, the licence and the notices for the borrowed code - run BetterWindowsServices.exe, or bws.exe from a terminal. No installer, nothing written to the registry, and no administrator rights needed to look. Changing anything needs an elevated session, and both halves say so instead of failing quietly - the window offers Restart as admin.

The executables carry an Authenticode signature with a timestamp, so Windows names the publisher rather than an unknown one. SmartScreen can still warn on a brand new build until enough people have run it - that reputation is earned over downloads and is not something a signature buys outright.

Every release publishes, beside each archive: a bill of materials naming everything inside it that somebody else wrote, a signed attestation of that document, and one file of SHA-256 sums. Run these in the folder you downloaded into. The first two need nothing at all. The last two need the GitHub CLI, and because the .sigstore.json beside each archive is passed to --bundle, they check it against what GitHub signed rather than by asking GitHub.

The first two match a whole line - the digest and the file name it is written against - rather than looking for the digest anywhere in the file. A sums file that lists your digest under somebody else's name would otherwise pass.

if (-not ((Get-Content SHA256SUMS) -match ('^' + (Get-FileHash BetterWindowsServices-win-x64.zip -Algorithm SHA256).Hash.ToLower() + '\s+\*?BetterWindowsServices-win-x64\.zip$'))) { throw 'BetterWindowsServices-win-x64.zip does not match SHA256SUMS' }
if (-not ((Get-Content SHA256SUMS) -match ('^' + (Get-FileHash bws-cli-win-x64.zip -Algorithm SHA256).Hash.ToLower() + '\s+\*?bws-cli-win-x64\.zip$'))) { throw 'bws-cli-win-x64.zip does not match SHA256SUMS' }
gh attestation verify BetterWindowsServices-win-x64.zip --repo donislawdev/BetterWindowsServices --predicate-type https://spdx.dev/Document/v2.3 --bundle BetterWindowsServices-win-x64.zip.sigstore.json
gh attestation verify bws-cli-win-x64.zip --repo donislawdev/BetterWindowsServices --predicate-type https://spdx.dev/Document/v2.3 --bundle bws-cli-win-x64.zip.sigstore.json

--predicate-type is not optional and leaving it out looks like a broken release. The tools ask for build provenance by default, and a signed archive deliberately has none: a person signed those bytes on their own machine with a card in a reader, and an attestation saying a workflow produced them would be a lie. What is attested is what is inside the archive. Without the flag one spelling answers "no attestation found" and another returns 404.

These four commands are not decoration: a workflow runs them, out of this file and unchanged, every time a release is published. If the command you are about to type has stopped working, that workflow is what turns red.

bws license --components answers the same question from inside the program, with no internet and nothing to download - what it carries, which version, under which licence.

Early release. Both halves do everything on this page, and an automated suite runs on every commit. What is not there yet is under Honest limits - most of it is the second half of the audit story: a stock Windows baseline, a change journal, and restoring from a snapshot.

One promise to hold it to: nothing changes without showing the plan first, and the preview is what runs. A preview that differs from what then happened is the worst bug this tool can have - report it.

In the window: start BetterWindowsServices.exe. It opens on a few numbers about this machine - what is running, what should have started and did not, what points at a file that is gone. Click one and its question lands in the search box as a query you can edit. Right-click a row, choose What stopping would do, and the plan appears: the steps, what comes down with them, a warning if one of them is something the machine needs, and the bws line that asks for the same thing. The button under it is named after what it will do - Stop Winmgmt - and runs exactly that plan, and afterwards the panel says what did not work and how to get back.

From the command line:

bws list --query "start:auto !status:running"     what should be up and is not
bws list --query "file:missing"                   services whose binary is gone
bws list --query "signed:no peruser:no"           unsigned, without the per-session copies
bws show Spooler                                  everything known about one entry
bws stop Winmgmt --dry-run --dependents           what stopping it would take down
bws kill Spooler --dry-run                        what ending its process would take with it
bws start-type Spooler manual --dry-run           what taking it off automatic would do
bws snapshot create before.json                   freeze the machine before a change
bws snapshot diff before.json --live --exit-code  what has changed since, 5 if the setup has

A preview is the plan, printed:

$ bws stop Winmgmt --dry-run --dependents
Plan: stop Winmgmt  (2 steps)
  1. stop  vmms      (would break otherwise)
  2. stop  Winmgmt   (asked for)

Warnings:
  - Stopping Winmgmt also stops one other entry: vmms
  - Winmgmt starts automatically, so it will be back after the next restart.

Run it without --dry-run and those are the steps, in that order, with the same reasons beside them. Every command speaks --json as well, and every ending has an exit code your script can branch on - the full list is in the reference below.

services.msc is a snap-in that has barely changed since Windows 2000, and administrators spend hours a week in it hitting the same walls:

• No search. The only navigation is jumping to the first letter of a display name.
• No filtering. There is no way to ask show me what is set to start automatically and is not running.
• One row at a time. Restarting twelve services is twelve right-clicks and twelve waits.
• "Stopping..." forever, with no way out except Task Manager and guessing the process.
• No history. Nobody knows who set that start type to Disabled, or when.
• Hidden data. The process, the triggers, the privileges, the security descriptor, who signed the binary - all of it needs sc.exe from memory, or the registry.
• No command line parity. sc.exe has a syntax from the nineties (sc config X start= auto, and the space after the equals sign is mandatory), and Get-Service does not show the account a service runs as, let alone its description.

The other tools each fix part of it. Process Hacker and System Informer show a rich list and can force a kill, and have no audit and no command line. sc.exe and PsService can do everything and tell you nothing. PowerShell's *-Service cmdlets are scriptable and shallow. Nobody combines a searchable list, a preview before every change, and a record of what changed over time - and the record is the reason to keep this on a machine after the first afternoon.

This is the part services.msc has never done.

A snapshot is the whole machine at one moment: every service and driver, with its start type, account, launch path and arguments, the hash and the signer of the file it runs, its dependencies and what depends on it, its triggers, its required privileges, its SID type and its security descriptor, plus the name of the machine and of the account that took it, and whether that account was an administrator. It is JSON with one field per line, so it goes into a repository and git diff reads it.

bws snapshot create before.json --note "before the patch"

Then change something, wait a week, or apply the patch. Ask what is different:

$ bws snapshot diff before.json --live --exit-code
Changed (2):
  Spooler  Print Spooler
    startType: Manual -> Automatic
    status: Stopped -> Running  (running state, not configuration)
  wlidsvc  Microsoft Account Sign-in Assistant
    status: Stopped -> Running  (running state, not configuration)

Added 0, removed 0, changed 2. Fields differing: 1 in configuration, 2 in running state.

Two things about that output are the point. Configuration and running state are reported apart, because two snapshots taken a day apart differ in what happens to be running and almost none of it is drift - the start type that changed is the line to read. And what could not be compared is listed, not hidden: a field one of the two snapshots never read, because that session had no rights to it, comes out as not compared under its entry, and the summary counts those entries, so a diff that says nothing changed means nothing changed in what both sides could see.

--exit-code ends with 5 when the configuration differs - an entry added or removed, or one set up differently - so a scheduled task can take a snapshot at deployment and page somebody the first night the machine drifts. A service that only stopped or started by itself is reported and does not count, and neither do the per-user copies Windows makes for each signed-in session: those are left out of the comparison and counted in a line of their own. Compare two files instead of a file and the machine to answer what did the Tuesday patch do, or why does staging differ from production - take one on each and diff them anywhere.

A snapshot describes the whole machine, down to every launch path and security descriptor, so file it accordingly. It is written with whatever permissions its directory already has, and the tool narrows nothing.

Every operation that writes builds a plan first, and the same plan serves five purposes: the preview, the cascade of dependent services, the refusal before you press anything, the command line that asks for the same thing, and the way back afterwards.

• The preview is the execution. --dry-run prints the steps in order, each with its reason - asked for, or would break otherwise. Without --dry-run those same steps run in that same order. There is no second code path for the real thing.
• What comes down with it is in the plan. The services that would break are steps of their own when you ask for them - --dependents on the command line, and in the window a button under the plan's sentence naming them - and a plan that would take down something the machine needs says so in its warnings.
• A refusal comes before the button. A driver, a service the manager will not accept a stop for, a process the system protects - refused when the plan is built, with the reason, not after a wait. The window greys the button and says why beside it.
• Force stop is two steps, and the second is conditional. bws kill asks the service to stop and ends its process only if that does not work. The preview names the process and every other service living in it, because ending a process takes all of them - and those are asked to stop only when the service itself did not, so a polite stop that works leaves them running. --restart brings them back, --force skips the polite step - and the preview shows one step instead of two, so the difference is visible before anything happens.
• Force stop never pulls a process out from under a running service. While services that depend on it, or on anything sharing its process, are running outside the plan, bws kill refuses and names them. --dependents stops the first kind as part of the plan, and a dependant that will not stop holds the process ending back. --force does not go with --dependents, because skipping the polite step would skip theirs too.
• Force stop says what Windows does once the process is gone. A process Windows marks critical, or a service whose recovery actions restart the computer, is refused - ending it takes the whole machine down. A service Windows starts again by itself, or one whose recovery runs a program, is named in the preview, because the stop may not last. Just before the process is ended the tool looks at it once more, and ends nothing if a service moved into it or started depending on it since the preview.
• Afterwards, the way back. A report ends with what did not work and the commands that put things back - and the window offers Copy all over them.
• A start type change moves nothing on its own. It changes what happens at the next boot, leaves the service as it was, and the report says so. The one exception is a stop you ask for in the same plan - --stop beside disabled, or Also stop it in the window.

The window and the command line are two clients of one engine. The plan the window shows is the plan bws would print, and the window prints the bws line beside it so you can take it to a script.

One language, in the search box and in bws list --query. A bare word searches the name, the display name, the account and the launch path. A field narrows it:

Text fields match contains by default, name:=spooler is exact, name:spool* takes wildcards, and name:/^Sql.*/ is a regular expression. ! negates a term, a comma is or inside a field, and quotes protect anything with spaces or colons: account:"NT SERVICE\McmSvc". The same field written twice means either, the way two ticked filters do - except two bounds on a number, which narrow: pid:>1000 pid:<2000. Every field accepts none, any and ? - the last one finds the entries where the tool could not read that field, or has not read it, which is a question services.msc cannot even ask.

A publisher is only proven by a trusted signature. Beside any other verdict the name is what the certificate claims - a Microsoft file changed after it was signed still carries a Microsoft certificate - so the window and bws show it as (not verified), and publisher: counts such an entry as unsure rather than matching it or leaving it out: !publisher:microsoft keeps the changed file and says so.

A mistyped value is an error with the nearest valid value suggested, never an empty result that looks like an answer. And a query that would narrow nothing is refused on the command line, so a script does not silently operate on the whole machine because of a typo.

A tool that quietly fails to cover something is worse than one that says what it cannot do.

Not built yet - the second half of the audit story:

• Snapshots are on the command line only. The window shows, searches and changes, and it does not take or compare snapshots. Use bws snapshot beside it.
• No stock Windows baseline. The opening screen has a place for how many of these are not from a clean install and says it is not counted yet rather than showing a number it cannot stand behind.
• No change journal. Who changed a start type, and when, is not read from the event log yet. A snapshot taken at deployment and a diff against the machine answers what changed, not who.
• No restore from a snapshot. A diff tells you what drifted, and putting it back is by hand or by script from the commands the diff shows you.
• No creating, deleting or repointing a service. The launch path is read and reported, and it is not edited.
• No recovery actions. Not read, not shown, not searchable.

By design:

• Local machine only. Remote management is not in this version. To compare two machines, take a snapshot on each and diff the two files.
• Windows only, 64-bit only, Windows 10 1809 or Windows Server 2019 and later.
• Operations on drivers are refused rather than attempted, because stopping a kernel driver is often not reversible without a restart.
• The tool does not raise its own privileges. When the manager refuses, it says so and ends with exit code 3. The window offers to restart itself as administrator, and does nothing else about it.
• The window is dark, and it stays dark whatever Windows is set to - including a high contrast theme. Checked rather than assumed: it keeps its own colours and stays readable, and it does not follow that setting.
• Certificate revocation is not checked. It would need to reach the network, and this tool never does. So Trusted means the chain was valid on this machine, not that nobody revoked the certificate since.
• The window unpacks part of the Windows user interface framework before it starts. As one file it carries a few native libraries that Windows can only load from disk. Without administrator rights it writes them, on the first start of each version, to a .net folder under the account's temporary folder and loads them from there. With administrator rights it uses ProgramData\BetterWindowsServices on the Windows drive instead - a folder it creates so that only administrators can change it, and checks at every start. If that folder cannot be created, or others can change it, the window does not start and says which folder and what to do. Moving there means an elevated window starts itself a second time, which takes a fraction of a second, and each version leaves its libraries there (about 8 MB) until somebody deletes the folder. The command line carries no such libraries and unpacks nothing.
• An elevated session names the .NET settings it inherits rather than refusing them. A profiler, a trace or dump switch, or a diagnostic port set in the environment cannot be switched off from inside a .NET program, so with administrator rights both halves list any they find. Startup hooks are switched off outright.

Things Windows does that this tool reports as they are:

• For a service hosted inside svchost, the launch path names the host, so the file is there and who signed it both say less than they do for a service with a process of its own.
• Where a file carries both its own signature and an entry in a Windows catalogue and the two name different signers, the publisher shown is the one inside the file - the one that stays the same when the file is looked at on another machine, and it can differ from what PowerShell reports.
• Without administrator rights the manager lists fewer entries and refuses more of what it lists. Both halves say so at the top, and a snapshot records it, because comparing an elevated snapshot against one taken without rights would otherwise report entries as removed that nobody removed.

Measured, so you know what to expect - on one machine with 810 services, and your figures will differ: bws list reads them in about a quarter of a second, the window shows the list in about eight tenths, and the window uses about 100 MB, half of which is the Windows user interface framework before any of this tool's own code runs. The command line over the same machine uses about 16 MB.

This tool does what an administrator does with services, and some of that is what security software watches for: it stops and starts services, it can end the process behind one, and it reads every service's security descriptor and required privileges. An EDR that flags a process ending svchost.exe is doing its job, and a forced stop here can look exactly like that.

What it does not do, so you can check the claim: it injects nothing into any process, it packs or obfuscates nothing, it installs nothing and leaves nothing running, and it opens no network connection. It is open source under GPL-3.0 and you can build both executables yourself from this repository.

If your policy needs an exclusion, exclude the two executables by file rather than a folder, and prefer the command line on a server - it is the smaller of the two and does everything the window does. The one thing worth treating with the same care as the tool itself is a snapshot file: it describes the whole machine.

• Windows 10 version 1809 or later, or Windows Server 2019 or later, 64-bit.
• Nothing to install. Both executables carry their own .NET runtime.
• Administrator rights to change anything. Reading, searching, snapshots and diffs work without, with fewer entries visible and the tool saying so.

The window keeps one file of its own, the layout you left the list in, under %APPDATA%\BetterWindowsServices. A window started as administrator under User Account Control reads that file and writes nothing there, because programs in your account that run without administrator rights can change where that folder is and what is in it - arrange the columns in an ordinary window to keep them. A snapshot goes where you tell bws snapshot create to put it, and into the current directory when you do not.

.NET 10 SDK, on Windows.

git clone https://github.com/donislawdev/BetterWindowsServices
cd BetterWindowsServices
dotnet build BetterWindowsServices.slnx -c Release
dotnet test BetterWindowsServices.slnx -c Release

Some tests read the real service control manager of the machine they run on and compare what this tool says against what sc.exe says. They are read-only. The single-file executables the releases carry are the two publishes below, each one file with the runtime inside:

dotnet publish src/Bws.Cli/Bws.Cli.csproj -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true
dotnet publish src/Bws.Gui/Bws.Gui.csproj -c Release -r win-x64 --self-contained true -p:PublishSingleFile=true

They land as bws.exe and BetterWindowsServices.exe under each project's bin/Release/.../win-x64/publish/. The .pdb files beside them are debugging symbols, and nothing needs them to run.

The short version of bws --help, which is the authoritative one and is longer.

bws list [--query TEXT] [--signatures] [--memory] [--required-by] [--follow-network] [--json] [--timing]
bws show NAME [--full] [--follow-network] [--json] [--timing]
bws stop|start|restart NAME [--dry-run] [--dependents] [--timeout SECONDS] [--json] [--timing]
bws kill NAME [--force] [--restart] [--dry-run] [--dependents] [--timeout SECONDS] [--json] [--timing]
bws start-type NAME automatic|delayed|manual|disabled [--stop] [--dry-run] [--json] [--timing]
bws snapshot create [FILE] [--note TEXT] [--follow-network] [--force] [--json] [--timing]
bws snapshot diff EARLIER LATER [--exit-code] [--json] [--timing]
bws snapshot diff EARLIER --live [--exit-code] [--json] [--timing]
bws license [--components]
bws --help
bws --version

Data goes to standard output and everything else to standard error, so bws list --json | jq works and a warning never lands in your JSON.

Every JSON document is plain ASCII: a letter outside it, a Polish one for instance, is written as a six character escape that every JSON reader turns back into the letter. That keeps bws list --json > file.json a valid UTF-8 file and | ConvertFrom-Json right whatever code page the console is set to. In the text a person reads, a character that would move the terminal rather than print - a tab, a line break, an escape sequence, a direction override - is shown as its code point, <U+001B>, so a snapshot from another machine cannot rewrite your screen.

-- ends the switches, so a service whose name begins with a dash can still be named: bws show -- -odd. The command lines this tool hands you - in the window, and after a run to put things back - are written for PowerShell. A name with a space goes in double quotes, which cmd reads the same way, and a name PowerShell would expand inside them, MSSQL$SQLEXPRESS for one, goes in single quotes. In a batch file with delayed expansion turned on, cmd eats the ! of a query such as "start:auto !status:running" without a word - write it ^! there.

Ctrl+C has three levels, each saying what the next one costs: the first stops going forward and still puts back what was taken, the second leaves things as they are and still prints the report, the third ends the process.

Closing the console window counts as the first Ctrl+C. Windows gives a program five seconds after that, and in them this one stops going forward and puts back what it took down - a request already handed to Windows is carried out either way. Signing out and shutting down end the program without any warning it could act on, and a dropped remote session may too, so run a long plan where the session will last.

BetterWindowsServices.exe, one argument it knows: --catalogue opens a developer's sheet that shows every component of the window in every state, and reads nothing from your machine.

Three lists on the switch above the search box - Services, Drivers, All - each saying how big it is. The search box takes the query language and suggests as you type - Tab or Enter writes the highlighted word. The filter buttons write into the box. Columns chooses what the list shows, a right-click on a column heading narrows the list to that value or puts the column away, and the layout you leave is the layout it opens in - unless the file holding it is one the window cannot use, from a newer version or held by another program, which it then says, leaves alone and saves nothing over. A row's menu previews every operation before offering it, and copies the name or everything about the entry, display name and description included. Export... writes the rows on screen, in the columns you have on and the order you sorted them into, to a CSV file separated the way your Windows region settings separate lists, so a double click opens it in columns. Ctrl+C over the list copies everything about the chosen entry. Escape backs out of the innermost thing first. Donate, at the right end of the row above the search box, opens the project's support page in your browser - and in a window running as administrator it asks the desktop to open it, so the browser does not get those rights.

sc query and Get-Service tell you what is running. services.msc lets you change it, one row at a time, with no way to ask a question and no record afterwards. This tool asks the question (start:auto !status:running), shows you the plan before it acts, and keeps a snapshot you can diff a week later. Where it disagrees with sc.exe about a service, that is a bug - part of the test suite runs both and compares them entry by entry.

Never. No telemetry, no update check, no crash reporting, no account, no client of anything. The one time it can touch a network at all is when a service's launch path points at another machine's share and you pass --follow-network to let it look there - off by default, and the help says why. The Donate button in the window hands one address to your browser when you press it, and your browser is what connects.

To look, no. To change, yes. Without them the manager shows fewer entries and refuses more, and both halves say so at the top rather than pretending the list is the whole machine. The window offers Restart as admin. It never elevates itself.

Yes to both. GPL-3.0, no strings attached. A snapshot you take is your file.

Not by itself. Nothing is changed without a plan you have seen, drivers are refused, and a plan that would take down something the machine needs says so. What it cannot protect you from is carrying out a plan you did not read. The list of services the machine needs is a starter list of seven - the two halves of RPC, the account manager, key isolation, the session manager and plug and play - and Remote Desktop is not on it, so over a remote session, read the plan.

No. Better Windows Services is an independent open source project and is not affiliated with, endorsed by or sponsored by Microsoft. Windows is a trademark of the Microsoft group of companies.

Not yet, and it is the next thing. A change journal read from the event log, a stock Windows baseline per build, and restoring configuration from a snapshot with a dry run and a checkbox per item are the plan. Until then a snapshot at deployment and a diff against the machine answer what changed, which is most of the question.

Working end to end: the window and the command line over the same engine, the query language, plans with preview, cascade, refusal and the way back, stop, start, restart, force stop, force restart and start type, snapshots and diffs between files and against the live machine, signatures, privileges, security descriptors, triggers, memory, per-user folding, keyboard and screen reader in the window, CSV export, JSON and exit codes on the command line.

Not there yet: everything under Honest limits, above all the stock baseline, the change journal and restore from a snapshot.

Found a problem, or a service this tool reports differently from sc.exe? The issue tracker is open, and a diff between the two is the most useful thing you can paste into it.

The most useful contribution is evidence: a machine where the tool and sc.exe disagree, a service whose plan was wrong, a snapshot diff that reported a change nobody made. Open an issue with the output. CONTRIBUTING.md says what a change has to satisfy before it can go in, what the test suite enforces, and what is not accepted. Behaviour here follows the Code of Conduct, and security problems go through SECURITY.md rather than the issue tracker.

Copyright (C) 2026 DonislawDev. The project is built with an AI-assisted workflow.

Released under the GNU General Public License, version 3 - see LICENSE. Free, no account, no telemetry, and it never talks to the internet. Other people's code is redistributed with the program, and what it is and what its licences require is written down in THIRD-PARTY-NOTICES.md.

Better Windows Services is not affiliated with, endorsed by or sponsored by Microsoft. Windows is a trademark of the Microsoft group of companies, and the name is used here only to say what the tool manages.

If it saved you an afternoon, donislawdev.com/support is where that can be said in a way that keeps the next afternoon funded - the Donate button in the window opens that page in your browser. The program itself opens no socket - your browser is what connects.