Mega 2560 installs as incorrect device under XP SP3 - problem and solution

I’ve spent a couple of days banging my head against the wall trying to sort this one out. Installing the serial drivers for the Mega 2560 under XP SP3 - each and every time, they would identify as “USBDeviceShare USB Device Stub” with no associated COM port number, making it impossible to program the board.

I eventually got to the bottom of it. Searching for the problem itself didn’t produce anything helpful, and I eventually had to go off on a few tangents. I’m hoping that by posting this, I’ll save someone else the trouble.

A bit of digging around finds that USBDeviceShare is part of a commercial application that I’ve never owned or installed. Further digging suggests that some driver update programs install this driver when they shouldn’t., and I’m guessing that’s what’s happened to me. As it turns out, Windows ranks this as a more compatible driver than the one supplied with the Arduino SDK, and so installs it in preference.

The secret of what’s going on lies in c:\windows\setupapi.log, which handily logs the decision making process that Windows goes through when selecting a driver. It’s a big file, but here’s the relevant bit

#-019 Searching for hardware ID(s): usb\vid_2341&pid_0042&rev_0001,usb\vid_2341&pid_0042
#-018 Searching for compatible ID(s): usb\class_02&subclass_02&prot_01,usb\class_02&subclass_02,usb\class_02
#W383 "oem136.PNF" migrate: PNF Language = 0409, Thread = 0809.
#I022 Found "USB\Class_02" in C:\WINDOWS\inf\oem136.inf; Device: "USBDeviceShare USB Device Stub"; Driver: "USBDeviceShare USB Device Stub"; Provider: "SysNucleus"; Mfg: "(Standard system devices)"; Section name: "USBShare_Device".
#I087 Driver node not trusted, rank changed from 0x00002002 to 0x0000a002.
#I023 Actual install section: [USBShare_Device.NT]. Rank: 0x0000a002. Effective driver date: 06/12/2012.
#W383 "oem154.PNF" migrate: PNF Language = 0409, Thread = 0809.
#I022 Found "USB\VID_2341&PID_0042" in C:\WINDOWS\inf\oem154.inf; Device: "Arduino Mega 2560"; Driver: "Arduino Mega 2560"; Provider: "Arduino LLC ("; Mfg: "Arduino LLC ("; Section name: "DriverInstall".
#I087 Driver node not trusted, rank changed from 0x00000001 to 0x0000c001.
#I023 Actual install section: [DriverInstall]. Rank: 0x0000c001. Effective driver date: 01/01/2013.
#-166 Device install function: DIF_SELECTBESTCOMPATDRV.
#I063 Selected driver installs from section [USBShare_Device] in "c:\windows\inf\oem136.inf".
#I320 Class GUID of device remains: {B85B7C50-6A01-11D2-B841-00C04FAD5171}.
#I060 Set selected driver.
#I058 Selected best compatible driver.

From the above, it’s finding the “USBDeviceShare” driver and assigning it a rank of a002. It’s also finding the Arduino driver and assigning it a rank of c001. Since the lowest rank becomes the chosen driver, it installs the wrong one.

Since the log also shows the INF and PNF files used, it simply becomes a matter of deleting (or temporarily moving) the offending files (in this case oem136.inf and oem136.pnf) from c:\windows\inf and re-attempting the driver install. It should install correctly this time around.

In this instance, a signed driver would probably have sorted the problem out too, since it would outrank the unsigned USBDeviceShare driver.

Thank you for posting about your experience.