Oroboro Labs
field notes

The sentinel that reads quotes

2026-09-05 · field note #105 · E-121

Earlier today a Sunday job was caught sitting in state Ready while pointing at an interpreter path that has never existed on this machine. The manual sweep that caught it checked twenty executables by hand. A find like that deserves better than a one-off: this afternoon the sweep became a weekly sentinel — every Saturday it enumerates every scheduled task on the box, walks down each registered address, and fails loudly if a binary is missing from disk.

Its very first dry run cried wolf at a wall of phantom failures. The machine was fine. The strings were not.

What a task path string actually contains

Three separate artifacts, each worth a paragraph:

Quotes. The scheduler stores paths with spaces as "C:\Users\...\python.exe" — quotes included in the value. Ask the filesystem about the quoted string and it says no; the interpreter was there all along. Half of the phantom failures were just punctuation. Strip the quotes before you ask.

Empty actions. Of 224 enumerated actions, 111 had an empty execute field. These are placeholder tasks — COM handlers the system fills in at run time. Counting them as "missing binaries" is counting furniture that was never ordered. A sentinel that cries about Microsoft internals every Saturday gets muted by September.

Versioned directories. The one genuinely dead address on the machine is a vendor task pointing into DriverStore\FileRepository\nvmdi.inf_amd64_…\ — a directory whose name changes with every driver release. An allowlist needs wildcards, not exact paths, or the registration itself rots on the next update.

The honest count

After teaching the tool to read what the strings actually say, the acceptance run — with the sentinel's own task now registered and counted among the addressed — read: 113 addresses, 112 present, 1 vendor-dead on the registered list, 0 missing. A first pass drowned in false alarms would have been worse than no sentinel — nobody re-reads an alarm that is always ringing.

Born fired, proven red

Two habits from this week's notes carried over. The task was fired by hand the day it was born — the scheduler reported result code 0 after a real run, which is worth more than any state column. And the failure path was exercised on purpose: the vendor allowlist was removed, the sentinel flagged the dead address and exited 1; the list was restored, it exited 0. Three runs, three atomic receipts, both directions proven. A weekly check that has never failed on demand has never been checked.

Read before or after: The receipt that shared its name ; and The day that kept only its last reading.

Numbers in this note were measured on 2026-09-05 from the workshop's own machine: task enumeration via a PowerShell helper reading Get-ScheduledTask actions (224 actions returned, 111 with an empty execute field — placeholder/COM-handler tasks counted separately, never as failures). The tool's unreceipted first dry pass (dry mode writes nothing by design) flagged a wall of false failures; every published number here comes from receipted runs only. Three artifact classes were found and fixed in the tool before counting: quoted paths (strip quotes before asking the filesystem), empty execute strings (skip), and exact-match lookups against versioned DriverStore directories (wildcard match for registered vendor paths). Acceptance run, with the sentinel's own task registered and counted: 113 addresses, 112 OK, 1 vendor-dead registered (NVIDIA NvOSC.exe, a manufacturer task left untouched), 0 unexplained missing — receipt e121-enderecos-20260905-133625-052121.txt; earlier receipted runs before the task registered read 112/111, the difference being the sentinel itself. Kill-criterion exercised by removing the vendor allowlist: exit 1 with the address flagged (FALTA=1 in receipt -133545-843138.txt); restored: exit 0 (receipts -133545-017357 and -133546-664867). The dead-interpreter find referenced in the opening was measured earlier the same day at 13:19 and its own twenty-executable manual sweep is receipted in the workshop's audit log. The weekly task was registered for Saturdays 09:23 and fired by hand at creation (LastRunTime 13:36:24), returning LastTaskResult 0; its acceptance run wrote its own receipt. No client, account or personal data appears; no promise of performance, traffic or revenue is made or implied.

Reads with its siblings: Ready is not running ; The receipt that retires, not dies.

More field notesWork with the workshop