USB Driver Install Problem

NTDEV
1

I have a basic driver that I use for a USB barcode scanner.
I install the driver with an *.inf (below) and it works well.
The Barcode scanner is a HID device, and my driver is used in preference to the HID driver, based on the VID/PID of the scanner.

This is my problem:
I have multiple USB ports on the PC.
I can connect the USB scanner to say port A, install my driver, that works fine.
However, if I move the USB Scanner to USB port B, the OS loads up the HID driver instead.
If I move to USB Scanner back to port A, the OS loads my driver.

Why do I get this behavior, and is there any way to install my driver once, so it is used for the USB Scanner no matter which port I connect it to?

I’d appreciate any pointers.

Thanks

Chris

; =============== BarcodeScanner inf for Win32

[Version]
Signature = “$Windows NT$”
Class=BarcodeScanner
ClassGuid={5A382F44-3B36-463e-9414-5400B25D92FD}
Provider=%MyCo%
CatalogFile=unknown.cat
DriverVer= 7/1/2007

; ================= Class section =====================

[ClassInstall32]
Addreg=BarcodeScannerClassReg

[BarcodeScannerClassReg]
HKR,0,%ClassName%
HKR,Icon,-20

[DestinationDirs]
BarcodeScanner.Files.x86_12 = 12

[SourceDisksNames.x86]
1=%Desc_x860%

[SourceDisksNames.ia64]

[SourceDisksFiles.x86]
BarcodeScanner_2_0.sys=1,.,
wdfcoinstaller01007.dll=1,.,

[SourceDisksFiles.ia64]

[Manufacturer]
%MyCo%=MyCo

[MyCo]
;;============ Add Additional Hardware IDs Here ========================
%BarcodeScannerDesc%=BarcodeScanner_Inst,USB\Vid_FFFF&Pid_0001,

[BarcodeScanner_Inst.ntx86]
CopyFiles = BarcodeScanner.Files.x86_12

[BarcodeScanner_Inst.ntx86.Services]
AddService = BarcodeScanner1,0x00000002,BarcodeScanner_Service_Instx86

[BarcodeScanner_Service_Instx86]
ServiceType = %SERVICE_KERNEL_DRIVER%
StartType = %SERVICE_DEMAND_START%
ErrorControl = %SERVICE_ERROR_IGNORE%
ServiceBinary = %12%\BarcodeScanner_2_0.sys

[BarcodeScanner.Files.x86_12]
BarcodeScanner_2_0.sys

;[BarcodeScanner_EventLog_Inst]
;AddReg = BarcodeScanner_EventLog_Inst.AddReg

;[BarcodeScanner_EventLog_Inst.AddReg]
;HKR,EventMessageFile,%REG_EXPAND_SZ%,“%%SystemRoot%%\System32\IoLogMsg.dll”
;HKR,TypesSupported,%REG_DWORD%,7

[Strings]

; *******Localizable Strings*******
MyCo= “MyCo”
Desc_x860= “MyCo USBdrivers”
ClassName=“BarcodeScanner”

; *******Non Localizable Strings*******

SERVICE_BOOT_START = 0x0
SERVICE_SYSTEM_START = 0x1
SERVICE_AUTO_START = 0x2
SERVICE_DEMAND_START = 0x3
SERVICE_DISABLED = 0x4

SERVICE_KERNEL_DRIVER = 0x1
SERVICE_ERROR_IGNORE = 0x0
SERVICE_ERROR_NORMAL = 0x1
SERVICE_ERROR_SEVERE = 0x2
SERVICE_ERROR_CRITICAL = 0x3

REG_EXPAND_SZ = 0x00020000
REG_DWORD = 0x00010001

;;===== My Device Custom Name ====?
BarcodeScannerDesc= “BarcodeScannerDevice”

;
;— Device Coinstaller installation ------
;

[BarcodeScanner_Inst.ntx86.CoInstallers]
AddReg=BarcodeScanner_Inst_CoInstaller_AddReg
CopyFiles=BarcodeScanner_Inst_CoInstaller_CopyFiles

[DestinationDirs]
DefaultDestDir = 12
BarcodeScanner_Inst_CoInstaller_CopyFiles = 11

[BarcodeScanner_Inst_CoInstaller_AddReg]
HKR,CoInstallers32,0x00010000, “WdfCoInstaller01007.dll,WdfCoInstaller”

[BarcodeScanner_Inst_CoInstaller_CopyFiles]
WdfCoInstaller01007.dll

[BarcodeScanner_Inst.ntx86.Wdf]
KmdfService = BarcodeScanner_Inst, BarcodeScanner_Inst_wdfsect
[BarcodeScanner_Inst_wdfsect]
KmdfLibraryVersion = 1.7

2

I don’t do ‘inf’, it is too damn tedious, but if your driver package
is unsigned then the inbox driver that is signed will always be
preferred, even if your inf is a better match otherwise.

Test sign your driver package, put the system in test signing mode
(assuming a vista or later release) and try again.

Mark Roddy

On Sat, Aug 29, 2009 at 11:36 AM, wrote:
> I have a basic driver that I use for a USB barcode scanner.
> I install the driver with an *.inf (below) and it works well.
> The Barcode scanner is a HID device, and my driver is used in preference to the HID driver, based on the VID/PID of the scanner.
>
> This is my problem:
> I have multiple USB ports on the PC.
> I can connect the USB scanner to say port A, install my driver, that works fine.
> However, if I move the USB Scanner to USB port B, the OS loads up the HID driver instead.
> If I move to USB Scanner back to port A, the OS loads my driver.
>
> Why do I get this behavior, and is there any way to install my driver once, so it is used for the USB Scanner no matter which port I connect it to?
>
> I’d appreciate any pointers.
>
> Thanks
>
> Chris
>
> ; =============== BarcodeScanner inf for Win32
>
> [Version]
> Signature = “$Windows NT$”
> Class=BarcodeScanner
> ClassGuid={5A382F44-3B36-463e-9414-5400B25D92FD}
> Provider=%MyCo%
> CatalogFile=unknown.cat
> DriverVer= 7/1/2007
>
> ; ================= Class section =====================
>
> [ClassInstall32]
> Addreg=BarcodeScannerClassReg
>
> [BarcodeScannerClassReg]
> HKR,0,%ClassName%
> HKR,Icon,-20
>
>
> [DestinationDirs]
> BarcodeScanner.Files.x86_12 = 12
>
> [SourceDisksNames.x86]
> 1=%Desc_x860%
>
> [SourceDisksNames.ia64]
>
>
> [SourceDisksFiles.x86]
> BarcodeScanner_2_0.sys=1,.,
> wdfcoinstaller01007.dll=1,.,
>
> [SourceDisksFiles.ia64]
>
>
> [Manufacturer]
> %MyCo%=MyCo
>
> [MyCo]
> ;;============ Add Additional Hardware IDs Here ========================
> %BarcodeScannerDesc%=BarcodeScanner_Inst,USB\Vid_FFFF&Pid_0001,
>
>
>
> [BarcodeScanner_Inst.ntx86]
> CopyFiles = BarcodeScanner.Files.x86_12
>
> [BarcodeScanner_Inst.ntx86.Services]
> AddService = BarcodeScanner1,0x00000002,BarcodeScanner_Service_Instx86
>
> [BarcodeScanner_Service_Instx86]
> ServiceType = %SERVICE_KERNEL_DRIVER%
> StartType = %SERVICE_DEMAND_START%
> ErrorControl = %SERVICE_ERROR_IGNORE%
> ServiceBinary = %12%\BarcodeScanner_2_0.sys
>
>
> [BarcodeScanner.Files.x86_12]
> BarcodeScanner_2_0.sys
>
> ;[BarcodeScanner_EventLog_Inst]
> ;AddReg = BarcodeScanner_EventLog_Inst.AddReg
>
> ;[BarcodeScanner_EventLog_Inst.AddReg]
> ;HKR,EventMessageFile,%REG_EXPAND_SZ%,“%%SystemRoot%%\System32\IoLogMsg.dll”
> ;HKR,TypesSupported,%REG_DWORD%,7
>
>
> [Strings]
>
> ; ? Localizable Strings
> MyCo= “MyCo”
> Desc_x860= “MyCo USBdrivers”
> ClassName=“BarcodeScanner”
>
> ; ? Non Localizable Strings
>
> SERVICE_BOOT_START = 0x0
> SERVICE_SYSTEM_START = 0x1
> SERVICE_AUTO_START = 0x2
> SERVICE_DEMAND_START = 0x3
> SERVICE_DISABLED = 0x4
>
> SERVICE_KERNEL_DRIVER = 0x1
> SERVICE_ERROR_IGNORE = 0x0
> SERVICE_ERROR_NORMAL = 0x1
> SERVICE_ERROR_SEVERE = 0x2
> SERVICE_ERROR_CRITICAL = 0x3
>
> REG_EXPAND_SZ = 0x00020000
> REG_DWORD = 0x00010001
>
> ;;===== My Device Custom Name ====?
> BarcodeScannerDesc= “BarcodeScannerDevice”
>
>
> ;
> ;— Device Coinstaller installation ------
> ;
>
>
> [BarcodeScanner_Inst.ntx86.CoInstallers]
> AddReg=BarcodeScanner_Inst_CoInstaller_AddReg
> CopyFiles=BarcodeScanner_Inst_CoInstaller_CopyFiles
>
> [DestinationDirs]
> DefaultDestDir = 12
> BarcodeScanner_Inst_CoInstaller_CopyFiles = 11
>
> [BarcodeScanner_Inst_CoInstaller_AddReg]
> HKR,CoInstallers32,0x00010000, “WdfCoInstaller01007.dll,WdfCoInstaller”
>
> [BarcodeScanner_Inst_CoInstaller_CopyFiles]
> WdfCoInstaller01007.dll
>
> [BarcodeScanner_Inst.ntx86.Wdf]
> KmdfService = BarcodeScanner_Inst, BarcodeScanner_Inst_wdfsect
> [BarcodeScanner_Inst_wdfsect]
> KmdfLibraryVersion = 1.7
>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>

3

> I have multiple USB ports on the PC.

I can connect the USB scanner to say port A, install my driver, that works fine.
However, if I move the USB Scanner to USB port B, the OS loads up the HID driver instead.
If I move to USB Scanner back to port A, the OS loads my driver.

It’s not your INF causing this, “this behavior is by design”.

Recommendation: Add a (device-unique) USB “Serial number string
descriptor” to your USB device descriptor (if you can).

Here is why:

(Case A) If your USB device does not have the USB “Serial number” string
set, Windows uses the “USB tree position” to uniquely identify the device.

Any installed driver is assigned to that DEVICE TYPE at that TREE POSITION.

Advantage1: If you plug another USB device of the same type (without USB
“Serial number” string) to the same port, you don’t need to install
anything, Windows will use the same driver.

Advantage2: For the same USB device type, you can actually have
different drivers for using the ame device on different USB ports.
(Good for testing, e.g. KMDF/UMDF/WDM driver alernatives.)

Disadvantage: If you plug your device to a “new” USB tree position (e.g.
using another root port, or by adding a USB hub and plugging the device
in there), you need to install your driver again.

(Case B) If your USB device does have a USB “Serial number” string,
the driver is installed for that SPECIFIC DEVICE with that serial number:

Advantage: Your installed driver will be used if you plug your device
into any USB port.

Disadvantage: You need to install the driver again if you have a second
device (of the same type) with a different USB “Serial number” string.

Warning: One promising looking hack to ‘solve’ your problem would be to
use the same USB “Serial number” string for all identical devices.
However, this is very risky: if your customer ever uses two or more of
your USB devices (=both with the same USB “Serial number” string!), this
will confuse the Windows driver system and certainly invite crashes.

Solution (as by MS): WHQL-certify your driver - then you can have a
“silent install”. As Mark already pointed out, in your case this might
be the only real solution: a WHQL-certified (e.g., ‘inbox’) driver takes
precedence over a non-WHQL one, and a signed driver takes precedence
over a non-signed one. If your USB device IDs/CLASSes resemble anything
“inbox”, this is likely the only clean way.

Solution (@todo for MS): Make driver selection for install based on
device type, not based on the device position or instance:
The installer should select the USB driver for a new device based on USB
“idVendor”, “idProduct” and “bcdDevice” IDs, not on “serial number
string” or “USB tree position”.
(The current system is like having to install a new graphics card driver
because you changed the Video cable. For end-users, USB is like a
“cable”, they don’t give a toss about the specific port used.)

USB info links:
http://www.beyondlogic.org/usbnutshell/usb5.htm#DeviceDescriptors
http://www.usb.org/developers/docs/

4

Hagen Patzke wrote:

Solution (@todo for MS): Make driver selection for install based
on device type, not based on the device position or instance:
The installer should select the USB driver for a new device based
on USB “idVendor”, “idProduct” and “bcdDevice” IDs, not on “serial
number string” or “USB tree position”.

How many times are you going to complain about this? Doron and others have already explained to you many times why and how it is a non-starter.

5

[Device installer and USB]

On 8/31/2009 1:42 AM, xxxxx@gmail.com wrote:

How many times are you going to complain about this?

Whenever someone else runs into it and asks for the reason.

Doron and others have already explained to you many times why and how
it is a non-starter.

Sorry, Chris, but this comment indicates to me you did not fully
understand the problem nor the replies to my posts about it.

6

Hagen Patzke wrote:

Solution (@todo for MS): Make driver selection for install based on
device type, not based on the device position or instance:
The installer should select the USB driver for a new device based on USB
“idVendor”, “idProduct” and “bcdDevice” IDs, not on “serial number
string” or “USB tree position”.

The system DOES select the USB driver for a new device based on the
vendor and product IDs. Neither serial number nor USB tree position
plays a role in that selection.

The situation you’re talking about is strictly in identifying a SPECIFIC
device – a physical piece of hardware. It’s not about assigning a
driver, it’s about maintaining information about a SPECIFIC device.
Every physical device maps to one position in the registry, where all of
its pertinent information is stored. That information is not shared
between multiple instances. If you have 3 identical web cameras, you
have 3 nodes in the registry.

When a device arrives, the system first looks to see whether it knows
about this specific piece of hardware. In that search, it does use the
serial number or USB tree position. Given an operating system that
requires a unique node for each physical device, what other mechanism
would you use to ensure uniqueness?

After it has determined that this specific piece of hardware has never
been seen before, then it falls back to using the vendor and product IDs
to locate an appropriate driver, which it uses to build a new registry node.

With any other mechanism, you would break the uniqueness guarantee if
you plugged in two devices with the same VID and PID but without serial
numbers. There would be no way to distinguish between them.

(The current system is like having to install a new graphics card driver
because you changed the Video cable.

A more appropriate metaphor would be “because you moved it to a new PCI
slot,” and I believe you’ll find the behavior in that case is exactly
the same as with USB, and for exactly the same reason. However, all of
the graphics drivers you are likely to encounter are WHQL-signed, so you
don’t notice this extra lookup. That’s not the case for USB drivers.

For end-users, USB is like a “cable”, they don’t give a toss about the specific port used.)

Perhaps, but the operating system needs to know. And, for gosh sakes,
we’re talking about a 30-second interruption in the user’s workflow.
I’m certainly not convinced this is an inconvenience that merits a
redesign of the device manager.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

7

xxxxx@cox.net wrote:

I have a basic driver that I use for a USB barcode scanner.
I install the driver with an *.inf (below) and it works well.
The Barcode scanner is a HID device, and my driver is used in preference to the HID driver, based on the VID/PID of the scanner.

This is my problem:
I have multiple USB ports on the PC.
I can connect the USB scanner to say port A, install my driver, that works fine.
However, if I move the USB Scanner to USB port B, the OS loads up the HID driver instead.
If I move to USB Scanner back to port A, the OS loads my driver.

Why do I get this behavior, and is there any way to install my driver once, so it is used for the USB Scanner no matter which port I connect it to?

If you have a complete driver for your device, so that you don’t need
the Microsoft USB HID stack at all, then all you need to do is change
your device descriptor so that you describe yourself as a vendor-class
device, instead of a HID-class device. That way, the system will never
try to load the stock HID driver.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

Tim Roberts wrote:

The situation you’re talking about is strictly in identifying a SPECIFIC
device – a physical piece of hardware. It’s not about assigning a driver,
it’s about maintaining information about a SPECIFIC device. Every physical
device maps to one position in the registry, where all of its pertinent
information is stored. That information is not shared between multiple
instances. If you have 3 identical web cameras, you have 3 nodes in the
registry.

Sorry to break it to you, but you’re wasting your time…

9

Tim, Chris,

There are two different items not to mix up:
(a) internal OS tracking of resources
(b) prompting for installation of a driver or re-use of an existing one

I completely agree that for (a) the unique device position needs to be
tracked and distinguished, of course.

For (b), however, it is not understandable for an end user, why they
have to install the same driver again, just because they forgot that
last time they plugged their device into the left USB port, not the
right USB port.

Worse, yet, they have the ability to screw up, and e.g. select a wrong
driver version - then in the worst case the wrong driver binary will
overwrite the existing, good binary.

It is even possible to have two technically completely different drivers

  • e.g. one WDM, one UMDF - serve the same USB VID/PID on two different
    USB ports.

Now you do the support explaining to a customer why something does not
work when he plugs his device on the one USB port, but works OK when he
uses the other port.

==> When an “unknown” USB device VID/PID for a USB port (enum
entry) is detected, the device installer can already copy the entries
from an exitsing other USB port if the USB device has a “USB serial
number string descriptor”.
So why not use VID/PID/BCDdevice (and if you like the device name string
descriptor) to determine what driver is needed.

If you have three “identical” apples, you do not need three different
knives to cut them, do you?
If you have three printer cables, do you need a new printer driver for
the different cables? Normally not.

So why do you need to install a new driver - with th epossibility for
the user to screw up - if someone plugs a device to a different USB port?

You don’t, b/c a driver should and does serve a device type, not an
individual instance of a device. This is my point.

Understood?

10

On 9/1/2009 9:13 AM, Hagen Patzke wrote:

You don’t, b/c a driver should and does serve a device type, not an
individual instance of a device. This is my point.

And to make it crystal clear:

One driver BINARY must of course be INSTANCED multiple times, thus
serving different devices OF THE SAME TYPE on multiple ports.

So one driver instance <=> one device instance.

But not a new driver installation for every device instance, or the same
device on a different port.

…well, probably it’s hopeless. I better give up now.

11

Hagen Patzke wrote:

Worse, yet, they have the ability to screw up, and e.g. select a
wrong driver version - then in the worst case the wrong driver
binary will overwrite the existing, good binary. […] Now you do
the support explaining to a customer why something does not
work when he plugs his device on the one USB port, but works
OK when he uses the other port.

I would probably suggest an explanation like, “my company is run by ignorant poseurs, so we don’t sign our drivers, nor do we ship a driver installer that probably manages driver upgrades. That’s why you get the hardware wizard as you move from port to port. Uhh, just keep clicking ‘Recommended’. And pay no attention to the box with the big red ‘X’. Thanks for calling PatzkeSoft.”

12

Hagen Patzke wrote:

==> When an “unknown” USB device VID/PID for a USB port (enum
entry) is detected, the device installer can already copy the entries
from an exitsing other USB port if the USB device has a “USB serial
number string descriptor”.
So why not use VID/PID/BCDdevice (and if you like the device name string
descriptor) to determine what driver is needed.

I agree that copying from an existing device is alternate design that
could be made to work. However, that design would have its OWN corner
cases and unintended consequences. For example, how much of the data
should you copy? What if there is additional data in the devnode
registry key? Should that data be copied or not? What if it contained
unique identifying data that was created by a co-installer? The answer
would depend on whether this was simple a single device being moved to a
different slot, or if this was really a new device.

If you have three “identical” apples, you do not need three different
knives to cut them, do you?

If I hope to cut them at the same time, I certainly do. That assumes I
have three hands, of course, but that’s just a matter of hardware. :wink:

If you have three printer cables, do you need a new printer driver for
the different cables? Normally not.

Your cable metaphor is fatally flawed. If I change USB cables, I don’t
need a new driver either.

You don’t, b/c a driver should and does serve a device type, not an
individual instance of a device. This is my point.

Understood?

Certainly, I understand your point. I hope you also understand that
your approach has just as many shortcomings as the approach Microsoft
chose. Given two approaches, neither one perfect, they chose the one
that starts from a clean slate. I suspect that the overall user
experience is probably better with the design they chose, in part
because the device manufacturers that care embed serial numbers.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

13

xxxxx@gmail.com wrote:

I would probably suggest an explanation like, "[insult deleted] we
don’t sign our drivers, nor do we ship a driver installer that
probably manages driver upgrades.

We KMCS sign our drivers and our CAT files, but - true - have no WHQL
signature. Not enough business to warrant one.

“Properly” is probably the word you were looking for. I would definitely
not want a driver upgrade that is “probably managed”. :slight_smile:

That’s why you get the hardware wizard as you move from port to port.

If my analysis is correct we get a hardware wizard because (a) Microsoft
decided to tie the USB device driver installation routine to a
specific device instead to (uniquely identified) device types, and (b)
we have no WHQL signature to do a silent installation.

[insult deleted]

True, we do not have an automagical multimegabyte install wizard to hunt
down and manually replace drivers. This might stem from the fact that
our drivers cause remarkably little support issues and therefore we
can’t justify the expense to ask Mr. Aseltine to write one for us.

C’mon, Chris. Calm down, and get professional again. Thanks!

14

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Wednesday, September 02, 2009 8:07 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] USB Driver Install Problem

If my analysis is correct we get a hardware wizard because
(a) Microsoft
decided to tie the USB device driver installation routine to a
specific device instead to (uniquely identified) device
types, and (b)
we have no WHQL signature to do a silent installation.

Yes. Tim already explained the first part but again. It is necessary to
create unique device node when you move the device to a new port. You
suggested to copy existing device node. But the basic problem is what to
copy. The device node registry info can be written by INF, by
coinstallers and by driver itself. OS has no way how to decide what to
copy and what not. For example, current selective suspend state. It is
managed by user in the Power Properties tab in DM. Driver is informed
about changes and stores them to the registry. The default value is
usually created by INF. Should it be copied or not? In turn, the only
way how to create new devnode in clean state is to run INF and
coinstallers and then load the driver. I.e. repeat installation. Which
is what OS does.

No problem with signed drivers, only unsigned ones. Perhaps OS could
detect this driver was already installed for different port, user
confirmed all red warnings and make installation more silent.

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

15

Michal Vodicka wrote:

No problem with signed drivers, only unsigned ones. Perhaps OS could
detect this driver was already installed for different port, user
confirmed all red warnings and make installation more silent.

Yes, my reasoning is exactly this:

  • If the OS can do a silent install for the exact same USB device
    with identical “USB Serial Number string descriptor” (on the first
    plug-in event(!))…

  • …then it should also be possible to specify the same silent install
    for the exact same USB device (as identified by VID/PID/bcdDevice) if
    the only thing that is different is the “USB Serial Number string
    descriptor”.

  • Same if the device does not even have a “USB Serial Number string
    descriptor”, but the device type (VID/PID/bcdDevice) is identical.

But now I see the light: the “1 Microsoft Way” solution is just

===>>> get WHQL signed <<<===

16

> -----Original Message-----

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Thursday, September 03, 2009 12:42 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] USB Driver Install Problem

Yes, my reasoning is exactly this:

  • If the OS can do a silent install for the exact same USB device
    with identical “USB Serial Number string descriptor” (on the first
    plug-in event(!))…

But it doesn’t. If I understand correctly, there is just one device
node per system for an USB device with serial number. Regardless of port
used. So no install if you plug to different port; existing devnode is
just reused. The side effect is you can’t have connected two devices
with the same serial number because they’d have to share the same
devnode.

  • …then it should also be possible to specify the same
    silent install
    for the exact same USB device (as identified by VID/PID/bcdDevice) if
    the only thing that is different is the “USB Serial Number string
    descriptor”.

  • Same if the device does not even have a “USB Serial Number string
    descriptor”, but the device type (VID/PID/bcdDevice) is identical.

Sorry, if your base assumption above is wrong, conclusions are wrong,
too. In above two cases there is a need for creating new devnode i.e.
new install.

But now I see the light: the “1 Microsoft Way” solution is just

===>>> get WHQL signed <<<===

Yes. It could be avoided. OTOH, they want to force us to sign drivers.
This is the way how to do it. Why should they fix it?

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]

17

On 9/3/2009 12:58 AM, Michal Vodicka wrote:

But it doesn’t. If I understand correctly, there is just one device
node per system for an USB device with serial number. Regardless of port
used. So no install if you plug to different port; existing devnode is
just reused. The side effect is you can’t have connected two devices
with the same serial number because they’d have to share the same
devnode.

Thanks, Michal, for pointing this out!

Surprisingly enough, this discussion actually manages to give me a
clearer view of the USB device management system. Time for a few more
experiments - this time with serial-number-enabled devices. :slight_smile: