[eiz-claude]

Fixes the rig's recovery-after-kill failures, which had become constant. It failed on every build once the race ran right before it: 6 of 6 runs at 16 pairs, on both old and new code.

What was happening

New SarTest watch timelines and CPU sampling showed:

• The race outruns Windows' endpoint builder. Each of its ten host restarts in about 35 s disables and re-enables 32 endpoints' worth of KS interfaces (5 per endpoint). That's more than the AudioEndpointBuilder service can process as it happens.
• The builder keeps working afterwards. For about 15 s after the race it spends roughly 12 s of CPU working through the backlog. During that time it tears down and rebuilds SAR endpoints one at a time, in creation order: each goes notpresent and then active 0.3–1 s later, while its interfaces stay enabled.
• kill-host started 0.5 s after the race, so the backlog ran through kill-host and recovery. Recovery's streams stalled in Activate, which hit the 4 s GetDeviceInterfacePath2 retry seen in the September traces, and in Initialize, serialized behind it for up to 20 s. Others were invalidated or got only silence.
• Ruled out:
  • It isn't SAR's filters being unreachable: opening every enabled filter by interface path once a second never failed during the rebuilds.
  • It isn't kill and recovery themselves: run without the race, they show no rebuilds and no slow calls.

test VM, 16 pairs	endpoint-builder CPU after race	rebuilds in kill-host / recovery	recovery
kill-host right after the race	busy through both	32 / 9	failed
30 s idle after the race	12.6 s, done in ~15 s	11 / 1	passed
120 s idle after the race (2 runs)	11.8–12.5 s, done in ~15 s	1 / 1	passed

Change

• settle-after-race: after the race, wait until the endpoint builder is idle (under 100 ms of its CPU per second for three seconds in a row, up to two minutes) and record how long that took. Recovery then measures recovery from a killed host. The wait time is a metric for how much the race costs Windows, and a builder still busy after two minutes fails the scenario.
• SarTest watch: runs from before the race through recovery and writes watch.log and watch.json. It records:
  • every change in which SAR KS interfaces are enabled (polled every 20 ms);
  • every endpoint state change MMDevAPI reports;
  • each second in which the endpoint builder or audio service used 50 ms of CPU or more;
  • with --probe, each change in whether the SAR filters can be opened.
• -PostRaceDelaySeconds: optional extra idle time after the race, for experiments.

Results on the test VM

build	runs	settle-after-race	recovery-after-kill	slow calls (>1 s) in recovery
this branch (broadcast from the PR above still present)	2	idle after 18.1 s, 15.3 s	passed, passed	0, 0
with the PR above too, full default suite	2	idle after 13.1 s, 13.1 s	passed, passed	0, 0
before this branch, 16 pairs	6	(no wait)	failed in all 6	up to 32 per run

Stream invalidations remain on this branch alone (82–116 in the 16-pair loopback run). Those come from SarAsio's format-change broadcast, which the next PR removes.

🤖 Generated with Claude Code