[Droid Eris Android Development] bftb0:
Dunno what to tell you. A while back, I did a lot of USB "sniffing", but mostly on Linux. (The Windows machine I was using at the time is toast - lemme look through my notes).

The thing is, if mounting the SD card works from the PC, you know that all the hardware is OK (The PC USB hardware I/F, the cable, and the Phone USB hardware I/F)

In the device manager under Windows, if you explore (one by one, it's tedious) under each device under each Universal Serial Bus Controller, and look at the device properties -> Details (tab), if you select the item "Device Instance Id" (or "Device Hardware IDs") you will see a string which is similar to:

PCI\VEN_106B&DEV_003F&SUBSYS_00000000&REV_00\3&267A616A&0&30

or

USB\VID_0BB4&PID_0C98

The identifiers which follow "VEN_", "DEV_" (or "VID_"/"PID_")are supposed to produce a globally unique value, which allows a PC (Windows for example) to identify the exact hardware that is on the USB bus at that bus address. This is the principle which allows Windows or other OS'es a means to match up a driver to a USB device.

The two things that most people don't realize about USB devices are that:

(1) The USB device is allowed to reconfigure itself onto a different (unique) Device Identifier, and

(2) A single USB device on the bus with a given Device_Identifier is allowed to advertise multiple logical "endpoints".

This allows multifunction devices like printers with an SD card reader to operate simultaneously over a single cable; it can also means that a given USB peripheral might have several drivers.

The Eris pulls both of these stunts, depending on what mode it is in.

The Vendor_ID will be "0BB4", an the three possible Device_IDs will be "0C98", "0FFF", or "0FF9"

With the phone in Fastboot mode, if you find a device in your hardware manager which is something like

VID_0BB4&PID_0FFF

and yet you still can not communicate with fastboot, then the problem is certainly a driver issue with Windows, and you are going to have to bone up on how to identify and remove individual drivers.

Perversely, if you try to uninstall a driver in Windows with the device attached, Windows will helpfully try to re-install any matching driver you have on your hard drive - usually the same one you are trying to remove. On the other hand, if the device is not attached to the PC, the windows device manager will "hide" those device entries from you. So, the trick is to get the Windows device manager to display ALL drivers. (The process is quite similar in both Win7 and Xp - you have to set an environment variable and also toggle a setting in the Device Manager) And there will be a $hitload of them for USB. You have to pick through that list and find the drivers matching

0BB4:0C98

0BB4:0FFF

0BB4:0FF9

and then manually uninstall and re-install drivers from whatever choice you deem appropriate (HTC Sync, Official 2.1 RUU, or the Android SDK).

[SIZE=+1]WARNING: Don't DELETE the generic "Mass Storage Device" driver file - that is a MS Windows generic driver, widely used! For any driver you plan to DELETE FROM THE HARD DRIVE, it should be obvious from looking at the device driver details that it is a HTC driver, NOT A MICROSOFT DRIVER[/SIZE]

(A short explanation of the above is needed here - many devices can use a single (generic "class") driver, so I believe that UNINSTALLING the driver is not the same as DELETING the driver file, as in "deleting the file from the hard drive" - "UNINSTALLING" in Windows merely breaks the association between that driver file and the particular piece of hardware in the Windows registry - Sometimes though, it becomes necessary to DELETE the driver file so that Windows will no longer find it when it automatically searches for matching drivers. My point in the above is that if you find want to DELETE a driver file, make sure it is an HTC driver - it should always be OK to "Uninstall" the driver)

I did it with the Android SDK driver about 5 months ago - on a Win 7 x64 machine. The ".INF" file provided by the "Android SDK USB driver" didn't have the correct entries in it, and I had to manually hack that .INF file before it took. (If you are not using x64, your life might be easier).

I think I posted this information before - it shows which Vendor/Device IDs show up depending on the state of the Eris, and also which "logical endpoints" are available at each Vendor/Device combo for that particular phone state.

Enjoy if you are able.

#1) Condition: Booted Leak-V1, debugging ON, SD export off
#2) Condition: Booted Leak-V1, debugging OFF, SD export off
#3) Condition: Booted Leak-V1, debugging OFF, SD export ON
#4) Condition: Booted Leak-V1, debugging ON, SD export ON
#5) Condition: FASTBOOT-USB Mode
#6) Condition: HBOOT MODE
#7) Condition: Leak-V1 recovery boot
#8) Condition: RUU/OEM-78 Mode
#9) Condition: Amon_RA recovery boot (no USB-MS)
#10) Condition: Amon_RA recovery boot (with USB-MS)

COND VEND:PROD #INT MANUF. PRODUCT CLASS:SUBCLASS:PROTO:INTERFACE(Endpoints)

1 0bb4:0c98 2 HTC	Android Phone 8:6:80:4(0x01,0x81), 255:66:1:5(0x02,0x82)
2 0bb4:0ff9 1 HTC	Android Phone 8:6:80:4(x01,x81)
3 0bb4:0ff9 1 HTC	Android Phone 8:6:80:4(x01,x81)
4 0bb4:0c98 2 HTC	Android Phone 8:6:80:4(x01,x81), 255:66:1:5(x02,x82)
5 0bb4:0fff 1 htc, Inc	Android 1.0 255:66:3:0(x01,x81)
6 0bb4:0fff 1 -	- 255:66:3:0(x01,x81)
7 0bb4:0ff9 1 HTC	Android Phone 8:6:80:4(x01,x81)
8 0bb4:0fff 1 htc, Inc	Android 1.0 255:66:3:0(x01,x81)
9 0bb4:0c98 2 HTC	Android Phone 8:6:80:4(x01,x81), 255:66:1:5(x02,x82)
10 0bb4:0c98 2 HTC	Android Phone 8:6:80:4(x01,x81), 255:66:1:5(x02,x82)

Key:

8:6:80:4() : Mass Storage:SCSI:Bulk (Zip):Mass Storage
255:66:1:5() : Vendor Specific Class:66:1:5 ADB
255:66:3:0() : Vendor Specific Class:66:3:0