Search your Windows services, preview every change, and see what drifted since yesterday

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.

Download for Windows See the code on GitHub

Free and open source, GPL-3.0
One file, or an installer
No administrator rights to look
Never talks to the internet

The window with five entries picked and the plan for starting them shown over the list: five steps, a note that two of them are already in that state, a bws start line for each entry, and the Start 5 entries button. — Entries picked, a plan shown before anything happens, and the `bws` line that asks for exactly the same thing. The program speaks English - the window reads a language file placed beside it, so a translation is possible without a rebuild.

Half a minute with it

What it looks like in use

A real session, on a Windows installed in Polish - the display names come from Windows, so they are in its language. The window itself speaks English.

Four entries picked and the plan for starting them, a force restart of the Local Session Manager whose plan warns that the machine does not work without it and asks for its name before the button works, the questions to start from under the empty search box, and the Print Spooler found by typing part of its name and started. — Four entries picked and the plan for starting them, a force restart that asks for the name of a service the machine needs, the questions under an empty search box, and the Print Spooler found by typing and started.

The opening screen: three cards of numbers about this machine - services running, services set to start automatically that did not come up, and services set to start automatically whose file is gone - and a Show the list button. — It opens on a few numbers about this machine. Each one is a question - click it and the question goes into the search box.

The list of services with the three lists above the search box, an empty search box, the filter buttons open in rows for state, startup type, signature, disagreements and triggers, and the list below. — The filter buttons write into the search box, so what you clicked is a query you can read and edit.

Why this exists

`services.msc` has barely changed since Windows 2000

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, and the Get-Service that comes with Windows, in Windows PowerShell 5.1, does not show the account a service runs as, let alone its description. PowerShell 7 shows both, and it is installed separately.

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.

The full comparison

What it does

A window and a command line over one engine

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, and who changed it

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. bws history says who changed a start type and who installed a service, out of the System log. The window does all three under Audit....

Fix a common problem in one press

The Tools tab and bws tool fix restart the service behind a printer that does not print, sound that is gone or a search that is stuck, together with what depends on it, through the same plan as everything else.

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

Unzip and run, or install it for the whole machine. No .NET to install, and it never talks to the internet. Reading needs no administrator rights. GPL-3.0.

The part services.msc never did

What changed since yesterday

A snapshot is the whole machine at one moment - every service and driver, with its start type, account, launch path, the hash and the signer of its file, its dependencies, triggers, privileges and security descriptor. It is JSON with one field per line, so it goes into a repository and git diff reads it.

$ 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.

Configuration and running state are reported apart. 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.
What could not be compared is listed, not hidden. A field one snapshot never read comes out as not compared, 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, so a scheduled task can take a snapshot at deployment and page somebody the first night the machine drifts.
Two machines, two files. Take a snapshot on staging and one on production, and diff them anywhere.

How snapshots and drift work

Nothing happens without a plan

The preview is the execution

Every operation that writes builds a plan first, and the same plan is 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.

$ 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. 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, 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. 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, naming every other service living in it.

When a service will not stop

Two minutes with it

From the command line

The same engine as the window, for scripts, scheduled tasks and CI. 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.

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
bws history Spooler                               who changed its start type, and when
bws tool fix printer --dry-run                    what the quick fix for a stuck printer would do

Every command, switch and exit code

Get it

Unzip and run, or install

Windows 10 1809 or Windows Server 2019 and later, 64-bit. The archives need no installer and write nothing to the registry, and looking needs no administrator rights. Changing anything needs an elevated session, and both halves say so instead of failing quietly - the window offers Restart as admin.

File	What it is
`BetterWindowsServices-win-x64.zip`	The window, one self-contained executable - no .NET to install
`bws-cli-win-x64.zip`	The command line, one self-contained executable, for scripts and CI
`BetterWindowsServices-win-x64.msi`	The installer: both programs for every account on the machine, the window in the Start menu and `bws` on the PATH

The executables carry an Authenticode signature, so Windows names the publisher instead of warning about an unknown one.

Download for Windows Requirements and building from source