USB - hardware wizard and serial number

I have a USB device with an unsigned WDF driver that installs and works on
XP or Vista. The device is reporting a VID (idVendor), PID (idProduct), and
string descriptor (iSerialNumber) in the standard device descriptor where
the string descriptor points to a unique string for every device.

If I plug in a 2nd device the hardware wizard comes up even though the
unsigned WDF driver has been bound to the VID/PID/Serial Number of the
identical 1st device (except the serial number is different).

I was expecting the 2nd device to get bound to the same driver of the 1st
device automatically without using the hardware wizard. Any ideas on what
is wrong or is there something I don’t quite understand? I’m thinking it
might be because the driver isn’t signed.

-Dave

Unsigned drivers aren’t rusted, and this is one of the ummmm… benefits of using them (you get the wizard every time).

I have a test where a test bus spawns 6 dozen nearly identical PDOs (actually 3-4 dozen each of two different IDs), and it is an absolute joy to run when I forget to sign the drivers first…

>Unsigned drivers aren’t rusted,

Actually, some of them are pretty rusty…

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Thursday, May 10, 2007 9:48 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] USB - hardware wizard and serial number

Unsigned drivers aren’t rusted, and this is one of the ummmm… benefits of
using them (you get the wizard every time).

I have a test where a test bus spawns 6 dozen nearly identical PDOs
(actually 3-4 dozen each of two different IDs), and it is an absolute joy to
run when I forget to sign the drivers first…


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

The serial number identifies the device and allows you to plug the usb
device into any single usb hub and be treated as the same device. This
means that you are asked to install the driver once per device with a
unique serial number. But, the identity only applies to the device, not
the install package. This is why a device with a different serial
number is treated as a new device (b/c it is new :wink: ).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Thursday, May 10, 2007 8:19 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB - hardware wizard and serial number

I have a USB device with an unsigned WDF driver that installs and works
on
XP or Vista. The device is reporting a VID (idVendor), PID (idProduct),
and
string descriptor (iSerialNumber) in the standard device descriptor
where
the string descriptor points to a unique string for every device.

If I plug in a 2nd device the hardware wizard comes up even though the
unsigned WDF driver has been bound to the VID/PID/Serial Number of the
identical 1st device (except the serial number is different).

I was expecting the 2nd device to get bound to the same driver of the
1st
device automatically without using the hardware wizard. Any ideas on
what
is wrong or is there something I don’t quite understand? I’m thinking
it
might be because the driver isn’t signed.

-Dave


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

So if I get the driver signed then the hardware wizard will not be started
when a 2nd device of the same PID, VID, and different serial number is
plugged in. Correct?

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Unsigned drivers aren’t rusted, and this is one of the ummmm… benefits of
using them (you get the wizard every time).

I have a test where a test bus spawns 6 dozen nearly identical PDOs
(actually 3-4 dozen each of two different IDs), and it is an absolute joy to
run when I forget to sign the drivers first…

Yes, if it is signed you will not get a popup on the 2nd time (and this
has nothing to do with the fact that your device has a serial number).

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Voeller
Sent: Thursday, May 10, 2007 10:16 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] USB - hardware wizard and serial number

So if I get the driver signed then the hardware wizard will not be
started
when a 2nd device of the same PID, VID, and different serial number is
plugged in. Correct?

“Bob Kjelgaard” wrote in message
news:xxxxx@ntdev…
Unsigned drivers aren’t rusted, and this is one of the ummmm… benefits
of
using them (you get the wizard every time).

I have a test where a test bus spawns 6 dozen nearly identical PDOs
(actually 3-4 dozen each of two different IDs), and it is an absolute
joy to
run when I forget to sign the drivers first…


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

> I was expecting the 2nd device to get bound to the same driver of the 1st

device automatically without using the hardware wizard.

This can only occur if the driver is WHQLed.

Nevertheless, if the serial number is here, you can re-plug the same device to
any USB ports in the system, and it will work without the driver reinstallation
procedure.

With serial-number-less device, it will run the driver install on each re-plug
to a new port.


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Bob Kjelgaard wrote:

I have a test where a test bus spawns 6 dozen nearly identical PDOs
(actually 3-4 dozen each of two different IDs), and it is an absolute
joy to run when I forget to sign the drivers first…

Wait, do you have the ability to self-sign as WHQL?

>>

I have a test where a test bus spawns 6 dozen nearly identical PDOs
(actually 3-4 dozen each of two different IDs), and it is an absolute
joy to run when I forget to sign the drivers first…

Wait, do you have the ability to self-sign as WHQL?
<<

No, I can’t self-sign as WHQL. Yes, I can under controlled circumstances provide binaries that are deemed “properly signed” by the OS on which I am installing them (I am a part of the Windows QA organization, so I do have a need to be able to do that). Saying more than that leaves me with NDA concerns, so I’d prefer to leave it at that.

Bob Kjelgaard wrote:

No, I can’t self-sign as WHQL. Yes, I can under controlled
circumstances provide binaries that are deemed “properly
signed” by the OS on which I am installing them.

Ooh…powerful :slight_smile:

Bob Kjelgaard wrote:

Wait, do you have the ability to self-sign as WHQL?
<<

No, I can’t self-sign as WHQL. Yes, I can under controlled circumstances provide binaries that are deemed “properly signed” by the OS on which I am installing them (I am a part of the Windows QA organization, so I do have a need to be able to do that). Saying more than that leaves me with NDA concerns, so I’d prefer to leave it at that.

But, as I understand it, we can ALL do this, as long as we turn on test
signing mode in boot.ini and add our certificates to the proper
certificate stores.

Can’t we? Or is my very tenuous grasp of the signing issue slipping
away yet again?


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

I was an idiot to even raise the issue of what I can or can’t do, and I’m not going to comment on it further.

I found I couldn’t use the mechanisms you refer to on Server 2003, but everywhere else I remember trying, yes I could make a self-signed driver install.

Tim Roberts wrote:

But, as I understand it, we can ALL do this, as long as we turn
on test signing mode in boot.ini and add our certificates to the
proper certificate stores.

Well, I believe we were talking about XP here. Self-signed drivers (even with real Verisign ID, etc.) show up as unsigned anyway on XP, except maybe drivers with their own device setup class. In other words you still get the warning box (unless set to ignore), and you still get the hardware wizard.

Bob was saying (at least I understood) that while he can’t self-sign as WHQL, he does possess the ability to create a similar outcome (drivers that install silently). Must be some sort of black magic :slight_smile:

>>
Self-signed drivers (even with real Verisign ID, etc.) show up as unsigned anyway on XP
<<

Did you include the certificates in the “Trusted Publishers” store and the “Trusted Root” (if I remembered the names correctly) store? It’s been almost a year since I walked through the WDK beta docs on the self-signing process with a certificate from makecert on various KMDF sample drivers, but as I recall it, I was able to make the driver acceptable on all the platforms (except server 2003, which I believe had objections related to Authenticode) by doing this.

Somebody (I think it was Hagen Patzke) had a rather useful post here explaining some of these stores and other certificate-related items a few weeks back.

At any rate, I think it looked like some parts of the system needed the certificate in one store, and other parts in the other- it didn’t fully work unless I had it in both (and it had to be system. not local user, store).

Sorry I’m not more definite, but it was a side project unrelated to my real work (all I really needed to do was make sure my assigned samples built, installed, worked, didn’t cause DV or DC2 to puke, etc). I did that over a year ago- my memory’s just not that good. Got the general impression it was a process that would seem easy if I did it enough times, but took a while to get through initially…

Bob Kjelgaard wrote:

Did you include the certificates in the “Trusted Publishers” store
and the “Trusted Root” (if I remembered the names correctly)
store?

Well, no, so I went and tried that. It didn’t seem to change anything, so I also went and dumped my certificate everywhere I could find, including places where I also saw “Microsoft Hardware Compatibility Publisher”. I still got the normal set of warnings, and setupapi.log said: “The certificate is not valid for the requested usage.”

If I view one of my Winqual-supplied catalog files, the path goes like this:

Microsoft Root Authority
Microsoft Windows Hardware Compatibility PCA
Microsoft Windows Hardware Compatibility Publisher

If I look at my inf2cat + signtool catalog file, it looks like this:

Verisign Class 3 Public Primary CA
VeriSign Class 3 Code Signing 2004 CA


I also tried copying “Verisign Class 3 Public Primary CA” to “Trusted Publishers”, etc. but it didn’t affect the outcome.

My apologies for that last post, Chris- sometimes hazy old memories work (like remembering the spurious restarts with the KMDF 1.1 coinstaller), other times they don’t- this being one of them.

>>
Bob was saying (at least I understood) that while he can’t self-sign as WHQL, he
does possess the ability to create a similar outcome (drivers that install
silently). Must be some sort of black magic :slight_smile:
<<
It does appear that at least parts of the technique we use have been disclosed:

Here’s one:
http://blogs.msdn.com/oldnewthing/archive/2003/08/12/54634.aspx

Here’s another:
https://winqual.microsoft.com/help/How_to.htm

In short. I test sign drivers with a certificate chained to Microsoft’s test root certificate, and install that certificate- it converts the OS to a test/evaluation build, but since what I am doing is “test”, I could care less about that. I prefer not to discuss the technique because it has been [and obviously can still be] used by some vendors for cheating, as noted in the first link.

But you can search for “test root certificate”.

I also set the “Silent Install” capability on my PDOs when the bus driver creates them. But I believe that only works if you get past the signing hurdle [I’ve seen statements posted here that it does nothing- that’s not the way I remember it, but I have no compelling reason to research the issue at the moment, either].

The last OS that used SilentInstall to suppress UI was Win2k. All OS’s
afterwards will always present hw present/installation UI (even if it is
jus the icon next to the clock), regardless of if this capability is set
or not.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@microsoft.com
Sent: Sunday, May 20, 2007 8:57 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] USB - hardware wizard and serial number

>
Bob was saying (at least I understood) that while he can’t self-sign as
WHQL, he
does possess the ability to create a similar outcome (drivers that
install
silently). Must be some sort of black magic :slight_smile:
<<
It does appear that at least parts of the technique we use have been
disclosed:

Here’s one:
http://blogs.msdn.com/oldnewthing/archive/2003/08/12/54634.aspx

Here’s another:
https://winqual.microsoft.com/help/How_to.htm

In short. I test sign drivers with a certificate chained to Microsoft’s
test root certificate, and install that certificate- it converts the OS
to a test/evaluation build, but since what I am doing is “test”, I could
care less about that. I prefer not to discuss the technique because it
has been [and obviously can still be] used by some vendors for cheating,
as noted in the first link.

But you can search for “test root certificate”.

I also set the “Silent Install” capability on my PDOs when the bus
driver creates them. But I believe that only works if you get past the
signing hurdle [I’ve seen statements posted here that it does nothing- that’s not the way I remember it, but I have no compelling reason to research the issue at the moment, either].


Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer