Hello,
I put in the driver (*.sys, *.inf) with the installer of the application into the system (XP).
But anytime I connect the USB-Device to an other(!) USB port or via an external hub this nasty hardware assistant comes up and ask the same questions again and again!
This is not very comfortable for me an the customers.
How can I prevent this behavior?
Why does this assistant not appear if I plug in the USB-mouse?
Thank you very much,
Thomas
Thomas Kracke wrote:
But anytime I connect the USB-Device to an other(!) USB port or
via an external hub this nasty hardware assistant comes up and
ask the same questions again and again!
Here’s my question: how many weeks after this thread has totally died will Maxim S. Shatskih resurrect it, only to say, “sign the driver and use a USB serial number”?
xxxxx@yahoo.com wrote:
But anytime I connect the USB-Device to an other(!) USB port or via an external hub this nasty hardware assistant comes up and ask the same questions again and again!
This has become a FAQ.
This is not very comfortable for me an the customers.
Yes.
How can I prevent this behavior?
Define an additional USB String Descriptor and reference its index in
the USB Device Descriptor field iSerialNumber.
(USB2.0 spec: http://www.usb.org/developers/docs/usb_20_040908.zip)
For a device with the same serial number it should prevent the driver
installation prompt. The prompt still comes if you have the same device
type, but with a different serial number.
Why does this assistant not appear if I plug in the USB-mouse?
Because the USB mouse driver went through WHQL/WLK certification and its
CATalog file is cross-signed by Microsoft (first install). And it
probably also has a serial number (subsequent installations).
Also see
http://blogs.msdn.com/oldnewthing/archive/2004/11/10/255047.aspx
http://forum.soft32.com/windows/USB-devices-detected-USB-ports-ftopict347854.html
The “proper” Windows behavior for handling USB devices would probably be
to use the USB Device Descriptor fields idVendor/idProduct and possibly
bcdDevice to determine that a USB device driver installation is
necessary, not (as today) iSerialNumber and logical USB port location.
Hopefully this will be fixed in Win7.
[Peter, can we have one of the old posts from Doron as a linkable FAQ
entry for this item, please? Thanks!]
Vid/pid alone cannot id a device uniquely on the system. Only a serial number can do that, so this is not changing for win7. If you used vid/pid as a unque id, what do you do when 2 of the same devices (eg share the same vid/pid values) are plugged in at the same time?
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Hagen Patzke
Sent: Friday, November 28, 2008 4:08 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to prevent “assistent for new hardware” if the USB-Device is plugged in?
xxxxx@yahoo.com wrote:
> But anytime I connect the USB-Device to an other(!) USB port or via an external hub this nasty hardware assistant comes up and ask the same questions again and again!
This has become a FAQ.
> This is not very comfortable for me an the customers.
Yes.
> How can I prevent this behavior?
Define an additional USB String Descriptor and reference its index in
the USB Device Descriptor field iSerialNumber.
(USB2.0 spec: http://www.usb.org/developers/docs/usb_20_040908.zip)
For a device with the same serial number it should prevent the driver
installation prompt. The prompt still comes if you have the same device
type, but with a different serial number.
> Why does this assistant not appear if I plug in the USB-mouse?
Because the USB mouse driver went through WHQL/WLK certification and its
CATalog file is cross-signed by Microsoft (first install). And it
probably also has a serial number (subsequent installations).
Also see
http://blogs.msdn.com/oldnewthing/archive/2004/11/10/255047.aspx
http://forum.soft32.com/windows/USB-devices-detected-USB-ports-ftopict347854.html
The “proper” Windows behavior for handling USB devices would probably be
to use the USB Device Descriptor fields idVendor/idProduct and possibly
bcdDevice to determine that a USB device driver installation is
necessary, not (as today) iSerialNumber and logical USB port location.
Hopefully this will be fixed in Win7.
[Peter, can we have one of the old posts from Doron as a linkable FAQ
entry for this item, please? Thanks!]
—
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
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Friday, November 28, 2008 4:59 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] How to prevent “assistent for new
hardware” if the USB-Device is plugged in?Vid/pid alone cannot id a device uniquely on the system. Only
a serial number can do that, so this is not changing for
win7.
And this is good thing at least for driver developers. It allows me to
have different drivers installed per port which is very useful
sometimes. The only weak point is when they use driver binary with the
same name. For example two different versions of the same driver. The
one installed later replaces the binary installed before. It makes
previous driver installation inconsistent so I’d see it as not quite
robust design at least.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
Doron Holan wrote:
Vid/pid alone cannot id a device uniquely on the system. Only a serial number can do that, so this is not changing for win7.
If you used vid/pid as a unque id, what do you do when 2 of the same devices (eg share the same vid/pid values) are plugged in at the same time?
VID/PID and bcdDevice together uniquely identify a group of devices that
can (read: should) use the same driver.
For “end users” it is not understandable why you need to install a new
driver just because you plug in your device in port 3 instead of port 2.
For them, USB is like a “cable”. Do you need to install a new driver
because you changed your serial cable?
Of course, internally the OS needs to track exactly which device is
plugged where.
But to determine if a new driver installation is necessary or not, the
logical/physical position of a device in a device tree should IMO not
matter. And currently it does. Hopefully this will be fixed in Win7.
(Clearer now?)
Michal Vodicka wrote:
And this is good thing at least for driver developers. It allows me to
have different drivers installed per port which is very useful
sometimes. The only weak point is when they use driver binary with the
same name. For example two different versions of the same driver. The
one installed later replaces the binary installed before. It makes
previous driver installation inconsistent so I’d see it as not quite
robust design at least.
The current functionality is potentially useful for a very small group
of users (driver developers), but can be disastrous for a very large
group of users (e.g. if with a re-plug of the device to a different port
a different driver binary is selected).
Hagen Patzke wrote:
…
For “end users” it is not understandable why you need to install a new
driver just because you plug in your device in port 3 instead of port 2.
Many things are not understandable to end users 
But to determine if a new driver installation is necessary or not, the
logical/physical position of a device in a device tree should IMO not
matter. And currently it does. Hopefully this will be fixed in Win7.
In the win95 version of PnP (it was mostly PCMCIA those days), instances
were identified as “1st detected (or inserted)”, “2nd detected” etc.
So, if you had only one device, it reused the same driver
instance, no matter where it was attached - without needing “serial
numbers” or signatures.
But with two or more instances, it was impossible to tell
which device gets which instance.
Then, somebody decided that this is a big deal.
Not clear why. PnP automagically does the right thing for most device
types, so it could just create new instances as needed.
When was the last time you tweaked a USB mouse, keyboard, flash drive,
or camera?
Few device classes that need per-instance config (like netcards) could
be treated separately. Who knows.
Instead, they decided to identify *all* device instances by “unique”
attachment points in the system, and call this ‘instance IDs’. Now, it’s
history…
No it isn’t likely to change in win7.
Regards,
–PA
It was clear before. What you are describing is changing the veru basis of device identity in windows, that is not changing for win7.
d
Sent from my phone with no t9, all spilling mistakes are not intentional.
-----Original Message-----
From: Hagen Patzke
Sent: Monday, December 01, 2008 2:46 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to prevent “assistent for new hardware” if the USB-Device is plugged in?
Doron Holan wrote:
> Vid/pid alone cannot id a device uniquely on the system. Only a serial number can do that, so this is not changing for win7.
> If you used vid/pid as a unque id, what do you do when 2 of the same devices (eg share the same vid/pid values) are plugged in at the same time?
VID/PID and bcdDevice together uniquely identify a group of devices that
can (read: should) use the same driver.
For “end users” it is not understandable why you need to install a new
driver just because you plug in your device in port 3 instead of port 2.
For them, USB is like a “cable”. Do you need to install a new driver
because you changed your serial cable?
Of course, internally the OS needs to track exactly which device is
plugged where.
But to determine if a new driver installation is necessary or not, the
logical/physical position of a device in a device tree should IMO not
matter. And currently it does. Hopefully this will be fixed in Win7.
(Clearer now?)
—
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
> -----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Monday, December 01, 2008 11:56 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] How to prevent “assistent for new
hardware” if the USB-Device is plugged in?The current functionality is potentially useful for a very
small group
of users (driver developers),
But members of the small group designed it 
but can be disastrous for a very large
group of users (e.g. if with a re-plug of the device to a
different port
a different driver binary is selected).
Don’t exaggerate. It’d occur only if they installed different drivers
per port.
Best regards,
Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]
> In the win95 version of PnP (it was mostly PCMCIA those days), instances
were identified as “1st detected (or inserted)”, “2nd detected” etc.
So, if you had only one device, it reused the same driver
instance, no matter where it was attached - without needing “serial
numbers” or signatures.
But with two or more instances, it was impossible to tell
which device gets which instance.
Linux uses the same way IIRC.
Few device classes that need per-instance config (like netcards)
Oh yes. I have an old laptop (my wife’s) with external USB Wi-Fi hardware which lacks the USB serial number.
It is a great fun setting it up - you need to re-enter the Wi-Fi WEP key for each USB port where the thing is attached.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
Maxim S. Shatskih wrote:
> In the win95 version of PnP (it was mostly PCMCIA those days), instances
> were identified as “1st detected (or inserted)”, “2nd detected” etc.
> So, if you had only one device, it reused the same driver
> instance, no matter where it was attached - without needing “serial
> numbers” or signatures.
> But with two or more instances, it was impossible to tell
> which device gets which instance.
>Linux uses the same way IIRC.
Actually, Linux now has a very flexible mechanism for mapping physical
devices to device file names (called “udev”), involving some clever
pattern matching primitives and even executable extensions… It is
essentially as if Microsoft allowed us to insert custom “helper” DLLs
into the plug-and-play process.
Linux also exposes the host/hub/port tree, which solves many of these
issues.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Doron Holan wrote:
It was clear before. What you are describing is changing the veru
basis of device identity in windows, that is not changing for win7.
(Ok, last time. Promised. I just want to try to make sure there is no
misunderstanding.)
Doron, one thing is the DRIVER BINARY installation. IMO, for USB this
should only be prompted for once per device TYPE (identified by USB
idVendor/idProduct/bcdDevice, all three of them).
A completely different issue is the DRIVER INSTANCE - this has to be
exactly matched to a specific device in the device tree (which Windows
does a great job to).
YES, the instances must be exactly identified and told apart.
For me, a driver drives not ONE ENTITY of a device, but can drive ALL
DEVICES of the identical TYPE.
–war story–
User installs our new USB driver version from a network drive. The core
driver binary has the same name, of course.
Time passes.
User is now with the laptop “on the go”. S/He plugs our USB device into
a different port, is prompted for driver install, and manually selects
the older USB driver version from a subdirectory on the laptop.
This installation overwrites the new driver binary with an older one.
User: "When I plug the device back into [the old USB port],
functionality STILL does not work again.
(Analyzed 2007. Solved via new driver download from our website.)
Maxim S. Shatskih wrote:
> Few device classes that need per-instance config (like netcards)
Oh yes. I have an old laptop (my wife’s) with external USB Wi-Fi hardware which lacks the USB serial number.
It is a great fun setting it up - you need to re-enter the Wi-Fi WEP key for each USB port where the thing is attached.
For USB, the “serial numbers” would perfectly get rid of this annoyance.
But they are specific to USB.
For cardbus, each socket created a new instance, so I had to sync the
settings among all these instances … it was a fun
New laptops usually have only one socket, that should spare user’s
nerves (and few yuans to the manufacturer).
–pa
Tim Roberts wrote:
Maxim S. Shatskih wrote:
>> In the win95 version of PnP (it was mostly PCMCIA those days), instances
>> were identified as “1st detected (or inserted)”, “2nd detected” etc.
>> So, if you had only one device, it reused the same driver
>> instance, no matter where it was attached - without needing “serial
>> numbers” or signatures.
>> But with two or more instances, it was impossible to tell
>> which device gets which instance.
>>
> Linux uses the same way IIRC.
>Actually, Linux now has a very flexible mechanism for mapping physical
devices to device file names (called “udev”), involving some clever
pattern matching primitives and even executable extensions… It is
essentially as if Microsoft allowed us to insert custom “helper” DLLs
into the plug-and-play process.Linux also exposes the host/hub/port tree, which solves many of these
issues.
But in Linux, there is no analog to the persistent enum tree in the
registry, where all components of the device stack can store their stuff?
(this is doable, of course, with the help of udev - but do they actually
use persistent data per device instance, like “friendly name” or
“characteristics” ?)
–PA
Pavel A. wrote:
But in Linux, there is no analog to the persistent enum tree in the
registry, where all components of the device stack can store their stuff?
(this is doable, of course, with the help of udev - but do they
actually use persistent data per device instance, like “friendly name”
or “characteristics” ?)
Not with persistence, no. To a much greater extent than Windows, Linux
uses the philosophy that each boot is a fresh start, with each device
being “born anew” every time. Much of the data that is persistent in
Windows (including friendly name) is recreated in Linux at each boot
(deterministically, one hopes).
And allow me to suggest pro-actively that debates over the “goodness” or
“badness” of the respective approaches of the two operating systems are
neither productive nor appropriate here.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I’ve heard the argument that Linux likes to be “born anew” on each boot, and
there is no persistence. Yet, much of device configuration is controlled by
scripts stored in the file system, which do persist across boots.
As a result, I’m a little skeptical of the view that Linux doesn’t have
“persistent” device configuration info. I guess things like IP addresses
stored in scripts are not supposed to count.
Jan
> But in Linux, there is no analog to the persistent enum tree in the
> registry, where all components of the device stack can
store their stuff?
> (this is doable, of course, with the help of udev - but do they
> actually use persistent data per device instance, like
“friendly name”
> or “characteristics” ?)Not with persistence, no. To a much greater extent than
Windows, Linux uses the philosophy that each boot is a fresh
start, with each device being “born anew” every time. Much
of the data that is persistent in Windows (including friendly
name) is recreated in Linux at each boot (deterministically,
one hopes).And allow me to suggest pro-actively that debates over the
“goodness” or “badness” of the respective approaches of the
two operating systems are neither productive nor appropriate here.
Jan Bottorff wrote:
I’ve heard the argument that Linux likes to be “born anew” on each boot, and
there is no persistence. Yet, much of device configuration is controlled by
scripts stored in the file system, which do persist across boots.As a result, I’m a little skeptical of the view that Linux doesn’t have
“persistent” device configuration info. I guess things like IP addresses
stored in scripts are not supposed to count.
But it’s a different concept, don’t you think? It’s the difference
between information created externally that directs how a device should
be configured, should it happen to show up, and information maintained
by a driver on its own behalf.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hagen Patzke wrote:
User installs our new USB driver version from a network drive. The
core driver binary has the same name, of course. Time passes.
User is now with the laptop “on the go”. S/He plugs our USB device
into a different port, is prompted for driver install, and manually
selects the older USB driver version from a subdirectory on the laptop.
Ahh, okay, now it makes sense. What you’re really saying is your driver installation process is broken. You should be preinstalling drivers using DIFX so that the “source path” for the binaries is a place (in this case, the DriverStore) that is always available.
Jan Bottorff wrote:
I’ve heard the argument that Linux likes to be “born anew” on each
boot, and there is no persistence.
Amen. Try moving your boot drive from one hard disk controller to another and then rebooting.
Linux: gravy.
Windows: INACCESSIBLE_BOOT_DEVICE