[Bug]: USB passthrough (Windows host): device-initiated reset/re-enumeration is not propagated to the guest; captured device stalls all requests until usbdetach/usbattach

Ouverte
  • Quelque chose ne va pas ?
#922 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 6 jours

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
42/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
c, linux
Domaine
desktop, operating-systems

Piste de recherche

Start by tracing the Windows USB proxy and VBoxSVC device enumeration path described in the report; the issue does not name source files or tests. Compare how a physical unplug and replug reaches the VM with the same-path re-enumeration after the FT4222 reset. Done means the guest sees the captured device disconnect and return, and its requests work again without manually running usbdetach and usbattach.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug
Version

7.2.20

Host OS Type

Windows

Host OS name + version

Windows 11 Enterprise 10.0.26200 (x64), Hyper-V/VBS active (VirtualBox runs on Hyper-V/NEM)

Host Architecture

x86

Guest OS Type

Linux

Guest Architecture

x86

Guest OS name + version

AlmaLinux 9.8, kernel 5.14.0-687.5.3.el9_8.x86_64, xHCI controller, libusb-1.0.30

Component

USB and Serial Ports

What happened?
Component USB
Version VirtualBox 7.2.20 r175154
Host Windows 11 Enterprise 10.0.26200 (x64), Hyper-V/VBS active (VirtualBox runs on Hyper-V/NEM)
Guest AlmaLinux 9.8, kernel 5.14.0-687.5.3.el9_8.x86_64, xHCI controller, libusb-1.0.30
Reproducible Always (7 of 7), across four VM boots, before and after a host reboot

Summary

A USB device that resets itself on request (drops off the bus and re-enumerates)
works on bare-metal Linux and natively on the Windows host. When the device is
captured by a VM, the re-enumeration never reaches the guest. The guest sees no
disconnect, and every later control request to the device fails with STALL
(LIBUSB_ERROR_PIPE), even requests that worked a moment before. The device
stays in that state until the host runs usbdetach and usbattach.

The host does notice the change: VBoxSVC starts a USB enumeration 0.8 s after
the reset. It then finds the device "still captured" under the same VBoxUSB path
and does not tell the VM.

Device

FTDI FT4222H (0403:601C, bcdDevice 18.00), full speed behind a USB 2.0 hub
(0403:6017).

The reset is FTDI's documented FT4222_ChipReset (libft4222), a vendor OUT
request:

bmRequestType bRequest wValue wIndex wLength
0x40 0x21 0x0080 0 0

The chip then reloads its configuration and re-enumerates with a new address,
but with the same VID, PID and serial number.

Steps to reproduce

  1. Create a USB device filter for 0403:601C, start the VM and let the device be
    captured.
  2. In the guest (libusb), send a read, for example C0 20 0000 0000, length 12.
    It succeeds.
  3. Send the reset 40 21 0080 0000, length 0. It returns OK (in one of seven
    runs it returned STALL instead).
  4. Wait 20 s, then send the read from step 2 again.

Expected

The device disappears from the guest and comes back with a new address within
1–2 s, as on bare metal. After that, requests succeed.

Actual

  • Step 4 returns STALL (LIBUSB_ERROR_PIPE). All further requests stall,
    including a second reset request.
  • Guest dmesg: no USB disconnect and no new enumeration. The device keeps
    its address.
  • VBox.log: no VUSB: Detached or Attached lines.
  • Windows: the device stays as "VirtualBox USB Driver"
    (USB\VID_80EE&PID_CAFE\...) with no PnP change. VBoxManage list usbhost
    shows it as Captured.
  • libusb_reset_device() from the guest makes the guest re-enumerate it
    (device firmware changed, string descriptor 0 read error: -32), but it
    still stalls.

Comparison

Setup Result
Windows host, device not captured (filter inactive), same request via FTDI D2XX FT_VendorCmdSet(0x80) Device gone after 0.2 s, back after 1.2–2.1 s, works
Bare-metal Linux (AlmaLinux 9.8), same libusb code Re-enumerates after about 0.4 s, works
Physical unplug and replug while captured Works: Detached/Attached logged, recaptured in about 2.3 s
USBPcap filter driver removed from the USB class UpperFilters, host rebooted No change

What the logs show

Attached run on 2026-10-20. All times are UTC.

Time Event
11:30:40.039 Guest sends the reset request (OK)
11:30:40.824 VBoxSVC.log: usbLibGetDevices: Starting USB device enumeration (VBoxSVC relative 00:01:21.634). The host noticed a device change 0.8 s after the reset. It finds the device still captured under the same VBoxUSB path \\?\usb#vid_80ee&pid_cafe#5926400002#{00873fdf-...} (Found 12 USB devices, 2 captured, as before). Nothing else happens, and VBox.log has no Detached or Attached lines
11:31:00.046 Guest request returns STALL
11:31:00.552 usbdetach (VBox.log: VUSB: Detached ... proxy 0403:601c)
11:31:03.416 usbattach (VBox.log: VUSB: Attached ... to port 2)
11:31:05 Guest requests work again

The VM was started with
VBOX_RELEASE_LOG=+usb_proxy.e.l.l2.l3.f+drv_vusb.e.l.l2.f+dev_xhci.e.l.f, but
the release build logs nothing more than the lines above for this sequence.

Our reading

The device drops off the bus and comes back within about 1 s with the same VID,
PID and serial number, so it reappears under VBoxUSB with the same instance path.
VBoxSVC sees "the same captured device" and does not notify the VM. The VM's USB
proxy keeps its old handle and state for a device that has been reset
(unconfigured, address 0), which explains the stalls.

A possible fix: VBoxUSB or VBoxSVC detects the re-arrival of a captured device
(a new device object or a PnP arrival) and re-attaches it to the VM, as it already
does for a physical unplug and replug.

Workaround

On the host, run VBoxManage controlvm <vm> usbdetach <uuid>, then
usbattach <uuid>. The filter does not recapture the device by itself after
usbdetach. The guest then sees the device anew and it works normally. The host
has to do this after every reset.

Attachments

User name, domain and DNS servers are redacted.

File Content
VBox.log VM log. Reset at 11:30:40.039 UTC (VM relative 00:01:17.879), usbdetach at 11:31:00.552 (00:01:38.393), usbattach at 11:31:03.416 (00:01:41.257)
VBoxSVC.log Host-side log. Enumeration after the reset at 00:01:21.634 (11:30:40.824 UTC), usbdetach and usbattach at 00:01:41.36–00:01:44.12

Guest timestamps come from the guest clock (chrony: less than 1 ms from NTP time).

VBox.log
VBoxSVC.log

How can we reproduce this?

See the "What happened" field.

Did you upload all of your necessary log files, screenshots, etc.?
  • Yes, I've uploaded all pertinent files to this issue.
Langage dominant
C
Étoiles
1.4k
Forks
219
Aucune PR mergée en 30 j

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de VirtualBox/virtualbox

Toutes les issues de VirtualBox/virtualbox

Issues similaires

Plus d'issues C

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.