Replacing signed drivers

Hello All,

I have a doubt regarding one signed driver replacing another signed
driver. My situation is as follows:

[1] I have a set of drivers (version 1.0) which install a given USB
device. These drivers were successfully WHQL tested.

[2] Now i have a new set of drivers (version 2.0) for the same device.
These drivers will also be tested with WHQL tool for certification.
It can be noted that apart from driver versions there is nothing
different between the 1.0 and 2.0 INF files.

At this point i have a few scenarios which need clarification from
experts:
================================================== =========================

1) If user has installed version 1.0 drivers first and later tries to
install 2.0 drivers (signed ofcourse) then will the 2.0 drivers
replace the existing 1.0 drivers?

2) If user has installed version 2.0 drivers (signed) first and later
tries to install 1.0 drivers, then when the device is connected which
of the INFs will be considered for installation? 1.0 or 2.0? Is
INF-matching based on newer of older versions of the INFs?

NOTE: Installation in the above scenarios are done programatically
through SetupXXXX functions.

Any pointers on this will be highly appreciated.

Hari

>-----Original Message-----
>Hello All,
>
>I have a doubt regarding one signed driver replacing
another signed
>driver. My situation is as follows:
>
>[1] I have a set of drivers (version 1.0) which install a
given USB
>device. These drivers were successfully WHQL tested.
>
>[2] Now i have a new set of drivers (version 2.0) for the
same device.
> These drivers will also be tested with WHQL tool for
certification.
>It can be noted that apart from driver versions there is
nothing
>different between the 1.0 and 2.0 INF files.
>
>At this point i have a few scenarios which need
clarification from
>experts:
>================================================= =========
=================
>
>1) If user has installed version 1.0 drivers first and
later tries to
>install 2.0 drivers (signed ofcourse) then will the 2.0
drivers
>replace the existing 1.0 drivers?
>

YES.

>2) If user has installed version 2.0 drivers (signed)
first and later
>tries to install 1.0 drivers, then when the device is
connected which
>of the INFs will be considered for installation? 1.0 or
2.0? Is
>INF-matching based on newer of older versions of the INFs?
>

UNFORTUNATLY, It seems that it always the new driver (the
Windows best one), no way to remove this bad behavior. I
tried to programmatically indicate to Windows that the old
one is fact better but I did not find a solution.
(I tried change DriverInstallParams.Rank to 0
SetSelectedDriver = old driver, NO SUCCESS).

Philippe.

>NOTE: Installation in the above scenarios are done
programatically
>through SetupXXXX functions.
>
>Any pointers on this will be highly appreciated.
>
>Hari
>.
>

wrote:
>>2) If user has installed version 2.0 drivers (signed)
> first and later
>>tries to install 1.0 drivers, then when the device is
>
> UNFORTUNATLY, It seems that it always the new driver (the
> Windows best one), no way to remove this bad behavior. I
> tried to programmatically indicate to Windows that the old
> one is fact better but I did not find a solution.
> (I tried change DriverInstallParams.Rank to 0
> SetSelectedDriver = old driver, NO SUCCESS).

UpdateDriverForPlugAndPlayDevices has a flag called INSTALLFLAG_FORCE
which causes the older driver to be installed. Use with extreme caution,
of course... Works for us...
--
.../ray\..

> >2) If user has installed version 2.0 drivers (signed)
> first and later
> >tries to install 1.0 drivers, then when the device is
> connected which
> >of the INFs will be considered for installation? 1.0 or
> 2.0? Is
> >INF-matching based on newer of older versions of the INFs?
> >
>
> UNFORTUNATLY, It seems that it always the new driver (the
> Windows best one), no way to remove this bad behavior. I
> tried to programmatically indicate to Windows that the old
> one is fact better but I did not find a solution.
> (I tried change DriverInstallParams.Rank to 0
> SetSelectedDriver = old driver, NO SUCCESS).

Clarification: Please do remember that 2.0 version of my drivers were
installed first and then 1.0 version of the drivers. In this
scenario, what would "new drivers" be? If 2.0 version of the drivers
are always considered as "new drivers" then it suits me fine!

Thanks for your response!

Hari.

On 23 Oct 2003 18:05:09 -0700, (Hari) wrote:

> Clarification: Please do remember that 2.0 version of my drivers were
> installed first and then 1.0 version of the drivers. In this
> scenario, what would "new drivers" be? If 2.0 version of the drivers
> are always considered as "new drivers" then it suits me fine!

From the DDK docs:

>> When the OS searches for drivers, it chooses a driver with a more recent
>> DriverVer date over a driver with an earlier date. If an INF has no DriverVer
>> entry or is unsigned, the OS applies the default date of 00/00/0000.

- Bob

The StickWorks
http://www.stickworks.com

How about just changing the date in the ver-2.0 .INF so
it's older than the other?

tim


>-----Original Message-----
>> >2) If user has installed version 2.0 drivers (signed)
>> first and later
>> >tries to install 1.0 drivers, then when the device is
>> connected which
>> >of the INFs will be considered for installation? 1.0
or
>> 2.0? Is
>> >INF-matching based on newer of older versions of the
INFs?
>> >
>>
>> UNFORTUNATLY, It seems that it always the new driver
(the
>> Windows best one), no way to remove this bad behavior.
I
>> tried to programmatically indicate to Windows that the
old
>> one is fact better but I did not find a solution.
>> (I tried change DriverInstallParams.Rank to 0
>> SetSelectedDriver = old driver, NO SUCCESS).
>
>Clarification: Please do remember that 2.0 version of my
drivers were
>installed first and then 1.0 version of the drivers. In
this
>scenario, what would "new drivers" be? If 2.0 version
of the drivers
>are always considered as "new drivers" then it suits me
fine!
>
>Thanks for your response!
>
>Hari.
>.
>

When we update an existing device a new signed driver (2.0)
with an old signed driver (1.0). We can do it using the
INSTALL_FORCE flag of the UpdateDriverForPlugAndPlayDevice
() function.
Now, if we plug a new device, windows uses driver 2.0 with
no user consent or notification.
It is the problem and I (same with Hari) did not find a
workaround.
We cannot change the date in the inf because it removes
consistency of driver delivery (and I am not sure it
works) and we should have also to update the dates in the
registry.

Philippe.

>-----Original Message-----
>On 23 Oct 2003 18:05:09 -0700,
(Hari) wrote:
>
>> Clarification: Please do remember that 2.0 version of
my drivers were
>> installed first and then 1.0 version of the drivers.
In this
>> scenario, what would "new drivers" be? If 2.0 version
of the drivers
>> are always considered as "new drivers" then it suits me
fine!
>
>From the DDK docs:
>
>>> When the OS searches for drivers, it chooses a driver
with a more recent
>>> DriverVer date over a driver with an earlier date. If
an INF has no DriverVer
>>> entry or is unsigned, the OS applies the default date
of 00/00/0000.
>
>- Bob
>
>The StickWorks
>http://www.stickworks.com
>.
>

By updating a specific device, you told the system to use an old driver for
that particular device. If you plug in a new device, how would the system
know that it needs to use the old driver? System will always the use the
latest signed driver by design.

Other than invalidating the new signed driver INF package (by scribbling
into it), there is no way you can force the system to use an old driver
package automatically when a device is plugged in.

--
-Eliyas
This posting is provided "AS IS" with no warranties, and confers no rights.
http://www.microsoft.com/whdc/hwdev/driver/kb-drv.mspx

"philippe smadja" <> wrote in message
news:074701c39a47$a1662f90$...
> When we update an existing device a new signed driver (2.0)
> with an old signed driver (1.0). We can do it using the
> INSTALL_FORCE flag of the UpdateDriverForPlugAndPlayDevice
> () function.
> Now, if we plug a new device, windows uses driver 2.0 with
> no user consent or notification.
> It is the problem and I (same with Hari) did not find a
> workaround.
> We cannot change the date in the inf because it removes
> consistency of driver delivery (and I am not sure it
> works) and we should have also to update the dates in the
> registry.
>
> Philippe.
>
> >-----Original Message-----
> >On 23 Oct 2003 18:05:09 -0700,
> (Hari) wrote:
> >
> >> Clarification: Please do remember that 2.0 version of
> my drivers were
> >> installed first and then 1.0 version of the drivers.
> In this
> >> scenario, what would "new drivers" be? If 2.0 version
> of the drivers
> >> are always considered as "new drivers" then it suits me
> fine!
> >
> >From the DDK docs:
> >
> >>> When the OS searches for drivers, it chooses a driver
> with a more recent
> >>> DriverVer date over a driver with an earlier date. If
> an INF has no DriverVer
> >>> entry or is unsigned, the OS applies the default date
> of 00/00/0000.
> >
> >- Bob
> >
> >The StickWorks
> >http://www.stickworks.com
> >.
> >

Well, in general, I think that Windows using the latest driver is
probably the right thing to do. With this as a basic guiding principle,
"working around it" would presumably require some kind of change to the
1.0 driver version in order to break the "correct" behavior for this one
special case. Since you would need to change it anyway, there doesn't
seem to be any extra work or configuration management.

So, I think the "right" answer is that you should build a branch off of
your 1.0 driver (you're using source code control, right? :-), and just
update the version date to something later than 2.0.

This way, if you ever release a 2.1 driver with a fix for the problem
(and presumably put in an even later date), it will again correctly
automatically be chosen as the "best" one.

The alternative would be some kind of scheme where your drivers *never*
allow themselves to be updated to a newer driver... either that or
something hideously complex. Either of those solutions would be much worse.

philippe smadja wrote:

> When we update an existing device a new signed driver (2.0)
> with an old signed driver (1.0). We can do it using the
> INSTALL_FORCE flag of the UpdateDriverForPlugAndPlayDevice
> () function.
> Now, if we plug a new device, windows uses driver 2.0 with
> no user consent or notification.
> It is the problem and I (same with Hari) did not find a
> workaround.
> We cannot change the date in the inf because it removes
> consistency of driver delivery (and I am not sure it
> works) and we should have also to update the dates in the
> registry.
>
> Philippe.
>
>
>>-----Original Message-----
>>On 23 Oct 2003 18:05:09 -0700,
>
> (Hari) wrote:
>
>>>Clarification: Please do remember that 2.0 version of
>
> my drivers were
>
>>>installed first and then 1.0 version of the drivers.
>
> In this
>
>>>scenario, what would "new drivers" be? If 2.0 version
>
> of the drivers
>
>>>are always considered as "new drivers" then it suits me
>
> fine!
>
>>From the DDK docs:
>
>>>>When the OS searches for drivers, it chooses a driver
>
> with a more recent
>
>>>>DriverVer date over a driver with an earlier date. If
>
> an INF has no DriverVer
>
>>>>entry or is unsigned, the OS applies the default date
>
> of 00/00/0000.
>
>>- Bob
>>
>>The StickWorks
>>http://www.stickworks.com
>>.
>>

--
.../ray\..

Doh... I just realized that even this suggestion is way too baroque.

Just tell your users to uninstall the 2.0 driver first before
reinstalling 1.0. I presume that your uninstallation package cleans up
after itself, right?

Ray Trent wrote:

> Well, in general, I think that Windows using the latest driver is
> probably the right thing to do. With this as a basic guiding principle,
> "working around it" would presumably require some kind of change to the
> 1.0 driver version in order to break the "correct" behavior for this one
> special case. Since you would need to change it anyway, there doesn't
> seem to be any extra work or configuration management.
>
> So, I think the "right" answer is that you should build a branch off of
> your 1.0 driver (you're using source code control, right? :-), and just
> update the version date to something later than 2.0.
>
> This way, if you ever release a 2.1 driver with a fix for the problem
> (and presumably put in an even later date), it will again correctly
> automatically be chosen as the "best" one.
>
> The alternative would be some kind of scheme where your drivers *never*
> allow themselves to be updated to a newer driver... either that or
> something hideously complex. Either of those solutions would be much worse.
>
> philippe smadja wrote:
>
>> When we update an existing device a new signed driver (2.0)
>> with an old signed driver (1.0). We can do it using the INSTALL_FORCE
>> flag of the UpdateDriverForPlugAndPlayDevice
>> () function.
>> Now, if we plug a new device, windows uses driver 2.0 with no user
>> consent or notification.
>> It is the problem and I (same with Hari) did not find a workaround.
>> We cannot change the date in the inf because it removes consistency of
>> driver delivery (and I am not sure it works) and we should have also
>> to update the dates in the registry.
>>
>> Philippe.
>>
>>
>>> -----Original Message-----
>>> On 23 Oct 2003 18:05:09 -0700,
>>
>>
>> (Hari) wrote:
>>
>>>> Clarification: Please do remember that 2.0 version of
>>
>>
>> my drivers were
>>
>>>> installed first and then 1.0 version of the drivers.
>>
>>
>> In this
>>
>>>> scenario, what would "new drivers" be? If 2.0 version
>>
>>
>> of the drivers
>>
>>>> are always considered as "new drivers" then it suits me
>>
>>
>> fine!
>>
>>> From the DDK docs:
>>
>>
>>>>> When the OS searches for drivers, it chooses a driver
>>
>>
>> with a more recent
>>
>>>>> DriverVer date over a driver with an earlier date. If
>>
>>
>> an INF has no DriverVer
>>
>>>>> entry or is unsigned, the OS applies the default date
>>
>>
>> of 00/00/0000.
>>
>>> - Bob
>>>
>>> The StickWorks
>>> http://www.stickworks.com
>>> .
>>>
>

--
.../ray\..