Post-sleep sessions still failed on 0.25.0 — the host was holding open the very device its recovery asks PnP to cycle #119

Merged

enricobuehler merged 3 commits from worktree-vdisplay-reap-pnputil into main 2026-08-08 13:29:11 +00:00

Conversation 0 Commits 3 Files Changed 4

+286 -124

3 Commits

Author	SHA1	Message	Date
enricobuehler	fba22c6c64	fix(host/vdisplay): the host no longer vetoes its own wake-from-sleep recovery — control handles close on retire ... The control-device sharing contract was 'bare HANDLE copies, never closed for the process lifetime': retired handles were deliberately kept alive because the pinger/linger threads and the capture delivery closures held raw copies whose soundness depended on no-close. The cost surfaced in the 2026-08-08 field log: after a wake left the driver hostless, every adapter reload came back REFUSED (Generic failure) — and an open control handle is exactly what vetoes the PnP disable (and can wedge the pnputil restart) the recovery leans on. reset-pf-vdisplay.ps1 stops the whole host service precisely to get those handles closed; the in-process recovery could not, because the process could never close them. Ownership is now Arc all the way out: ensure_device/device_handle/ control_device_handle hand out Arc<OwnedHandle> clones, every consumer holds its clone across its IOCTLs (the capture closures each own one — Arc<OwnedHandle> is Send+Sync, ending the isize smuggling), and retiring drops only the manager's reference, so the handle CLOSES when the last in-flight user drains. DeviceSlot::retired is gone. The recovery path now releases the manager's reference at the first absent sighting — the 3 s ABSENT_SETTLE doubles as the drain window — and again before a not-ready-deadline reload, so the PnP cycle finally runs against a device the host is no longer holding open. The driver attaches no meaning to the control file closing (host-gone is the IOCTL-liveness watchdog, EvtFileClose deliberately unhooked), so the close has no driver-side side effects. Lock order note: RECOVERY → device is now taken (the release hooks); the forbidden inverse still never occurs — VdisplayDriver::open never reloads.	2026-08-08 13:37:05 +02:00
enricobuehler	f242b2d2fc	fix(host/vdisplay): a refused adapter reload now says WHY, and never targets a phantom devnode ... Field log 2026-08-08 (0.25.0, wake from sleep): every session died on 'the adapter devnode could not be reloaded (Generic failure)' — the WMI catch-all — because the REFUSED branch reported only the Disable exception and threw away everything that would identify the failure mode: why the pnputil /restart-device fallback ALSO failed (its exit code — 3010 'needs a reboot' is its own diagnosis), what state the devnode was in, and whether the right devnode was even targeted. That last one is a real trap, not just missing telemetry: Get-PnpDevice lists not-present PHANTOM devnodes (upgrade/reinstall leftovers), and Select-Object -First 1 could hand every recovery attempt a phantom — whose disable and restart both fail exactly like the field log — while a live node sat unexamined. The selector now prefers present nodes (OK before problem-state), and a phantom-only state gets a truthful refusal: no reload can revive a devnode record whose device is gone; only reinstalling re-creates it. The REFUSED line now carries devnode counts, the chosen node's PnP Status + ConfigManager problem code, and the restart exit code, so the next field log decides between handle-veto, phantom, and problem-state instead of reading 'Generic failure'. Decode pinned by test.	2026-08-08 13:22:05 +02:00
enricobuehler	975fef2048	fix(host/vdisplay): the ghost-monitor reap can no longer fail in silence ... The reap that keeps departed virtual monitors from exhausting the IddCx monitor-slot budget launched pnputil by BARE NAME — under the LocalSystem service's PATH that can miss System32, SilentlyContinue swallowed the miss, and the Rust side logged only when the count was positive: a reap that removed nothing and a box with no ghosts were byte-identical (silence). Ghosts then ratcheted up with every sleep cycle until IOCTL_ADD wedged at 0x80070490 and every session black-screened — and the wedge self-heal shipped in 0.25.0 retried an ADD behind a reap that could never remove anything, which is exactly a persistent post-sleep "no connection" surviving the b6acbd09 probe fix. Same family and same cure as the adapter-reload path one function down: resolve pnputil via $env:SystemRoot (a SYSTEM process must not trust PATH anyway — a planted pnputil.exe would run elevated), pre-seed $LASTEXITCODE to failure before every launch, and report found AND removed unconditionally so "no ghosts" and "removed nothing" are finally distinguishable in a field log. The report parse is split out and pinned by tests like classify_reload_output.	2026-08-08 12:19:48 +02:00