Skip to main content

hermes-windows-devices

❖ Communityv0.1.0★ 0

Tools · by Yicheng-Mark · added

Answer "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.

Open in Hermes Desktop
hermes plugins install hermes-windows-devices
Repository ↗Reviewed source @ 125c039 ↗Documentation ↗

What it adds

Tools 2

win_device_tablewin_device_detail

README

From the reviewed commit 125c039 ↗; it updates when the author re-pins.

hermes-windows-devices

Answer "which device on this machine is unhappy, and what does it need" on Windows, from inside Hermes.

win_device_table({"broken_only": True})
win_device_table({"class": "net"})
win_device_detail({"name": "LENOVO"})

The Device Manager question, answered without Device Manager: a yellow mark on a device is a number nobody translates, and these two tools translate it — 28 is no driver installed, 10 cannot start, 43 Windows stopped it after it reported a failure, 22 is switched off on purpose (not broken), 1 is configured incorrectly.

What the tools report

Field Where it comes from
name, manufacturer The device as Windows names it (localized, carried through, never parsed)
class PNPClass: System, Net, HIDClass, Display, Camera, ...
status, problem Status (OK/Error/Degraded) and the problem code with its meaning
device_id The stable id, e.g. PCI\VEN_8086&DEV_2723&... — the match key for detail
present vs historical Devices not plugged in any more are left out unless asked for

win_device_detail adds the driver behind the device — name, version, date, provider, signer, INF file, and whether it is signed — or the absence of one, which for problem code 28 is the same fact said twice. A disabled device (code 22) gets a note saying it is on purpose, not an alarm.

Read-only, and why it goes through CIM

Nothing is enabled, disabled, updated or reinstalled: the tools query, and the schemas say so.

Both answers come from CIM — Win32_PnPEntity for the tree (235 devices in 1.7 s on this machine, unelevated) and Win32_PnPSignedDriver for the driver table (239 rows, 2.2 s, joined by device id). Property names, enum values and ids do not change with the display language; the human-facing Name/Manufacturer localize, but they are data carried through, never parsed. One child process per query (powershell.exe, hidden window, 90 s timeout); no registry walk, no SetupAPI, no network, no file writes.

Layout

plugin.yaml                       manifest: tools, tags, the read-only disclosure
hermes_windows_devices/
  tools.py                        the two tools: filtering, rows, notes
  devquery.py                     the two CIM calls (PowerShell, ConvertTo-Json)
  codes.py                        problem-code words
  schemas.py                      the tools' parameter schemas
tests/test_unit.py                the tools over faked CIM answers; no PowerShell
tests/test_live.py                the real device tree and driver table on this machine

Disclosure

More by Yicheng-Mark

All 10 plugins by Yicheng-Mark →
hermes-dpapi-secrets❖ Community★ 0

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

Tools
hermes-wincred❖ Community★ 0

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

Tools
hermes-windows-eventlog❖ Community★ 0

Answer "why did this process die" on Windows: three read-only tools over the Windows Event Log. win_crash_events reads Application Error / Application Hang / Windows Error Reporting / .NET Runtime records for a time window, decodes the exception code (0xC0000005 -> ACCESS_VIOLATION and the other codes a debugger would name), reports the faulting module, its path and the fault offset, and groups repeated crashes by app and signature. Records are classified by provider as well as by event id, so unrelated providers that reuse ids 1000 and 1001 for informational events are not reported as crashes. win_shutdown_events reads the System log for Kernel-Power 41 unexpected restarts, bugchecks decoded to names (0x9F -> DRIVER_POWER_STATE_FAILURE, accepting the decimal form some providers emit), EventLog 6008 dirty shutdowns, 1074 operator-initiated restarts with the process and comment, and the 6005/6006/12/13 start and stop markers. win_eventlog_query is the general case: any channel, filtered by event ids, levels, an exact provider name or a payload substring, returning structured records instead of raw XML. Queries read newest-first and stop at the window start or at a 5000-record scan cap; a call returns at most 200 records and marks truncated payload text. Channel names, provider names and numeric filters are validated before anything is interpolated into the query.

Tools
hermes-windows-ops❖ Community★ 0

Windows and WSL triage skills for Hermes: processes that survive a quit (orphaned stdio MCP trees, lingering python/uv/node children), WSL-to-Windows interop where an argument reaches cmd.exe as shell syntax, config and encoding traps (UTF-8 BOM, legacy console code pages), and long-path or reserved-name errors. One skill plus a copy-paste command reference; the process, argv and job-object failure modes are pinned to reports #131561, #132069 and #61059 and re-verified against current main.

Tools
hermes-windows-ports❖ Community★ 0

Answer "who holds this port" on Windows. win_port_owners reads the TCP and UDP owner tables through iphlpapi (the same rows netstat -ano prints, with the owning PID attached) and resolves each PID to its image name and path, returning one structured record per endpoint. Filters cover one port, several ports, a process substring, the protocol (tcp, udp or both), the TCP state (listen, established, any state name, or all; UDP rows report bound) and IPv6 inclusion, with a record cap and a per-process summary of the rows returned. Built for the failure mode that stalls agents on Windows: a gateway, backend or bridge that cannot bind, where the error names a port but not the process holding it. netstat -ano prints columns, not fields, and its PID still needs a second command (tasklist, or a PowerShell round-trip) to become an image name; this tool is one in-process call instead of a shell parse plus a join, with no child process and no dependency on PowerShell being installed or allowed by execution policy. A protected process whose image cannot be queried keeps its PID and reports a null process name instead of failing the call.

Tools
hermes-windows-process❖ Community★ 0

Answer "what is still running, and who started it" on Windows: win_process_table reads the process table (PID, parent PID, image name) and adds each process's image path and creation time, then marks every row with whether its recorded parent is still the process that spawned it. Windows stores a parent PID rather than a handle, so a child that outlived its parent points at a PID that is either unused or reused by a newer process; a parent that started after its child cannot have spawned it, so both cases are reported as gone or reused instead of a plausible but wrong parent name. Filters cover one PID, several PIDs, a name or path substring, a parent PID, and an orphans-only view of what outlived its parent, with a result cap and an option to leave out Windows session processes. Use it for leftover gateway/backend/server children after a quit, for telling thirty python.exe rows apart by start time, and for checking whether a process started before or after the thing being debugged. Read-only: processes are opened with PROCESS_QUERY_LIMITED_INFORMATION for QueryFullProcessImageName and GetProcessTimes only - no memory reads (command lines are deliberately out of scope), no handle duplication, no writes, no child processes. Stdlib-only (ctypes): no Python dependencies, no network calls, no file writes, no self-update. Windows only.

Tools

← Back to the catalog · catalog built Nov 3, 2026