Windows MSI: re-install/upgrade over an existing install fails with Error 1722 — install-driver.ps1 restarts the device before stopping the broker, poisoning the instance with pending-reboot #215

Describe the Bug

On any machine where a previous install ran at least as far as the driver custom action (including a fully successful install), every subsequent run of libvirtualhid-Windows-AMD64-driver-installer.msi fails near the end with:

Error 1722. There is a problem with this Windows Installer package. A program run as
part of the setup did not finish as expected. Contact your support personnel or
package vendor. Action CA_LibVirtualHidInstallDriver

The MSI rolls back, but the staged driver package, the ROOT\LIBVIRTUALHID\0000 device instance and the libvirtualhid_broker service are not MSI-managed and survive the rollback — so the product never appears in Apps & Features while the driver "seems installed", and every retry fails the same way. Reproduced with installer 2026.1028.334.38 and 2026.1030.2010.1.

Root cause (two-stage, in install-driver.ps1, existing-device path)

The script sequence is:

1. Update-RootDeviceDriverWithSetupApi — libvirtualhid_driver_setup.exe update ...
2. Restart-RootDevice — pnputil.exe /restart-device ROOT\LIBVIRTUALHID\0000, which throws on any non-zero exit
3. Install-LibVirtualHidBrokerService — this is where the broker gets stopped and reconfigured

Stage 1: the broker is registered start= auto and runs from boot; together with connected clients (e.g. Sunshine) it holds an open handle on the device, so the driver update's device restart is vetoed:

dvi: Query-removal during install of 'ROOT\LIBVIRTUALHID\0000' was vetoed by
     'ROOT\LIBVIRTUALHID\0000' (veto type 5: PNP_VetoOutstandingOpen).
dvi: Device required reboot: Query remove failed (install) 0x17: CR_REMOVE_VETOED.
ndv: Reboot needed to complete driver update.

Stage 2: that veto leaves the device instance in "pending system reboot", after which every pnputil /restart-device is refused outright, regardless of what holds the handle:

Failed to restart device: ROOT\LIBVIRTUALHID\0000
Device is pending system reboot to complete a previous operation.
This command is not supported on the OS product.
→ exit code 50

The script turns that into a terminating error → powershell.exe -File exits 1 → MSI Error 1722 → rollback. This is a deadlock: the script can only stop the broker in step 3, after the restart in step 2 that the running broker blocks — and because a plain reboot does not help as long as the broker is running when the CA executes, the installer can never complete over an existing install. Both the interactive (CA_LibVirtualHidInstallDriver) and silent (...Silent) variants carry the identical command line.

The exit code 50 failure appears verbatim in the Microsoft-Windows-PowerShell/Operational event log (event 4100) for every failing run:

Error Message = pnputil.exe /restart-device ROOT\LIBVIRTUALHID\0000 exited with code 50

Steps to Reproduce

1. Install the MSI once successfully (or run install-driver.ps1 elevated once) so the device instance and broker service exist.
2. Leave libvirtualhid_broker running (Automatic) — optionally with a client app using the device.
3. Run the same or a newer installer MSI elevated.
4. File copy and driver staging succeed, then the install fails with Error 1722 at the driver CA; the product is absent from Apps & Features while device, service and staged driver remain.
5. Every retry fails identically.

Expected Behavior

The installer should succeed over an existing install: stop the broker before touching or restarting the device, and report a deferred driver reload as a reboot-required condition instead of failing the whole transaction.

Suggested fix

• Call Stop-LibVirtualHidBrokerService before Update-RootDeviceDriverWithSetupApi / Restart-RootDevice on the existing-device path (the function already exists), and only start the broker again as the final step.
• Treat a pnputil /restart-device failure caused by pending-reboot/veto as a warning ("a reboot will complete the driver reload") rather than a terminating throw — or skip the restart when the instance is already in pending-reboot.
• Consider signalling reboot-required to MSI instead of exiting non-zero.

Workaround (for users hitting this now)

Elevated:

net stop libvirtualhid_broker
pnputil /remove-device ROOT\LIBVIRTUALHID\0000
msiexec /i libvirtualhid-Windows-AMD64-driver-installer.msi /qn /l*v install.log

(Stop any client app using the device first. /remove-device clears the poisoned instance and the installer recreates it fresh; alternatively a reboot clears the pending-reboot flag — but the broker must not be running when the CA executes.) This took an install from a deterministic Error 1722 to msiexec exit 0 with the product correctly registered.

Additional Context

• Environment: Windows 11 Pro build 26300, Windows PowerShell 5.1.26100.9818, installer 2026.1030.2010.1 (identical failure on 2026.1028.334.38).
• Not a duplicate of Install-driver.ps1 fails at Add-Type with "incorrect format" deterministic, survives reboot and clean driver re-registration #130 (Add-Type load failure, fixed in fix(installer): replace Add-Type with native setup helper #131): this failure is at the restart-device step and concerns ordering over an existing install.
• Diagnosis was harder than necessary: in every failing run Start-Transcript failed (Error Message = Transcription cannot be started, event 4100), so -LogPath never captured the terminating error. The only trail was the PowerShell operational log plus setupapi.dev.log. Worth checking why the transcript cannot start on this path under Windows 11 / PS 5.1.
• MSI rollback cannot unstage driver packages, so repeated failed runs accumulate one oem*.inf per attempt in the driver store (five had piled up here); a cleanup note or an uninstall-driver pass for orphans would help.