feat(windows): detect and automatically disable incompatible Acronis fltsrv storage filter #1071

Parent/related hardware investigation: #1049

Context

RP-series ROM BOOTSEL exposes a synthetic FAT mass-storage volume. On Windows, third-party disk and volume class filters can intercept every write to this device before fbuild reaches the ROM.

Acronis True Image for Crucial 23.0.21500 installs fltsrv (Acronis Storage Filter Management) as a boot-start legacy storage filter and registers it in both class stacks:

• DiskDrive {4d36e967-e325-11ce-bfc1-08002be10318} UpperFilters: partmgr, fltsrv
• Volume {71a27cdd-812a-11d0-bec7-08002be2092f} UpperFilters: volsnap, fltsrv
• service: HKLM\SYSTEM\CurrentControlSet\Services\fltsrv, Start=0

The service reports STOPPABLE, but sc stop fltsrv returns Windows error 1052. It is a legacy class filter, not a Filter Manager minifilter, so fltmc detach cannot remove it. Isolation requires a validated next-boot registry change.

A controlled attached-Pico A/B removed only fltsrv, preserved partmgr/volsnap, disabled fltsrv plus the Acronis scheduler, and rebooted. PlatformIO and fbuild still failed in the mass-storage write, so fltsrv is not the root cause of the current #1049 board failure. This issue is host diagnosis/remediation support, not a claim that disabling Acronis fixes every RP2040 upload.

Proposal

Add a Windows host-storage preflight/doctor path used by RP-series mass-storage deployment:

1. Detect fltsrv automatically by service identity and its actual presence in DiskDrive/Volume UpperFilters; do not infer from process names alone.
2. Surface a precise diagnostic before/after Windows errors such as 1006/1392, including whether the driver is currently loaded and whether a reboot is required.
3. Provide an explicit remediation option (interactive confirmation and a noninteractive CLI flag). Once selected, the disable operation itself is automatic:
   • require/elevate through UAC;
   • export the exact class and service keys plus a machine-readable manifest to an fbuild recovery directory;
   • remove only case-insensitive fltsrv entries while preserving the order and contents of every other REG_MULTI_SZ element;
   • disable only the fltsrv driver and the Acronis scheduler component needed to prevent re-registration;
   • stop user-mode Acronis monitor/scheduler processes only after positive product/service identification;
   • re-read and validate every value before reporting success;
   • roll back immediately if validation fails.
4. Offer reboot as a separate explicit option. Never force reboot/logout merely because the filter was detected or disabled.
5. Do not automatically re-enable fltsrv. Keep the backup and provide an explicit restore command that imports and verifies the original state; restoration may report that a later reboot is required.
6. Keep this independent of board VID/PID literals. RP-series identity remains sourced from FastLED/boards.

Suggested UX (exact command naming may follow existing CLI conventions):

fbuild doctor windows-storage
fbuild doctor windows-storage --disable fltsrv
fbuild doctor windows-storage --disable fltsrv --reboot
fbuild doctor windows-storage --restore <recovery-id>

fbuild deploy may link to or invoke the same helper after explicit consent, but registry/elevation logic must have one implementation.

Safety requirements

• Windows only; fail closed elsewhere.
• Never remove partmgr, volsnap, Microsoft filters, or any unrequested third-party filter.
• Refuse empty/missing/malformed UpperFilters, an unknown fltsrv binary/service identity, absent backup exports, or unexpected concurrent changes.
• Never edit USB VID/PID data, install WinUSB/Zadig, run filesystem repair, format the ROM volume, or write raw disks.
• No reboot unless the user explicitly selected it.
• Preserve rollback files across daemon restarts and package upgrades.
• Print the exact affected keys, before/after values, recovery ID/path, current driver state, and reboot requirement.

Acceptance criteria

• A pure detector reports loaded/stopped/start mode and exact DiskDrive/Volume membership for synthetic registry fixtures.
• Detection is automatic during relevant Windows RP-series deploy failures and produces an actionable command without mutating the host.
• The opt-in disable command automatically handles UAC, backup, targeted mutation, validation, and rollback-on-failure.
• Tests prove partmgr, volsnap, ordering, unrelated filters, and registry value types are preserved.
• Tests cover repeated/idempotent disable, concurrent-value drift, missing service, spoofed service/binary identity, denied elevation, failed export, partial mutation, and failed rollback.
• Reboot is never initiated without the explicit reboot option.
• Restore requires a valid recovery manifest, restores the exact original values/start modes, validates them, and does not silently reboot.
• Unit tests use an injected registry/service/reboot executor and never touch the developer machine.
• A Windows admin integration test is explicitly opt-in/ignored with a hardware/privilege reason and records before/after state.
• Documentation states that filter detection is diagnostic and that the feat(rp2040): deploy parity with Arduino-Pico, PlatformIO, and official picotool #1049 A/B did not fix the attached Pico write failure.

Related issues

• feat(rp2040): deploy parity with Arduino-Pico, PlatformIO, and official picotool #1049 — RP2040 stock UF2/picotool parity and attached Pico acceptance; contains the physical error 1006 evidence and A/B result.