davinci-resolve-mcp 2.218.0 → 2.218.2

package/CHANGELOG.md

@@ -2,6 +2,104 @@
 
 Release history for the DaVinci Resolve MCP Server. The latest release is summarized in the root README; older entries live here to keep the README focused.
 
+## What's New in v2.218.2 — the AddTransition null-duration boundary, measured
+
+Measured by @legionsound on Studio 21.1.0.14 (#209), recorded here; no behavior
+changed.
+
+### Documentation
+
+- **An explicit `"duration": null` is not a special case.** v2.218.0 shipped
+  `add_transition` forwarding an explicit null verbatim rather than dropping
+  the key, on the principle that inventing a default would misreport what the
+  server asked Resolve for — but only the 24-frame case had been measured, so
+  whether Resolve read a null as "automatic" or refused it was an open
+  question raised on #209. It is now answered: on fresh timelines with the same
+  handled red/blue fixture, **omitting the key and passing `duration: null`
+  behaved identically**, each creating a transition of 8 frames spanning 67–75
+  around a cut at 71.
+- So the shipped behavior is correct as written, and the ledger now says why a
+  future wrapper must **not** strip an explicit null to route around a
+  refusal — there is no refusal to route around. `resolve_control api_truth
+  "AddTransition"` carries this, alongside the standing 21.1 gap it does not
+  close: there is still no accessor for an existing transition's type,
+  alignment or duration beyond its name and frame range, and no clone verb.
+- The 8 frames is recorded as **what that build chose for that fixture, not a
+  documented default**, and these two cases were creation and readback only —
+  they were not rendered, unlike the 24-frame fixture behind v2.218.0.
+
+### Validation
+
+- Ledger and generated `docs/reference/api-limitations.md` regenerated; full
+  suite green. No code path changed, so no live Resolve run was required here —
+  and this machine is Studio 19.1.3.7, below the 21.1 floor, where the method
+  refuses by design. The measurement is @legionsound's on 21.1.0.14.
+
+## What's New in v2.218.1 — Windows 11 process detection survives the removal of WMIC
+
+Reported by @Nikibakht (#210), verified on Windows 11 Pro build 26200.
+
+### Fixed
+
+- **Every tool refused with `RESOLVE_NOT_RUNNING` on Windows 11 build 26200+,
+  while Resolve was running in front of the user.** Process detection read the
+  running Resolve's command line through `wmic`, which **Microsoft removed in
+  build 26200** — it is neither on `PATH` nor at `C:\Windows\System32\wbem`.
+  Spawning it raised `FileNotFoundError`, the read returned `None`, and `None`
+  correctly means "cannot determine whether Resolve is running", so the server
+  refused to act and declined to launch. The detection logic was right; the
+  reader it depended on had ceased to exist.
+- Windows now tries a chain of readers — `wmic`, then Windows PowerShell's
+  `Get-CimInstance Win32_Process`, then `pwsh` — and uses the first that
+  answers. `None` is returned only when **no** reader ran; a reader that ran
+  and found nothing still returns an empty list, which is a different answer.
+  Machines that still have WMIC are unaffected, and keeping it first costs
+  nothing, because a missing binary fails instantly rather than burning the
+  ten-second timeout.
+
+### Changed
+
+- The PowerShell reader returns **`ProcessId`, `Name`, `ExecutablePath` and
+  `CommandLine`**, not the command line alone, so Windows now fills the same
+  two-column process table as macOS and Linux. The columns fail independently,
+  and @Nikibakht measured how: querying as an unelevated user on build 26200, a
+  process the caller cannot fully read still returns its row with `ProcessId`
+  and `Name` populated and `CommandLine` NULL — the *column* is
+  access-restricted, not the row. Reading only the command line would turn
+  such an instance into no row at all: an empty list, which does not mean
+  "cannot tell", it means "nothing is running", and that is the answer that
+  launches a second Resolve on top of a live one.
+- `Name` is in that query because of the same measurement. It showed `Name`
+  surviving the access restriction; it did **not** show `ExecutablePath`
+  surviving it, and for a protected process that field is commonly empty too,
+  so the executable column falls back to the bare process name — which the
+  existing match patterns already accept. An instance is counted on either
+  column, and the mode is reported as unknown rather than guessed when the
+  argument vector is unreadable, since `-nogui` is only ever visible there.
+  Windows rows also carry real pids instead of the synthetic negative ones the
+  WMIC branch invents.
+
+### Validation
+
+- Full suite green: 3,446 passed, 1 skipped. Ten new tests cover the reader chain: a machine with no WMIC, `-nogui`
+  surviving the new reader, an unreadable command line still counting as an
+  instance, a row where only the process name survives, WMIC still winning
+  where it exists, an empty answer ending the chain rather than falling
+  through, a broken reader falling through, no reader at all staying
+  undeterminable, and the two parsing edges (a command line containing tabs, a
+  non-numeric pid).
+- **Not verified on Windows hardware by this project — there is none here.**
+  The WMIC absence, the `FileNotFoundError` it raises inside the server's own
+  venv, and the access-restricted row shape were all measured by @Nikibakht on
+  Windows 11 Pro build 26200. The local half is the unit coverage above, run
+  against a faked process spawn.
+- One thing remains **untested by anyone**: an actual Resolve running elevated
+  or under a different Windows account. The reporter runs it as the same
+  unelevated user and said so rather than guessing; the access-restricted row
+  shape above is a proxy measured on other processes in that same access
+  class. The fallback is written so that it costs nothing if that case never
+  arises.
+
 ## What's New in v2.218.0 — native Resolve 21.1 transition creation
 
 Contributed by @legionsound (#209), live-validated on Studio 21.1.0.14.

package/README.md

@@ -2,7 +2,7 @@
 
 English | [简体中文](README.zh-CN.md)
 
-[![Version](https://img.shields.io/badge/version-2.218.0-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-2.218.2-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
 [![npm](https://img.shields.io/npm/v/davinci-resolve-mcp.svg?label=npm&color=CB3837)](https://www.npmjs.com/package/davinci-resolve-mcp)
 [![API Coverage](https://img.shields.io/badge/API%20Coverage-100%25-brightgreen.svg)](docs/reference/api-coverage.md)
 [![Tools](https://img.shields.io/badge/MCP%20Tools-36%20(368%20full)-blue.svg)](#server-modes)

package/README.zh-CN.md

@@ -2,7 +2,7 @@
 
 [English](README.md) | 简体中文
 
-[![Version](https://img.shields.io/badge/version-2.218.0-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
+[![Version](https://img.shields.io/badge/version-2.218.2-blue.svg)](https://github.com/samuelgursky/davinci-resolve-mcp/releases)
 [![npm](https://img.shields.io/npm/v/davinci-resolve-mcp.svg?label=npm&color=CB3837)](https://www.npmjs.com/package/davinci-resolve-mcp)
 [![API Coverage](https://img.shields.io/badge/API%20Coverage-100%25-brightgreen.svg)](docs/reference/api-coverage.md)
 [![Tools](https://img.shields.io/badge/MCP%20Tools-36%20(368%20full)-blue.svg)](#服务器模式)
@@ -12,7 +12,7 @@
 [![Python](https://img.shields.io/badge/python-3.10+-green.svg)](https://www.python.org/downloads/)
 [![License](https://img.shields.io/badge/license-MIT-blue.svg)](https://opensource.org/licenses/MIT)
 
-> 本翻译对应 v2.218.0 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
+> 本翻译对应 v2.218.2 版 README。如与英文原版有出入，以 [英文原版](README.md) 为准。
 
 一个 Model Context Protocol (MCP) 服务器，让 AI 助手通过官方脚本 API 控制 DaVinci Resolve Studio（达芬奇）。它提供完整的 API 覆盖，外加带护栏的工作流助手，涵盖剪辑、媒体池整理、渲染设置、审阅标记、调色、Fusion、Fairlight、项目生命周期任务、扩展开发，以及不碰源媒体的媒体分析。
 

package/docs/reference/api-limitations.md

@@ -82,7 +82,7 @@ equivalent, blocking full automation.
 ### Transition create / copy / clone
 
 - **Object:** `Timeline / TimelineItem`
-- **Behavior:** CREATION IS FIXED IN 21.1, READBACK IS NOT. Reported by @billcarroll (PR #197) from an attribute probe on Studio 21.1.0.14 (2026-09-08; not reproduced here, no 21.1 install): TimelineItem.AddTransition resolves to a <BlackmagicFusion.PyFunctionCall object>, not None. Its stub signature is AddTransition(transitionOptions) -> TimelineItem | None, where transitionOptions carries type (e.g. 'Cross Dissolve'), category ('simple'|'fusion'|'ofx'|'audio'), position ('start'|'end'), alignment ('left'|'center'|'right') and an optional duration in frames. That original probe did not invoke the method. UPDATE, contributor-validated by @legionsound on Studio 21.1.0.14, macOS, 2026-09-09 (not reproduced by the maintainer on 19.1.3.7): a synthetic red/blue pair with handles accepted a 24-frame centered Cross Dissolve. GetStart/End returned 59/83 around cut 71, GetDuration returned 24, and source clip spans were unchanged. Both community interfaces rendered identical 142-frame movies with a progressive red-to-blue blend. With zero handles the native call returned None. This validates that fixture, not other effects, audio transitions or alignments. See resolve211-native-transitions.md. WHAT REMAINS MISSING ON 21.1: reading a transition back. There is still no accessor for an existing transition's type, alignment or duration beyond its name string and frame range, and no clone verb — alignment and duration are write-only arguments to AddTransition. The pre-21.1 statement, kept as the historical record: there was no method to ADD or CLONE an edit transition — no AddTransition/CreateTransition/AddVideoTransition on Timeline or TimelineItem (dir(), 21.0.4.5). CORRECTION, measured on Studio 21.0.4.5 (2026-08-12): this entry previously said transitions applied in the UI are 'invisible to and unmodifiable by scripts'. BOTH HALVES WERE WRONG and are withdrawn. A transition IS a first-class timeline item: a 12-frame Cross Dissolve applied through the Edit-page right-click menu enumerates in GetItemListInTrack('video', 1) as GetName()=='Cross Dissolve', GetStart()==86426, GetDuration()==12 — centered on a cut at 86432 — with a stable GetUniqueId() and a working GetTrackTypeAndIndex(). A transition authored offline into a .drp and imported reads IDENTICALLY, so the route that created it does not matter. It is also REMOVABLE: Timeline.DeleteClips([transition], False) returns True and deletes it, leaving both adjacent clips at their original starts and durations. THE DISCRIMINATOR between a transition item and a clip item is GetProperty(): a transition returns an EMPTY dict where a video clip returns 26 transform keys; it also has no MediaPoolItem and no Fusion comp. WHAT IS GENUINELY MISSING (pre-21.1: creation too; on 21.1+ read the paragraph above): cloning, and any type/alignment/parameter detail — the transition's kind is knowable ONLY from its name string, and there is no way to read its alignment (centered/start/end) or edit its duration. AUDIO NUANCE (measured 2026-09-01 on 19.1.3.7, E113): an audio cross-fade enumerates in GetItemListInTrack('audio', n) with an EMPTY GetName() (24 frames, centered on the cut, between the two clips) — so on audio lanes even the kind is not readable from the name. The discriminator that holds for BOTH: GetMediaPoolItem() is None AND GetProperty() is empty — BUT a Solid Color generator AND a subtitle item read the same way (GetProperty() None, no MediaPoolItem; measured E115), so that pair only separates clips from non-clips. What separates a transition from a generator is GEOMETRY: a transition straddles a cut (one neighbour ends inside its span, another starts inside it) while a generator owns its span. timeline.get_items reports `kind` on that basis.
+- **Behavior:** CREATION IS FIXED IN 21.1, READBACK IS NOT. Reported by @billcarroll (PR #197) from an attribute probe on Studio 21.1.0.14 (2026-09-08; not reproduced here, no 21.1 install): TimelineItem.AddTransition resolves to a <BlackmagicFusion.PyFunctionCall object>, not None. Its stub signature is AddTransition(transitionOptions) -> TimelineItem | None, where transitionOptions carries type (e.g. 'Cross Dissolve'), category ('simple'|'fusion'|'ofx'|'audio'), position ('start'|'end'), alignment ('left'|'center'|'right') and an optional duration in frames. That original probe did not invoke the method. UPDATE, contributor-validated by @legionsound on Studio 21.1.0.14, macOS, 2026-09-09 (not reproduced by the maintainer on 19.1.3.7): a synthetic red/blue pair with handles accepted a 24-frame centered Cross Dissolve. GetStart/End returned 59/83 around cut 71, GetDuration returned 24, and source clip spans were unchanged. Both community interfaces rendered identical 142-frame movies with a progressive red-to-blue blend. With zero handles the native call returned None. This validates that fixture, not other effects, audio transitions or alignments. See resolve211-native-transitions.md. DURATION IS OPTIONAL AND AN EXPLICIT NULL IS NOT A SPECIAL CASE, measured by @legionsound on Studio 21.1.0.14 (2026-09-09) on fresh timelines with the same handled red/blue fixture: omitting the duration key and passing duration=None behaved IDENTICALLY, both creating a transition at GetDuration()==8 spanning 67-75 around a cut at 71. So a wrapper must NOT strip an explicit null to work around a refusal — there is no refusal to work around. The 8 frames is what that build chose for that fixture, NOT a documented default; this was creation and readback only, not rendered. WHAT REMAINS MISSING ON 21.1: reading a transition back. There is still no accessor for an existing transition's type, alignment or duration beyond its name string and frame range, and no clone verb — alignment and duration are write-only arguments to AddTransition. The pre-21.1 statement, kept as the historical record: there was no method to ADD or CLONE an edit transition — no AddTransition/CreateTransition/AddVideoTransition on Timeline or TimelineItem (dir(), 21.0.4.5). CORRECTION, measured on Studio 21.0.4.5 (2026-08-12): this entry previously said transitions applied in the UI are 'invisible to and unmodifiable by scripts'. BOTH HALVES WERE WRONG and are withdrawn. A transition IS a first-class timeline item: a 12-frame Cross Dissolve applied through the Edit-page right-click menu enumerates in GetItemListInTrack('video', 1) as GetName()=='Cross Dissolve', GetStart()==86426, GetDuration()==12 — centered on a cut at 86432 — with a stable GetUniqueId() and a working GetTrackTypeAndIndex(). A transition authored offline into a .drp and imported reads IDENTICALLY, so the route that created it does not matter. It is also REMOVABLE: Timeline.DeleteClips([transition], False) returns True and deletes it, leaving both adjacent clips at their original starts and durations. THE DISCRIMINATOR between a transition item and a clip item is GetProperty(): a transition returns an EMPTY dict where a video clip returns 26 transform keys; it also has no MediaPoolItem and no Fusion comp. WHAT IS GENUINELY MISSING (pre-21.1: creation too; on 21.1+ read the paragraph above): cloning, and any type/alignment/parameter detail — the transition's kind is knowable ONLY from its name string, and there is no way to read its alignment (centered/start/end) or edit its duration. AUDIO NUANCE (measured 2026-09-01 on 19.1.3.7, E113): an audio cross-fade enumerates in GetItemListInTrack('audio', n) with an EMPTY GetName() (24 frames, centered on the cut, between the two clips) — so on audio lanes even the kind is not readable from the name. The discriminator that holds for BOTH: GetMediaPoolItem() is None AND GetProperty() is empty — BUT a Solid Color generator AND a subtitle item read the same way (GetProperty() None, no MediaPoolItem; measured E115), so that pair only separates clips from non-clips. What separates a transition from a generator is GEOMETRY: a transition straddles a cut (one neighbour ends inside its span, another starts inside it) while a generator owns its span. timeline.get_items reports `kind` on that basis.
 - **Workaround / current handling:** Automated QC of existing transitions IS possible and is the main practical need — enumerate GetItemListInTrack, treat any item whose GetProperty() is empty and whose GetMediaPoolItem() is None as a transition, and read its name, start and duration. Removal is scriptable via Timeline.DeleteClips. To CREATE one, either apply it in the Resolve UI, or author it offline and import: the advanced server's drp place_transition writes a cross dissolve at an abutting cut ({track, atFrame, durationFrames}) and it round-trips into Resolve 21.0.4.5 reading back at the expected centered range. On 21.1+ prefer TimelineItem.AddTransition, which takes the type, category, edge, alignment and duration directly.
 - **Tags:** missing-method, timeline, transition
 

package/docs/reference/resolve211-native-transitions.md

@@ -45,8 +45,17 @@ The included scratch test exercises both community interfaces and creates render
 jobs for independent movie inspection. Unit tests cover actual returned spans,
 missing native methods, None/False failures, malformed options, optional duration,
 write classification, and dry-run refusal. Audio transitions, Fusion/OFX effects,
-other alignments, automatic duration and repeated insertion are not live-validated
-by this contribution. Support for their documented options is pass-through.
+other alignments and repeated insertion are not live-validated by this
+contribution. Support for their documented options is pass-through.
+
+Automatic duration was measured afterwards, by @legionsound on Studio 21.1.0.14
+(2026-09-09), on fresh timelines with the same handled red/blue fixture: omitting
+the `duration` key and passing `duration: null` behaved identically, each creating
+a transition of 8 frames spanning 67-75 around a cut at 71. An explicit null is
+therefore not a special case, and a wrapper must not strip it to route around a
+refusal — there is no refusal. The 8 frames is what that build chose for that
+fixture, not a documented default, and these two cases were creation and readback
+only; they were not rendered.
 
 `python tests/live_resolve211_transitions.py OUTPUT_DIR` requires a disposable
 project named `Codex Native Transition Validation 20260909`, set to 640x360/24 fps,

package/install.py

@@ -37,7 +37,7 @@ from src.utils.update_check import (
 
 # ─── Version ──────────────────────────────────────────────────────────────────
 
-VERSION = "2.218.0"
+VERSION = "2.218.2"
 # Only hard floor: mcp[cli] requires Python 3.10+. There is no upper bound —
 # Resolve's scripting bridge loads into newer interpreters on recent builds
 # (Python 3.14 verified against Resolve Studio 20.3.2). Older Resolve builds

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "davinci-resolve-mcp",
-  "version": "2.218.0",
+  "version": "2.218.2",
   "description": "NPM bootstrapper for the DaVinci Resolve MCP Server.",
   "license": "MIT",
   "author": "Samuel Gursky <samgursky@gmail.com>",

package/src/granular/common.py

@@ -87,7 +87,7 @@ if not logging.getLogger().handlers:
         handlers=[logging.StreamHandler()],
     )
 
-VERSION = "2.218.0"
+VERSION = "2.218.2"
 logger = logging.getLogger("davinci-resolve-mcp")
 logger.info(f"Starting DaVinci Resolve MCP Server v{VERSION}")
 logger.info(f"Detected platform: {get_platform()}")

package/src/server.py

@@ -11,7 +11,7 @@ Usage:
     python src/server.py --full       # Start the 368-tool granular server instead
 """
 
-VERSION = "2.218.0"
+VERSION = "2.218.2"
 
 import base64
 import os

package/src/utils/api_truth.py

@@ -915,6 +915,16 @@ API_TRUTH: List[Dict[str, Any]] = [
                    "red-to-blue blend. With zero handles the native call returned "
                    "None. This validates that fixture, not other effects, audio "
                    "transitions or alignments. See resolve211-native-transitions.md. "
+                   "DURATION IS OPTIONAL AND AN EXPLICIT NULL IS NOT A SPECIAL CASE, "
+                   "measured by @legionsound on Studio 21.1.0.14 (2026-09-09) on "
+                   "fresh timelines with the same handled red/blue fixture: omitting "
+                   "the duration key and passing duration=None behaved IDENTICALLY, "
+                   "both creating a transition at GetDuration()==8 spanning 67-75 "
+                   "around a cut at 71. So a wrapper must NOT strip an explicit null "
+                   "to work around a refusal — there is no refusal to work around. "
+                   "The 8 frames is what that build chose for that fixture, NOT a "
+                   "documented default; this was creation and readback only, not "
+                   "rendered. "
                    "WHAT REMAINS MISSING ON 21.1: reading a "
                    "transition back. There is still no accessor for an existing "
                    "transition's type, alignment or duration beyond its name string "

package/src/utils/resolve_runtime.py

@@ -96,6 +96,91 @@ def _split_pid(line: str, index: int):
     return -(index + 1), line
 
 
+def _windows_wmic_rows(stdout: str) -> List[Dict[str, Optional[str]]]:
+    """WMIC prints one command line per row, under a `CommandLine` header.
+
+    The header row and WMIC's blank padding rows are left in rather than
+    filtered: they are not Resolve command lines, so the executable match
+    drops them, and a second filter here would be a second place for that
+    decision to drift. There is no pid column to read, so pids are synthetic
+    and negative — they exist only to key the row, never to name a process.
+    """
+    return [{"pid": -(index + 1), "comm": None, "args": line}
+            for index, line in enumerate(stdout.splitlines())]
+
+
+def _windows_cim_rows(stdout: str) -> List[Dict[str, Optional[str]]]:
+    """`ProcessId`, `ExecutablePath` and `CommandLine`, tab-separated per row.
+
+    Four columns rather than the command line alone, because they fail
+    independently exactly as they do on POSIX. Measured on build 26200 by the
+    reporter of #210, querying as an unelevated user: for a process the caller
+    cannot fully read, CIM still returns the row with `ProcessId` and `Name`
+    populated and `CommandLine` NULL — the *column* is access-restricted, not
+    the row. Reading only the command line would turn such an instance into no
+    row at all: an empty list, which does not mean "undeterminable", it means
+    "nothing is running", and that is the answer that launches a second
+    Resolve on top of a live one.
+
+    `Name` rather than `ExecutablePath` alone is the reason this holds. That
+    measurement showed `Name` surviving the access restriction; it did not
+    show `ExecutablePath` surviving it, and for a protected process that field
+    is commonly empty too. So the executable column falls back to the bare
+    process name, which `RESOLVE_PROCESS_PATTERNS` already matches — enough to
+    prove an instance is up, while the mode stays honestly unknown, since
+    `-nogui` is only ever visible in the command line.
+
+    Split at most three times: a command line may itself contain tabs, and it
+    is the last field, so everything after the third separator belongs to it.
+    """
+    rows: List[Dict[str, Optional[str]]] = []
+    for index, line in enumerate(stdout.splitlines()):
+        if not line.strip():
+            continue
+        fields = line.split("\t", 3)
+        fields += [""] * (4 - len(fields))
+        try:
+            pid = int(fields[0].strip())
+        except ValueError:
+            pid = -(index + 1)
+        rows.append({"pid": pid,
+                     "comm": fields[2].strip() or fields[1].strip() or None,
+                     "args": fields[3].strip() or None})
+    return rows
+
+
+#: PowerShell equivalent of the WMIC query, emitting the four columns above.
+#: The output encoding is forced because the default console codepage mangles
+#: a non-ASCII install path before Python ever sees it.
+_CIM_COMMAND = (
+    "[Console]::OutputEncoding=[Text.Encoding]::UTF8; "
+    "Get-CimInstance Win32_Process -Filter \"name='Resolve.exe'\" | "
+    "ForEach-Object { \"$($_.ProcessId)`t$($_.Name)`t$($_.ExecutablePath)`t$($_.CommandLine)\" }"
+)
+
+#: Readers for the Windows process table, tried in order until one answers.
+#:
+#: WMIC first, so a machine that still has it behaves exactly as it did before
+#: — but **WMIC was removed in Windows 11 build 26200** and is neither on PATH
+#: nor at its old System32\wbem location, so on current Windows it raises
+#: FileNotFoundError and every tool refused with "Resolve is not running"
+#: while Resolve sat in front of the user (#210). Keeping the old reader first
+#: costs nothing precisely because absence fails instantly rather than burning
+#: the timeout. Windows PowerShell 5.1 ships with Windows; `pwsh` is the
+#: cross-platform 7.x binary, tried last for a machine that has only that one.
+#:
+#: `None` is returned only when NO reader ran. A reader that ran and found
+#: nothing returns an empty list, which is a different answer.
+WINDOWS_PROCESS_READERS = (
+    (["wmic", "process", "where", "name='Resolve.exe'", "get", "CommandLine"],
+     _windows_wmic_rows),
+    (["powershell", "-NoProfile", "-NonInteractive", "-Command", _CIM_COMMAND],
+     _windows_cim_rows),
+    (["pwsh", "-NoProfile", "-NonInteractive", "-Command", _CIM_COMMAND],
+     _windows_cim_rows),
+)
+
+
 def _process_table() -> Optional[List[Dict[str, Optional[str]]]]:
     """One row per process: `{pid, comm, args}`, or None when undeterminable.
 
@@ -113,27 +198,28 @@ def _process_table() -> Optional[List[Dict[str, Optional[str]]]]:
     """
     if platform.system().lower() == "windows":
         # `tasklist` prints no command line, so the flag is invisible there.
-        # WMIC does print it and is what makes headless detection possible.
+        # The readers below do print it, which is what makes headless
+        # detection possible on Windows at all.
         #
         # Decoded explicitly: `text=True` alone decodes with the locale
         # codepage, which raises UnicodeDecodeError on a byte cp1252 has no
         # mapping for — and this read is the input to the second-instance
         # guard, so it must fail to "cannot tell", never to an exception.
         # ASCII is byte-identical under both codecs, so the matching this
-        # feeds is unchanged; what WMIC emits for a non-ASCII install path
-        # on a non-English Windows is not something we can verify here.
-        try:
-            out = subprocess.run(
-                ["wmic", "process", "where", "name='Resolve.exe'", "get", "CommandLine"],
-                capture_output=True, text=True, encoding="utf-8", errors="replace",
-                timeout=10, check=False,
-            )
-        except Exception:  # pragma: no cover - defensive; an unknown answer is None
-            return None
-        if out.returncode != 0 and not out.stdout:
-            return None
-        return [{"pid": -(i + 1), "comm": None, "args": line}
-                for i, line in enumerate((out.stdout or "").splitlines())]
+        # feeds is unchanged; what these readers emit for a non-ASCII install
+        # path on a non-English Windows is not something we can verify here.
+        for reader, parse in WINDOWS_PROCESS_READERS:
+            try:
+                out = subprocess.run(
+                    reader, capture_output=True, text=True, encoding="utf-8",
+                    errors="replace", timeout=10, check=False,
+                )
+            except Exception:
+                continue  # this reader is unusable here; try the next one
+            if out.returncode != 0 and not (out.stdout or "").strip():
+                continue
+            return parse(out.stdout or "")
+        return None
 
     comm_lines = _run_ps("pid=,comm=")
     args_lines = _run_ps("pid=,args=")