hermes-windows-services

Answer "what runs as a service on this machine, why did one fail, and what does it depend on" on Windows: win_service_table lists every service with its state (Running, Stopped, Paused), its start mode (Auto, Manual, Disabled, with the delayed flag folded in as "Auto, delayed"), the pid it runs under, the account and binary it runs as, the dependency edges both ways, and what its exit code means - 1077 is one that has not tried to start since the last boot, 1053 one that did not answer in time, 1075 one whose dependency failed first, 2 one whose binary is gone. win_service_detail takes one service and gives what Windows does when it fails (the FailureActions blob decoded: restart the service, restart the computer, run a command, after how many seconds, and when the count resets), whether the registered binary is still on disk, and the Service Control Manager's own event-log record behind the failure - 7000 failed to start, 7009 a start request that timed out, 7024 a service-specific error, 7031 an unexpected end, 7045 an install. Use it for what died after the last update, for finding what an uninstalled program left registered, and for the dependency order before a restart. Read-only: nothing is started, stopped, reconfigured or deleted. The listing comes from one Get-CimInstance Win32_Service call because its property names and enum values do not change with the display language while sc.exe localizes both; dependencies and failure actions are read from the registry, because CIM's DependOnService property is never populated and the failure policy exists nowhere in CIM at all. The plugin declares no Python dependencies; there is no network call and no file write. Windows only. Disclosure - the tools report service names, display names, command lines, logon accounts and the event-log history to the model, and those reveal what the person has installed, what runs as their machine's system accounts, and the paths under C:\Program Files and C:\Users\<name>; treat the output like a Services window opened on their machine.

Yicheng-MarkToolsv0.1.0Updated 1 hour ago

About

hermes-windows-services

Answer "what runs as a service on this machine, why did one fail, and what does it depend
on" on Windows, from inside Hermes.

win_service_table({"nonzero_exit": True})
win_service_table({"state": "stopped", "start": "auto"})
win_service_detail({"name": "wuauserv"})

A Windows machine carries two to three hundred services, and when one of them is the reason
something does not work, the evidence is a number in a column nobody translates: the exit
code, the SCM event log behind it, and the failure policy nobody configured. These two tools
read all three and put them in words.

What the tools report

| Field | Where it comes from |
|---|---|
| state | Running, Stopped, Paused (CIM Win32_Service) |
| start | Boot, System, Auto, Manual, Disabled, with the delayed flag folded in as Auto, delayed |
| pid | The process running it, or null when it is not |
| exit_code | The number, in hex, with what it means: 1077 has not tried since the last boot, 1053 did not answer in time, 1075 waits on a dependency that failed first, 2 a binary that is gone |
| account, binary | The logon account and command line from the registration |
| depends_on, dependents | The dependency edges both ways, +-prefixed load-order groups spelled out |

win_service_detail adds what a listing has no room for: what Windows does when the service
fails (restart it, restart the computer, run a command, after how many seconds, and when the
count resets — the FailureActions blob out of the registry, decoded), whether the
registered binary is still on disk, and the Service Control Manager's own record from the
System event log: 7000 failed to start, 7009 a start request that timed out, 7024 a
service-specific error, 7031 an unexpected end, 7045 an install. Routine noise (7036
state changes, 7040 start-type changes) is deliberately not collected.

Read-only, and why it goes through PowerShell

Nothing is started, stopped, reconfigured or deleted: the tools query, and the schemas say
so.

The service listing comes from one Get-CimInstance Win32_Service call, whose property
names and enum values do not change with the display language — sc.exe query localizes
both. One child process (powershell.exe, hidden window, 90 s timeout) runs that call;
everything else — dependencies, the delayed flag, failure actions — is read straight from
HKLM\SYSTEM\CurrentControlSet\Services with winreg, no child process at all. The event
query is a second, per-detail PowerShell call that filters the System log by provider and
event id.

Two facts the hard way, both verified on Windows 11 (build 26300):

CIM's DependOnService property is never populated — a listing of 293 services
returned none, while the registry and sc qc both show them. Dependencies are read from
the registry's DependOnService value (MULTI_SZ, a + prefix names a load-order
group).
FailureActions is an undocumented binary value with the 32-bit
SERVICE_FAILURE_ACTIONS ABI: reset period, two string offsets, a count, an offset to
the action array, then type/delay pairs. Decoded here directly; wuauserv's blob
reads back as three "restart after 60 s" actions, which is what the Services snap-in
shows for it.

No network, no file writes, no elevation: everything these tools read is visible to a
normal user.

Layout

plugin.yaml                        manifest: tools, tags, the read-only disclosure
hermes_windows_services/
  tools.py                         the two tools: filtering, rows, notes
  svcquery.py                      the CIM call and the event query (PowerShell)
  svcreg.py                        dependencies, delayed start, failure actions (winreg)
  exitcodes.py                     exit-code and SCM-event words
  schemas.py                       the tools' parameter schemas
tests/test_unit.py                 every layer with fakes; no PowerShell, no registry
tests/test_live.py                 the real CIM, registry and event log on this machine

README from the reviewed commit 1d1027f; it updates when the author re-pins.

More by Yicheng-Mark

14 plugins by Yicheng-Mark in the catalog.

Yicheng-Markhermes-dpapi-secretsResolve Hermes environment variables at startup from a single secret file encrypted with the Windows Data Protection API, instead of keeping provider keys in plaintext in .env or auth.json. Config is secrets.dpapi.map, an ENV_VAR -> store-name mapping (bare names or dpapi:// names) plus an optional file path (default <HERMES_HOME>/secrets.dpapi). The file is one DPAPI blob keyed by the current Windows user profile, so it is unreadable by another Windows account and worthless off the machine; it is written by the bundled CLI (python -m hermes_dpapi_secrets set NAME, value read from a prompt or stdin, never from argv) and only read at runtime. Mapped names that are missing or empty are skipped with a warning; a file that is not ours, a blob this user cannot decrypt, or a payload that is not a flat string map is reported as an error with nothing injected. Disclosure - this source decrypts a file for every Hermes process that enables it: resolved values become environment variables of the Hermes process and its children, exactly like .env entries, so anything that can read that environment can see them. User-scope encryption only (the machine-wide flag is never used and is not exposed), and the at-rest protection is a bar for backups, cloud sync and dotfiles, not a boundary against code already running as the same user. Stdlib-only (ctypes): no Python dependencies, no subprocesses, no network calls, no self-update. Windows only. Applying fetched values stays the orchestrator's job; the plugin never writes os.environ itself. Disclosure — decrypts a DPAPI-encrypted secret file (default <HERMES_HOME>/secrets.dpapi) at startup for every Hermes process that enables it, and the resolved values become environment variables of Hermes and its child processes like `.env` entries; the encryption is per Windows user and protects backups, cloud sync and copied files, not against other code running as the same user. Local only: no network calls, no subprocesses.Communitytools Yicheng-Markhermes-wincredResolve Hermes environment variables from the current user's Windows Credential Manager at startup, instead of keeping provider keys in plaintext in .env or auth.json. Config is secrets.wincred.map, an ENV_VAR -> generic-credential-target mapping (bare names or wincred:// names); each value is read with CredReadW in the current user's vault and handed to the secret-source orchestrator, which applies it with the usual precedence, provenance and conflict rules. Values may be UTF-8 or UTF-16LE (cmdkey and the Credential UI write UTF-16); anything that does not decode to text, or that contains interior NULs, is skipped with a warning instead of being injected as a mangled key. Disclosure - this source reads your Windows Credential Manager: only the generic credentials named in the map, with no enumeration of the vault. Resolved values become environment variables of the Hermes process and its children, exactly like .env entries, so anything that can read that environment can see them. The package is read-only and stdlib-only (ctypes): it never creates, updates or deletes credentials, writes no files, starts no subprocesses, makes no network calls and does not self-update. Windows only. Credential Manager is user-scoped, so this raises the at-rest bar for backups, cloud sync and dotfiles; it is not a boundary against code already running as the same user. Applying fetched values stays the orchestrator's job; the plugin never writes os.environ itself. Disclosure — when enabled, reads only the Windows Credential Manager generic credentials named in secrets.wincred.map (no vault enumeration) and injects them as environment variables of the Hermes process and its children, exactly like .env entries; read-only, stdlib ctypes, no subprocesses, no network, no file writes; user-scoped at-rest protection, not a boundary against code already running as the same user.Communitytools Yicheng-Markhermes-windows-appsAnswer "what is installed on this Windows machine": the software inventory behind Apps & Features, swept straight from the four Uninstall registry keys (the machine's 64-bit and 32-bit views plus the user's), so a program is found even when the Settings page hides it - a per-user install that never shows on the machine page came from the user view on the writing machine. Each row carries version, publisher, size in MB, install date and which view it lives in; the same DisplayName in two views is a 32/64-bit dual install, marked instead of listed twice. Entries the publisher asked to hide (runtime packages, update rollups) are filtered out unless asked for. Details one program with every field its publisher wrote and a reading of the uninstall command (MSI product code, setup executable, appx, script) so the next step is known before anything is run; the install folder is checked against disk. Use it for "what did that installer actually register", for inventory before a cleanup, and for "which of the two installs does uninstalling remove". Read-only: registry keys are enumerated and uninstall strings are reported, never run; no network, no file writes, no elevation. The sweep is pure registry - 102 entries in seven milliseconds on the writing machine, the whole table in ten, no PowerShell, no WMI. The plugin declares no Python dependencies. Windows only. Disclosure - the tools report program names, versions, publishers, sizes, install folders and uninstall commands, and what is hidden from Apps & Features, to the model; treat the output like the machine's own Apps & Features page.Communitytools Yicheng-Markhermes-windows-devicesAnswer "which device on this Windows machine is unhappy, and what does it need" on Windows: win_device_table lists every present PnP device with its class (System, Net, HIDClass, Display), its status, its manufacturer, its stable device id, and its problem code in words - 28 is one with no driver installed, 10 one that cannot start, 43 one Windows stopped after it reported a failure, 22 one the person switched off on purpose and is not broken - filtering by name or id substring, by class, or to the devices that need attention; devices no longer plugged in are history, left out unless asked for. win_device_detail takes one device by id or name substring and adds the driver behind it from the signed-driver table - name, version, date, provider, signer, INF file, signed or not - or the absence of one, which for code 28 is the same fact said twice; a disabled device gets a note saying it is on purpose, not an alarm. Use it for the Device Manager yellow-mark question without opening Device Manager, for finding what an uninstalled program left behind, and for what changed after an update. Read-only: nothing is enabled, disabled, updated or reinstalled. Both answers come from CIM (Win32_PnPEntity and Win32_PnPSignedDriver, joined by device id), whose property names, enum values and ids do not change with the display language; the human-facing device names localize and are carried through as data, never parsed. The plugin declares no Python dependencies; there is no network call and no file write. Windows only. Disclosure — the tools report device names, manufacturers, device ids and driver versions to the model, and those reveal the machine's hardware inventory and what is plugged into it; treat the output like a Device Manager window opened on their machine.Communitytools

All 14 by Yicheng-Mark