Winusb.inf

0 views

Skip to first unread message

Algernon Alcala

unread,

Aug 3, 2024, 5:34:38 PM8/3/24

to goyfundmesga

I found this, which isn't really universal since it defines a bunch of specific device IDs to identify them and is outdated anyway. There's also this pull request posted on that project's GitHub page and also another repo containing a dead link to already singed driver (or more precisely, signed INF that identifies ADB interface by the universal compatible ID).

So what are my options? Anyone found such a driver/INF that can be just installed and forgotten about or do I have to go the signing the modified android_winusb.inf with self-signed certificate route if I don't want to disable driver signature enforcement and such?

So far, my phone has used like 6 different device IDs to identify itself and under certain circumstances, I even have to re-install the official driver/INF for it to work again and confirming that I do want it installed, even if device ID doesn't match.

Thanks, I didn't look in system winusb.inf and manufacturer supplied INF must have been downloaded from Windows Update, placing the entry in Device Manager that usually appears under Universal Serial Bus devices under a different category, so I didn't realize it was already supported out-of-the-box.

I use Win10 versions 1809 and 1909 on my two machines. Depending on the software currently running on the phone, hardware ID differs, so who knows which is the "right" one. Vendor ID is always VID_0FCE, as should be.

That problem requiring re-install was actually encountered when putting the phone in fastboot mode. I suspect a conflict happened due to an old entry having a different compatible ID (adb vs fastboot and the fact that fastboot ID is missing from winusb.inf), but the same vendor and device ID. The ID when in fastboot mode is constant, but otherwise it seems to depend on the OS running, even though it should be constant as well as long as we're talking about the same phone model, in this case Xperia E3.

I did some cleaning up in Device Manager and removed two drivers that were downloaded from Windows Update for ADB, so now I have phone's entries under Universal Serial Bus devices, not under some custom categories like before. I also added USB\Class_FF&SubClass_42&Prot_01 ID to the list of Prevent installation of devices that match any of these devices ID group policy, so the OS won't try "updating" them. Manually installing ADB Device through update wizard in Device Manager while phone is in fastboot mode also works and makes it visible to fastboot utility.

The device ID when in fastboot mode is VID_0FCE&PID_0DDE, so that *.inf couldn't help the OS detect it as compatible with the driver. But you can still set it for use with fastboot mode by manually selecting it in driver update wizard.

It's good that at least for ADB mode, it works out of the box either way. Though by default settings, OS might still see fit to download "drivers" from Windows Update, even though no specialized driver is usually involved since it's all just about the .inf file identifying and setting up the device to be driven using winusb.sys.

Xperia Manufacturer offers Emma to flash a device.
Emma dosn't use fastboot mode, flashmode is used instead.
Emma does use a Gordons Gate driver ggsomc.sys, signed by 'Sony Mobile Communications AB'.
-devices/get-started/flash-tool/download-flash-tool/

It looks like clearing old entries in Device Manager that was setup by INF file that came with those drivers from Windows Update, deleting said drivers, setting up fastboot device entry using device update wizard and picking built-in ADB Device helped with the issue of the said device entry for fastboot mode being reset under certain circumstances.

I decided to Google this and see if there are other devices that have the same Hardware ID so I could install that driver and check if it works. Miraculously, it took me to a page on XDA Developers where there was someone who got their device (A Nexus S) to work by changing the android/_winusb.inf file located in the android-sdks/extras/google/usb/_driver folder.

On the desktop, checking the services, does not have a Thunderbolt Service listed. G-Raid is not listed as an available storage device in Disk Manager. Going into Devices and Printers lists a new device under Unspecified called G-RAID Thunderbolt 3 USB 3.1, but nothing can be done with it except remove the device or view the properties. Checking the properties shows that the driver being used is winusb.inf, and that the device is working properly. To verify that the Thunderbolt 3 / USB 3.1 port is functioning properly on the desktop, I did plug a Thunderbolt 3 LaCie hard drive in, which was detected and allowed me to view the contents.

Based on the motherboard you mentioned it looks like it does not have Thunderbolt 3 but it does have USB 3.1 type C. So as long as you are attaching the drive via that connection on the back of the drive and not the Thunderbolt ones it should be recognized just fine and not require any special drivers.

I'm a huge fan of the Nexus 7, but one of the things that annoyed me from day one was the lack of landscape support on the homescreen. I almost always use the tablet in landscape mode, so when switching to an app I didn't already have in the open/recent apps list, I would have to hit the Home button; which flipped everything around temporarily. There was already a user-set orientation lock, and we knew Android could handle it (from other devices, and those with rooted devices changing build properties), so it always seemed like a really random restriction.

This was announced as fixed in Android 4.1.2, which began rolling out only a few days ago. As of this evening, my device still showed no update, so after finding some instructions, I decided to load the update myself.

These instructions do *not* require you to root your device or unlock the bootloader. If your device is unlocked/rooted, I have no idea what affect that might have on this process. If you're unsure about this, don't do it. I accept no liability if you mess things up. I have only limited knowledge of Android! The steps seemed fairly straight forward, which is the only reason I was attempting them!

My first problem was that I was unable to boot into recovery mode using the instructions. When I selected Recovery Mode from the boot menu, my device just booted normally. I didn't get the Android with the red exclamation mark. This was easily fixed by using adb (installed as part of the Android SDK) and running:

The problem was, once in this mode, Windows failed to recognise the decide/load the drivers that were previously loaded (before the reboot), which meant adb would no longer be able to connect the device:

After a lot of searching online, I figured out that the problem was that the Hardware ID of my Nexus 7 when in recovery mode was not listed in "android_winusb.inf" file from the Google Android Windows USB Drivers. The ID I saw in device manager against the Nexus was USB\VID_18D1&PID_D001, which didn't turn a lot up in Google!

I decided to try adding this to the inf file manually (C:\Program Files (x86)\Android\android-sdk\extras\google\usb_driver\android_winusb.inf). As I'm running on a 64bit machine, I added the following to the [Google.NTamd64] section (note: this applies to Intel 64 bit machines, not just AMDs!). If you're using 32bit, you'd want to add it to the [Google.NTx86] section:

After making this change, I uninstalled the device drivers, then reinstalled them using this inf file. I once again rebooted into Recovery mode, and this time, Windows correctly displayed the device as "Android ADB Interface", and I was then able to sideload the Android 4.1.2 update (downloaded directly from Google) by typing: