Unknown Usb Device Descriptor Request Failed Webcam
Derrick Drescher
In order to resolve this issue, your device or any other devices you want to connect with this same issue, I suggest you do this; Open the Windows PowerShell (Admin) and type: chkdsk /f/r/x. It will inform: 'The type of the file system is NTFS.
Cannot lock current drive.
Chkdsk cannot run because the volume is in use by another process. Would you like to schedule this volume to be
checked the next time the system restarts? (Y/N)' select Y then re-boot your machine and follow the on screen prompts.
After the reboot, again, Windows PowerShell (Admin) and type: sfc /scannow and allow the process to finish.
Now clean the registry with a reputable program such as CCleaner then take a note of the device/s name and select 'run' from the Windows menu list bottom left.
Type 'regedit' without the apostrophes and open the registry.
Select 'Edit' then Search... and type the brand name of the device in the search bar.
The search results will point you to a series of strings of the device that was giving the *(device descriptor request failed) code 43* error message.
Every string in the registry with the name of your device will need to be deleted but ensure it is the device's name from which was generating this error example; Logitech, Seagate, whatever brands device name that has generated this error code!
Ensure you have removed every last trace of your devices name in the registry.
Then after completion use the CCleaner again to remove all known traces and re-install the devices software if this is the case.
Your device will come back to life without the error message and start to work again.
Reasons why this happen are not entirely certain but often PC's pick up spyware/malware/virus's and corrupt the registry's strings other times, updates and upgrades in particular over lap information and again, corrupt the software and its registration process.
Selecting "USB xHCI Complaint Host Controller" the same issue but shows the "Intel(R) USB 3.0 eXtensible Host Controller - 1.0 (Microsoft)" on device manager. Selecting "Chipset Controller" installing the Chipset Controller on the device manager but the propery shows that "No drivers are installed for this device" . But "Unknown USB Device (Device Descriptor Request Failed" disappears but placing USB, the USB is not found.
Registry Disclaimer: The further steps will involve registry manipulation. Making mistakes while manipulating registry could affect your system adversely. So be careful while editing registry entries and create a System Restore point first.
SOLUTION!!
I posted in the Microsoft Community Groups about my problem. Someone asked to upload my mini dump logs, which I did and they saw that my Network card was causing the issue.
I took it to a computer repair shop and they ran their own tests and determined it was the network card in my laptop.
They took it out of my laptop and tested the chip on its down and it showed faults. The repairman inserted a new network card into the laptop and test everything and no errors.
Since then...
- No crashes
- No "unknown usb device descriptor request failed"
It's been giving me SO MUCH GRIEF these past 2 weeks.
I've uninstalled and reinstalled Bluetooth, WLAN, USB drivers and nothing seems to work.
Only temporary solutions where my Mouse (Bluetooth) will work for a couple minutes, hours, days before it randomly disappears and the 'unknown usb device descriptor request failed" appears and sometimes it crashes my computer, sometimes it doesn't.
I never touched the BIOS settings, but as i said before... i had thes Problems since i Updated the BIOS to Version 318, so i think this Update did some strange changes in the settings or maybe Version 317 has some settings that dont work with 318.. dont know, but it works for me now.
I bought this Asus laptop December 2019 and it worked smoothly til March 2022. Since then I've had to...
1) Replace the computer screen (one of the circuits in the monitor burned out)
2) Replaced my laptop charger (somehow the adapter kept shorting out my computer and making it shut off)
3) And now my Bluetooth works, and doesn't work. Found one solution where you have to go into the registry, and that worked. But now my computer randomly crashes and resets. Ughh.
Might be my last Asus...
This message usually appears when a system uses a certified bus-powered USB hub (hub power and power for all it's ports are coming from a single upstream cable from host). In this case the system knows (via hub descriptors) that this is bus-powered hub, and therefore it must have the natural limits of how much power can be theoretically taken from upstream, and delivered to downstream ports.
Therefore the bus-powered hubs are allowed to allocate only a fraction of power that is normally available from normal ports (500 or 900 mA) and from self-powered hubs (powered from external AC-DC adapters). To prevent the hub upstream port (host downstream) from overloading, USB has a two-step mechanism.
First step is an informative. USB devices must take only 100/150 mA from VBUS to respond with device descriptors. The device descriptor(s) have an information on how much current it is expecting to use under full-functional mode, its maximum. The system reads this information, and, knowing whether the hub can or can't (theoretically) supply this power, it may or may not proceed with final step of device configuration, SET_CONFIG(). If the system determines that the port does have enough power, it finishes the enumeration. If this is a bus-powered hub (100 mA per port), and device declares the use of 500 mA, the system won't proceed with configuration and will display the warning message. Thus the device will be rejected. Whether the device really consumes that current remains however unknown.
In fact, in USB 2.0 power management schema of things, the "high-power" device will not be admitted even if other ports don't have anything plugged in, and theoretically the hub might have enough resource to power it up. This is a major inconvenience from user standpoint. To avoid this inconvenience, USB industry has invented illegal "semi-self-powered" hubs, tyhe hubs who can be bus-powered, but don't report this in their descriptors, fooling the host system into thinking that this is a normal self-powered hub, so no restrictions will be imposed. The rest is up to user's lack or luck thereof.
So, it looks like you have a misfortune (or fortune) to have a certified USB hub that plays nicely, in accord with USB specifications. To avoid this messages either use a self-powered hub, or use the bootleg hubs that don't report their bus-powered status, and pray that the host port has enough power to drive whatever devices you are plugging into the hub without losing much of VBUS voltage level.
A possible cause might be one of the metal anti-RFI "fingers" in the I/O shield plate accidentally getting inside an USB port when installing the motherboard. Normally these "fingers" should only contact the metal shells of the connectors on the motherboard: they should never go inside the actual connector.
A solution to that is a self-powered usb hub which takes its power from an external power supply unit and can therefore provide full power (up to 500 mA) to every port. Depending on the number of usb devices you have to plug there's up to 16 ports and maybe even more...(from what i've seen in Google images)
c80f0f1006