We recently upgraded our Windows 10 test environment with ChromeDriver v87.0.4280.20 and Chrome v87.0.4280.66 (Official Build) (64-bit) and after the up-gradation even the minimal program is producing this ERROR log:
[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)
Minimum Code Block:
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/')
Console Output:
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)
Anyone facing the same? Was there any change in ChromeDriver/Chrome v87 with respect to ChromeDriver/Chrome v86?
Any clues will be helpful.
However these log messages can be supressed from appearing on the console through an easy hack i.e. by adding an argument through add_experimental_option() as follows:
options.add_experimental_option('excludeSwitches', ['enable-logging'])
Code Block:
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/')
My apologies for the log spam. If you aren't having issues connecting to a device with WebUSB you can ignore these warnings. They are triggered by Chrome attempting to read properties of USB devices that are currently suspended.
After going through quite a few discussions, documentations and Chromium issues here are the details related to the surfacing of the log message:
[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)
Details
It all started with the reporting of chromium issue Remove WebUSB's dependency on libusb on Windows as:
For Linux (probably Mac as well), both WebUSB notification and communication works correctly (after allowing user access to the device in udev rules).
For Windows, it seems that libusb only works with a non-standard WinUsb driver (https://github.com/libusb/libusb/issues/255).
When the hardware is inserted and the VID/PID is unknown to the system, windows 10 correctly loads it's CDC driver for the CDC part and the WinUSB driver (version 10) for the WebUSB part (no red flags). However, it seems that chrome never finds the device until I manually force an older WinUSB driver (version 6 - probably modified also) on the interface.
The solution was implemented in a step-wise manner as follows:
Start supporting some transfers in the new Windows USB backend
Fix bulk/interrupt transfers in the new Windows USB backend
[usb] Read BOS descriptors from the hub driver on Windows
[usb] Collect all composite devices paths during enumeration on Windows
[usb] Remove out parameters in UsbServiceWin helper functions
[usb] Support composite devices in the new Windows backend
[usb] Detect USB functions as Windows enumerates them
[usb] Support composite devices with multiple functions
[usb] Hold interface requests until Windows enumerates functions
[usb] Add direction parameter to ClearHalt
[usb] Count references to a WINUSB_INTERFACE_HANDLE
[usb] Implement blocking operations in the Windows backend
These changes ensured that the new backend was ready to be tested and was available through Chrome Canary and chrome-dev-channel which you can access manually through:
chrome://flags#enable-new-usb-backend
More change requests were submitted as follows:
[usb] Mark calls to SetupDiGetDeviceProperty as potentially blocking: According to hang reports this function performs an RPC call which may take some time to complete. Mark calls with a base::ScopedBlockingCall so that the thread pool knows this task may be busy for a while.
variations: Enable NewUsbBackend in field trial testing config: This flag was experimental as beta-channel uses this change configuration as the default for testing.
As the experimental launch of the new backend appeared to be stable, finally these configuration was enabled by default so that the chanege rolls out to all users of Chrome 87 through usb: Enable new Windows USB backend by default. Revision / Commit
The idea was once this configuration becomes the default for a few milestones, Chromium Team will start removing the Windows-specific code from the old back-end and remove the flag.
Road Ahead
Chromium Team have already merged the revision/commit to Extend new-usb-backend flag expiration within Chrome v90 which will be available soon.
Update
As per #ReillyGrant's [Committer, WebDriver for Google Chrome] comment :
..." it would be good to reduce the log level for these messages so they don't appear on the console by default but we haven't landed code to do that yet"...
References
You can find a couple of relevant detailed discussions in:
Failed to read descriptor from node connection: A device attached to the system is not functioning error using ChromeDriver Selenium on Windows OS
Failed to read descriptor from node connection: A device attached to the system is not functioning error using ChromeDriver Chrome through Selenium
I encounered this problem yesterday,and I has fixed it by update all available windows update.
https://support.microsoft.com/en-us/windows/what-to-try-if-your-touchscreen-doesn-t-work-f159b366-b3ef-99ad-24a4-31a4c62ab46d
A partial solution that worked for me
I was getting this error too. It was stopping my program running.
I unplugged all my USB devices, ran the program, with no error.
Plugged the devices back in, ran the program. I am still getting the error, however, the program finished without the error stopping the program.
Note: For WebdriverIO on Windows 10, this suppresses the error messages for me:
"goog:chromeOptions": { "excludeSwitches": ["enable-logging"] }
I have been trying to locate a working library for the MSR605X magnetic card reader/writer. At time of writing, I have tried five separate libraries. Only two of these were explicitly for the 605X the other three were for the older 605. All the libraries I have tried either did nothing at all or errored before completing a command (can't figure out the errors either).
I am running Raspberry Pi OS 32 bit on a Raspberry Pi 3 B+ the MSR605X communicates via a USB connection.
So far the library that seems to be most complete is: https://pypi.org/project/msrx/
However, I can not get this library to read or write (either nothing happens or I get a Serial exception "cannot reconfig port).
Any help or links to documentation for this reader is welcome.
EDIT: Adding the commands ran with the above library
msrx -D /dev/input/event4 read
msrx -D /dev/input/jso0 read
The -D is to specify the device path (default is /dev/ttyUSB0 which doesn't exist on my system). I obtained the above two paths by searching for USB serial devices then matching the search result to the device ID which I obtained from lsusb.
Running these commands results in a serial exception (could not reconfig port) which I assume means that I have the wrong device path. I have also checked for any tty* device paths that are changed when I plug in the reader. I consistently get a permission denied error whenever trying to run the above commands with a tty* device path (I am root on this system).
msrx author here — MSR605 requires an external 9V power injected into its cable (via the barrel jack port), otherwise it won't power up properly.
I'm trying to get MSI-X working on an iMX6 (Freescale/NXP/Qualcomm) CPU in Linux v4.1 for a PCIe character device driver. Whenever I call either pci_enable_msix() or pci_enable_msix_range() or pci_enable_msix_exact() I get an EINVAL value returned. I do have the CONFIG_PCI_MSI option selected in the kernel configuration and I am also able to get single MSI working with pci_enable_msi(), but I cannot get multiple MSI working either.
I have tested my driver code on an Intel i7 running kernel v3 with the same PCIe hardware attached and I was able to get MSI-X working without any problems so I know my code is correctly written and the hardware is correctly functioning.
When running on the iMX6 I can use lspci -v to view that the hardware has MSI-X capabilities and see the number of IRQs it allows. I can even get the same correct number in my driver when calling pci_msix_vec_count().Questions
Are there any other kernel configuration flags I need to set?
Is there anything specific to the iMX6 CPU I need to consider?
Does anyone have any experience with the iMX6 and either MSI-X or
multiple MSI?
I am currently developing a small OS on my Raspberry Pi, that I install by replacing the kernel.img file on the /boot partition of my SD card. By the time my code is run, the CPU is already in Normal Mode, so I can't have access to the Secure world / Trustzone area.
Is it possible to modify the boot process of the Raspberry to be able to start executing my code in Secure mode ?
Best,
V.
In fact you don't have to do anything but stop being stupid like me.
As explained here:
https://raspberrypi.stackexchange.com/questions/14953/is-it-possible-to-boot-the-raspberry-pi-in-secure-mode
When the NS bit of the SCR register is 0, it means that you are in Secure Mode, which is the case at boot on my Raspberry. I had the meaning of this bit backwards, sorry !
I need the certificate from my smart card to be in the Windows service local sotre. I opened the store with mmc -> snap-in -> certificates.
I used different little tools to see informations(ATR etc.) about my smartcard and they all worked out.
I can see a lot of certificates there, but the one from my smartcard is missing in the store. The folder 'Smartcard trusted Roots' is empty. Windows gets the .cer/.pfx-data from smart cards automatically, right?
Or is there no chance, i can do it without using low-level programming(APDU-commands etc.)
First read this:
http://technet.microsoft.com/en-us/library/ff404288(v=WS.10).aspx
As it's written
A logged-on user inserts a smart card.
CertPropSvc is notified that a smart card was inserted.
CertPropSvc reads all certificates from all inserted smart cards. The certificates are written to the user's personal certificate store
So yes, gnerally certificates should pop up in User Personal Certificate Store automatically.
First thing to check is that you have CertPropSvc service runnig.
Another thing that I saw that some smart cards drivers doesn't work with Windows API. One example I know was old RSA tokens. We have changed them to Gemalto .NET cards and USB readers because of this
Note: In the artcle I linked it's written that this is valid for Windows 7 and 2008 but it worked for me on XP and Vista.