USB: usb_device_handle_win.cc:1020 No se pudo leer el descriptor del error de conexión del nodo con ChromeDriver v87/Chrome v87 usando Selenium en Windows10
Recientemente actualizamos nuestro entorno de prueba de Windows 10 con ChromeDriver v87.0.4280.20 y Chrome v87.0.4280.66 (compilación oficial) (64 bits) y después de la actualización, incluso el programa mínimo produce este registro de ERROR:
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
Bloque de código mínimo:
from selenium import webdriver
options = webdriver.ChromeOptions()
options.add_argument("start-maximized")
driver = webdriver.Chrome(options=options, executable_path=r'C:\WebDrivers\chromedriver.exe')
driver.get('https://www.google.com/')
Salida de consola:
DevTools listening on ws://127.0.0.1:64170/devtools/browser/2fb4bb93-79ab-4131-9e4a-3b65c08dbffb
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
[9848:10684:1201/013233.172:ERROR:device_event_log_impl.cc(211)] [01:32:33.173] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
¿Alguien se enfrenta a lo mismo? ¿Hubo algún cambio en ChromeDriver/Chrome v87 con respecto a ChromeDriver/Chrome v86?
Cualquier pista será útil.
Sin embargo, se puede evitar que estos mensajes de registro aparezcan en la consola mediante un sencillo truco , es decir, agregando un argumento de add_experimental_option()la siguiente manera:
options.add_experimental_option('excludeSwitches', ['enable-logging'])
Bloque de código:
from selenium import webdriver
options = webdriver.ChromeOptions()
options.add_argument("start-maximized")
# to supress the error messages/logs
options.add_experimental_option('excludeSwitches', ['enable-logging'])
driver = webdriver.Chrome(options=options, executable_path=r'C:\WebDrivers\chromedriver.exe')
driver.get('https://www.google.com/')
Después de pasar por bastantes discusiones, documentaciones y problemas de Chromium, aquí están los detalles relacionados con la aparición del mensaje de registro:
[9848:10684:1201/013233.169:ERROR:device_event_log_impl.cc(211)] [01:32:33.170] USB: usb_device_handle_win.cc:1020 Failed to read descriptor from node connection: A device attached to the system is not functioning. (0x1F)
Detalles
Todo comenzó con el informe del problema de Chrome. Elimine la dependencia de WebUSB en libusb en Windows como:
- Para Linux (probablemente también Mac), tanto la notificación como la comunicación WebUSB funcionan correctamente (después de permitir el acceso del usuario al dispositivo en las reglas de udev).
- Para Windows, parece que libusb solo funciona con un controlador WinUsb no estándar ( https://github.com/libusb/libusb/issues/255 ).
Cuando se inserta el hardware y el sistema desconoce el VID/PID, Windows 10 carga correctamente su controlador CDC para la parte CDC y el controlador WinUSB (versión 10) para la parte WebUSB (sin señales de alerta). Sin embargo, parece que Chrome nunca encuentra el dispositivo hasta que fuerzo manualmente un controlador WinUSB anterior (versión 6, probablemente también modificado) en la interfaz.
La solución se implementó paso a paso de la siguiente manera:
- Comience a admitir algunas transferencias en el nuevo backend USB de Windows
- Reparar transferencias masivas/interrumpidas en el nuevo backend USB de Windows
- [usb] Leer descriptores BOS desde el controlador del concentrador en Windows
- [usb] Recopile todas las rutas de dispositivos compuestos durante la enumeración en Windows
- [usb] Eliminar parámetros en las funciones auxiliares de UsbServiceWin
- [usb] Admite dispositivos compuestos en el nuevo backend de Windows
- [usb] Detecta funciones USB a medida que Windows las enumera
- [usb] Admite dispositivos compuestos con múltiples funciones
- [usb] Retener las solicitudes de interfaz hasta que Windows enumere las funciones
- [usb] Agregar parámetro de dirección a ClearHalt
- [usb] Contar referencias a WINUSB_INTERFACE_HANDLE
- [usb] Implementar operaciones de bloqueo en el backend de Windows
Estos cambios garantizaron que el nuevo backend estuviera listo para ser probado y estuviera disponible a través de Chrome Canary y chrome-dev-channel al que puede acceder manualmente a través de:
chrome://flags#enable-new-usb-backend
Se enviaron más solicitudes de cambio de la siguiente manera:
- [usb] Marcar llamadas a SetupDiGetDeviceProperty como potencialmente bloqueantes : según los informes de bloqueo, esta función realiza una llamada RPC que puede tardar algún tiempo en completarse. Marque las llamadas con base::ScopedBlockingCall para que el grupo de subprocesos sepa que esta tarea puede estar ocupada por un tiempo.
- Variaciones: Habilite NewUsbBackend en la configuración de prueba de campo : esta bandera fue experimental ya que el canal beta usa esta configuración de cambio como predeterminada para las pruebas.
Como el lanzamiento experimental del nuevo backend parecía ser estable, finalmente esta configuración se habilitó de forma predeterminada para que el cambio se implemente para todos los usuarios de Chrome 87 a través de USB: Habilitar el nuevo backend USB de Windows de forma predeterminada . Revisión / Confirmación
La idea era que una vez que esta configuración se convirtiera en la predeterminada para algunos hitos, Chromium Team comenzaría a eliminar el código específico de Windows del antiguo back-end y eliminaría la bandera.
Camino por delante
El equipo de Chromium ya ha fusionado la revisión / compromiso para extender la caducidad del indicador de backend nuevo USB dentro de Chrome v90 , que estará disponible pronto.
Actualizar
Según el comentario de @ReillyGrant [Committer, WebDriver para Google Chrome] :
..."sería bueno reducir el nivel de registro de estos mensajes para que no aparezcan en la consola de forma predeterminada, pero aún no hemos obtenido el código para hacerlo"...
Referencias
Puede encontrar un par de discusiones detalladas relevantes en:
- No se pudo leer el descriptor de la conexión del nodo: un dispositivo conectado al sistema no funciona, error al usar ChromeDriver Selenium en el sistema operativo Windows
- No se pudo leer el descriptor de la conexión del nodo: un dispositivo conectado al sistema no funciona, error al usar ChromeDriver Chrome a través de Selenium
Mis disculpas por el spam de registros. Si no tiene problemas para conectarse a un dispositivo con WebUSB, puede ignorar estas advertencias. Se activan cuando Chrome intenta leer las propiedades de los dispositivos USB que están actualmente suspendidos.
