WinUSB v2 INF-File

Hello,

I want to use the new WinUSB v2(WDK 7.0.0) driver for my USB device but did not manage to get it installed correctly.
Until now I used the inf file from http://www.lvr.com/winusb.htm to install WinUSB, I tried to change the versions and file names but windows XP SP3 complained aabout missing winusbcoinstaller.dll file.

Best Regards

Would it be possible to paste the inf that you are using (i.e. after your modifications)?
The WinUSB v2 coinstaller is called winusbcoinstaller2.dll (i.e. there is a “2” at the end of the filename) and my guess is that somewhere in your inf you are still refering to the old name (which does not have the ending “2”).

Ilias


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of xxxxx@gmx.at [xxxxx@gmx.at]
Sent: Friday, August 07, 2009 3:25 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WinUSB v2 INF-File

Hello,

I want to use the new WinUSB v2(WDK 7.0.0) driver for my USB device but did not manage to get it installed correctly.
Until now I used the inf file from http://www.lvr.com/winusb.htm to install WinUSB, I tried to change the versions and file names but windows XP SP3 complained aabout missing winusbcoinstaller.dll file.

Best Regards


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

Ilias,

what was the reason of this change? Just curious, I have my INFs already
updated.

Best regards,

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ilias
Tsigkogiannis
Sent: Saturday, August 08, 2009 4:00 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

Would it be possible to paste the inf that you are using
(i.e. after your modifications)?
The WinUSB v2 coinstaller is called winusbcoinstaller2.dll
(i.e. there is a “2” at the end of the filename) and my guess
is that somewhere in your inf you are still refering to the
old name (which does not have the ending “2”).

Ilias


From: xxxxx@lists.osr.com
[xxxxx@lists.osr.com] on behalf of
xxxxx@gmx.at [xxxxx@gmx.at]
Sent: Friday, August 07, 2009 3:25 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WinUSB v2 INF-File

Hello,

I want to use the new WinUSB v2(WDK 7.0.0) driver for my USB
device but did not manage to get it installed correctly.
Until now I used the inf file from
http://www.lvr.com/winusb.htm to install WinUSB, I tried to
change the versions and file names but windows XP SP3
complained aabout missing winusbcoinstaller.dll file.

Best Regards


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


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

This has to do with the way that the PNP manager handles the coinstallers.
Let’s say that you have a driver that uses a coinstaller with the name coinstaller.dll. This driver is running in the system, however you have a newer version of the driver with a newer version of the coinstaller (i.e. the code of your coinstaller has changed) and you want to update your driver.

If the old and the new coinstallers have the same name, then we have the following sequence of events:

  1. The PNP manager loads the old coinstaller and passes the DIF_* codes that have to do with the uninstall of the driver
  2. The PNP manager tries to load the new coinstaller (withount unloading the old one), however the memory manager finds that a dll with the same name is already loaded in the process (because the old and new coinstallers have the same name) and prevents the load of the new coinstaller .
  3. The PNP manager uses the old coinstaller to proceed with the installation of the new version of the driver. The new coinstaller is not used at all in this scenario.

This has been like that for all versions of Windows that support coinstallers. In order to avoid the above scenario, we need to put a version number, when there is a change in the coinstaller (e.g. wdfcoinstaller1007.dll -> wdfcoinstaller01009.dll, winusbcoinstaller.dll -> winusbcoinstaller2.dll, etc).

Hopefully, the above example was helpful.

Ilias


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of Michal Vodicka [xxxxx@upek.com]
Sent: Friday, August 07, 2009 7:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

Ilias,

what was the reason of this change? Just curious, I have my INFs already
updated.

Best regards,

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ilias
Tsigkogiannis
Sent: Saturday, August 08, 2009 4:00 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

Would it be possible to paste the inf that you are using
(i.e. after your modifications)?
The WinUSB v2 coinstaller is called winusbcoinstaller2.dll
(i.e. there is a “2” at the end of the filename) and my guess
is that somewhere in your inf you are still refering to the
old name (which does not have the ending “2”).

Ilias


From: xxxxx@lists.osr.com
[xxxxx@lists.osr.com] on behalf of
xxxxx@gmx.at [xxxxx@gmx.at]
Sent: Friday, August 07, 2009 3:25 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] WinUSB v2 INF-File

Hello,

I want to use the new WinUSB v2(WDK 7.0.0) driver for my USB
device but did not manage to get it installed correctly.
Until now I used the inf file from
http://www.lvr.com/winusb.htm to install WinUSB, I tried to
change the versions and file names but windows XP SP3
complained aabout missing winusbcoinstaller.dll file.

Best Regards


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


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


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

Thanks, it is interesting and good to know.

But now I don’t understand how do you handle minor WDF updates using
coinstallers with the same name. For example between WDK 6001.18000 and
6001.18002. If I’m not mistaken, there are two set of files like
WdfCoInstaller01007.dll which are a bit different. The driver package
containing newer one should replace older one if installed, shouldn’t
it?

Best regards,

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ilias
Tsigkogiannis
Sent: Saturday, August 08, 2009 8:06 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

This has to do with the way that the PNP manager handles the
coinstallers.
Let’s say that you have a driver that uses a coinstaller with
the name coinstaller.dll. This driver is running in the
system, however you have a newer version of the driver with a
newer version of the coinstaller (i.e. the code of your
coinstaller has changed) and you want to update your driver.

If the old and the new coinstallers have the same name, then
we have the following sequence of events:

  1. The PNP manager loads the old coinstaller and passes the
    DIF_* codes that have to do with the uninstall of the driver
  2. The PNP manager tries to load the new coinstaller
    (withount unloading the old one), however the memory manager
    finds that a dll with the same name is already loaded in the
    process (because the old and new coinstallers have the same
    name) and prevents the load of the new coinstaller .
  3. The PNP manager uses the old coinstaller to proceed with
    the installation of the new version of the driver. The new
    coinstaller is not used at all in this scenario.

This has been like that for all versions of Windows that
support coinstallers. In order to avoid the above scenario,
we need to put a version number, when there is a change in
the coinstaller (e.g. wdfcoinstaller1007.dll ->
wdfcoinstaller01009.dll, winusbcoinstaller.dll ->
winusbcoinstaller2.dll, etc).

Hopefully, the above example was helpful.

Ilias


From: xxxxx@lists.osr.com
[xxxxx@lists.osr.com] on behalf of Michal
Vodicka [xxxxx@upek.com]
Sent: Friday, August 07, 2009 7:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

Ilias,

what was the reason of this change? Just curious, I have my
INFs already
updated.

Best regards,

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

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ilias
> Tsigkogiannis
> Sent: Saturday, August 08, 2009 4:00 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] WinUSB v2 INF-File
>
> Would it be possible to paste the inf that you are using
> (i.e. after your modifications)?
> The WinUSB v2 coinstaller is called winusbcoinstaller2.dll
> (i.e. there is a “2” at the end of the filename) and my guess
> is that somewhere in your inf you are still refering to the
> old name (which does not have the ending “2”).
>
> Ilias
> ________________________________________
> From: xxxxx@lists.osr.com
> [xxxxx@lists.osr.com] on behalf of
> xxxxx@gmx.at [xxxxx@gmx.at]
> Sent: Friday, August 07, 2009 3:25 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] WinUSB v2 INF-File
>
> Hello,
>
> I want to use the new WinUSB v2(WDK 7.0.0) driver for my USB
> device but did not manage to get it installed correctly.
> Until now I used the inf file from
> http://www.lvr.com/winusb.htm to install WinUSB, I tried to
> change the versions and file names but windows XP SP3
> complained aabout missing winusbcoinstaller.dll file.
>
> Best Regards
>
> —
> 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
>
> —
> 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
>


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


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

The problem arises, if you are updating the same driver.
Let’s say that you have driver A (bundled with coinstaller.dll) and driver B (bundled with a newer version of the same coinstaller, however you keep the same coinstaller name -> coinstaller.dll). If driver A is runnng and you try to install driver B, then the newer version will be called (because the old version is not in memory… the coinstaller is only loaded for specific actions and not all the time).

Minor WDF updates (e.g. from KMDF 1.7 to KMDF 1.9) have different coinstaller names (e.g. wdfcoinstaller01007.dll -> wdfcointaller01009.dll).

However, if you have driver A using the v1 of coinstaller.dll and then you try to update the same driver using a newer coinstaller.dll, then the initial (v1) coinstaller will be used for the update. This is always the same problem regardless of what coinstaller you have. This is the same for all Windows coinstallers and not a WDF-specific issue.

We are trying to prevent such issues by asking the usage only of RTM versions of the coinstallers.

Ilias


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of Michal Vodicka [xxxxx@upek.com]
Sent: Friday, August 07, 2009 11:28 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

Thanks, it is interesting and good to know.

But now I don’t understand how do you handle minor WDF updates using
coinstallers with the same name. For example between WDK 6001.18000 and
6001.18002. If I’m not mistaken, there are two set of files like
WdfCoInstaller01007.dll which are a bit different. The driver package
containing newer one should replace older one if installed, shouldn’t
it?

Best regards,

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ilias
Tsigkogiannis
Sent: Saturday, August 08, 2009 8:06 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

This has to do with the way that the PNP manager handles the
coinstallers.
Let’s say that you have a driver that uses a coinstaller with
the name coinstaller.dll. This driver is running in the
system, however you have a newer version of the driver with a
newer version of the coinstaller (i.e. the code of your
coinstaller has changed) and you want to update your driver.

If the old and the new coinstallers have the same name, then
we have the following sequence of events:

  1. The PNP manager loads the old coinstaller and passes the
    DIF_* codes that have to do with the uninstall of the driver
  2. The PNP manager tries to load the new coinstaller
    (withount unloading the old one), however the memory manager
    finds that a dll with the same name is already loaded in the
    process (because the old and new coinstallers have the same
    name) and prevents the load of the new coinstaller .
  3. The PNP manager uses the old coinstaller to proceed with
    the installation of the new version of the driver. The new
    coinstaller is not used at all in this scenario.

This has been like that for all versions of Windows that
support coinstallers. In order to avoid the above scenario,
we need to put a version number, when there is a change in
the coinstaller (e.g. wdfcoinstaller1007.dll ->
wdfcoinstaller01009.dll, winusbcoinstaller.dll ->
winusbcoinstaller2.dll, etc).

Hopefully, the above example was helpful.

Ilias


From: xxxxx@lists.osr.com
[xxxxx@lists.osr.com] on behalf of Michal
Vodicka [xxxxx@upek.com]
Sent: Friday, August 07, 2009 7:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

Ilias,

what was the reason of this change? Just curious, I have my
INFs already
updated.

Best regards,

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

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ilias
> Tsigkogiannis
> Sent: Saturday, August 08, 2009 4:00 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] WinUSB v2 INF-File
>
> Would it be possible to paste the inf that you are using
> (i.e. after your modifications)?
> The WinUSB v2 coinstaller is called winusbcoinstaller2.dll
> (i.e. there is a “2” at the end of the filename) and my guess
> is that somewhere in your inf you are still refering to the
> old name (which does not have the ending “2”).
>
> Ilias
> ________________________________________
> From: xxxxx@lists.osr.com
> [xxxxx@lists.osr.com] on behalf of
> xxxxx@gmx.at [xxxxx@gmx.at]
> Sent: Friday, August 07, 2009 3:25 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] WinUSB v2 INF-File
>
> Hello,
>
> I want to use the new WinUSB v2(WDK 7.0.0) driver for my USB
> device but did not manage to get it installed correctly.
> Until now I used the inf file from
> http://www.lvr.com/winusb.htm to install WinUSB, I tried to
> change the versions and file names but windows XP SP3
> complained aabout missing winusbcoinstaller.dll file.
>
> Best Regards
>
> —
> 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
>
> —
> 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
>


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


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


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

I’d have to bust out my notes from the first DDC, or whenever we were introduced to WDF,
and I swear one of the talking points was that because everything was versioned, we were not
ever going to have to worry about this with WDF coinstallers. Maybe what I remember was
limited only to release versions.

I vaguely remember build numbers being a part of that, but I might be wrong - but it doesn’t
matter, there’s gotta be a better way.

Betas could use odd numbered versions, you could use build numbers, the version of the DDK
(sorry, oops, WDK) could be tacked on - something that would allow for a graceful transition
from beta to release is something that I think would make everyone’s life easier.

I have to write a lot of stuff, firmware included, and NOTHING makes it off my workstation
without a unique version number, even if it differs only by the build number.

Somehow, I don’t have problems with versionitus - unless I use the beta of the WDK…

Greg Havenga
Sr. System Architect / Sr. Software Engineer

Photometrics, Inc.
3440 E Britannia Dr.
Tucson, AZ 85749

(520) 547-2566
http://www.photomet.com


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Ilias Tsigkogiannis [xxxxx@microsoft.com]
Sent: Friday, August 07, 2009 11:56 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

The problem arises, if you are updating the same driver.
Let’s say that you have driver A (bundled with coinstaller.dll) and driver B (bundled with a newer version of the same coinstaller, however you keep the same coinstaller name -> coinstaller.dll). If driver A is runnng and you try to install driver B, then the newer version will be called (because the old version is not in memory… the coinstaller is only loaded for specific actions and not all the time).

Minor WDF updates (e.g. from KMDF 1.7 to KMDF 1.9) have different coinstaller names (e.g. wdfcoinstaller01007.dll -> wdfcointaller01009.dll).

However, if you have driver A using the v1 of coinstaller.dll and then you try to update the same driver using a newer coinstaller.dll, then the initial (v1) coinstaller will be used for the update. This is always the same problem regardless of what coinstaller you have. This is the same for all Windows coinstallers and not a WDF-specific issue.

We are trying to prevent such issues by asking the usage only of RTM versions of the coinstallers.

Ilias


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] on behalf of Michal Vodicka [xxxxx@upek.com]
Sent: Friday, August 07, 2009 11:28 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

Thanks, it is interesting and good to know.

But now I don’t understand how do you handle minor WDF updates using
coinstallers with the same name. For example between WDK 6001.18000 and
6001.18002. If I’m not mistaken, there are two set of files like
WdfCoInstaller01007.dll which are a bit different. The driver package
containing newer one should replace older one if installed, shouldn’t
it?

Best regards,

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ilias
Tsigkogiannis
Sent: Saturday, August 08, 2009 8:06 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

This has to do with the way that the PNP manager handles the
coinstallers.
Let’s say that you have a driver that uses a coinstaller with
the name coinstaller.dll. This driver is running in the
system, however you have a newer version of the driver with a
newer version of the coinstaller (i.e. the code of your
coinstaller has changed) and you want to update your driver.

If the old and the new coinstallers have the same name, then
we have the following sequence of events:

  1. The PNP manager loads the old coinstaller and passes the
    DIF_* codes that have to do with the uninstall of the driver
  2. The PNP manager tries to load the new coinstaller
    (withount unloading the old one), however the memory manager
    finds that a dll with the same name is already loaded in the
    process (because the old and new coinstallers have the same
    name) and prevents the load of the new coinstaller .
  3. The PNP manager uses the old coinstaller to proceed with
    the installation of the new version of the driver. The new
    coinstaller is not used at all in this scenario.

This has been like that for all versions of Windows that
support coinstallers. In order to avoid the above scenario,
we need to put a version number, when there is a change in
the coinstaller (e.g. wdfcoinstaller1007.dll ->
wdfcoinstaller01009.dll, winusbcoinstaller.dll ->
winusbcoinstaller2.dll, etc).

Hopefully, the above example was helpful.

Ilias


From: xxxxx@lists.osr.com
[xxxxx@lists.osr.com] on behalf of Michal
Vodicka [xxxxx@upek.com]
Sent: Friday, August 07, 2009 7:12 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

Ilias,

what was the reason of this change? Just curious, I have my
INFs already
updated.

Best regards,

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

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ilias
> Tsigkogiannis
> Sent: Saturday, August 08, 2009 4:00 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] WinUSB v2 INF-File
>
> Would it be possible to paste the inf that you are using
> (i.e. after your modifications)?
> The WinUSB v2 coinstaller is called winusbcoinstaller2.dll
> (i.e. there is a “2” at the end of the filename) and my guess
> is that somewhere in your inf you are still refering to the
> old name (which does not have the ending “2”).
>
> Ilias
> ________________________________________
> From: xxxxx@lists.osr.com
> [xxxxx@lists.osr.com] on behalf of
> xxxxx@gmx.at [xxxxx@gmx.at]
> Sent: Friday, August 07, 2009 3:25 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] WinUSB v2 INF-File
>
> Hello,
>
> I want to use the new WinUSB v2(WDK 7.0.0) driver for my USB
> device but did not manage to get it installed correctly.
> Until now I used the inf file from
> http://www.lvr.com/winusb.htm to install WinUSB, I tried to
> change the versions and file names but windows XP SP3
> complained aabout missing winusbcoinstaller.dll file.
>
> Best Regards
>
> —
> 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
>
> —
> 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
>


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


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


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


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

>Somehow, I don’t have problems with versionitus - unless I use the beta of the WDK…

Do not use beta tools for anything serious, i.e. for any shippable builds.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

You forgot one problem. How do you compile an in-box driver when the
released WDK is not available?

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntdev…
>Somehow, I don’t have problems with versionitus - unless I use the beta of
>the WDK…

Do not use beta tools for anything serious, i.e. for any shippable builds.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Second time repeating this - Doran asked too, NO.

But I have a lot of test computers that are a pain to wipe and redo for point upgrades.

Eventually they get wiped, but we have a very small staff trying to do a very big job
and we don’t need Microsoft making it any harder.

Greg Havenga
Sr. System Architect / Sr. Software Engineer

Photometrics, Inc.
3440 E Britannia Dr.
Tucson, AZ 85749

(520) 547-2566
http://www.photomet.com


From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih [xxxxx@storagecraft.com]
Sent: Sunday, August 09, 2009 3:12 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WinUSB v2 INF-File

Somehow, I don’t have problems with versionitus - unless I use the beta of the WDK…

Do not use beta tools for anything serious, i.e. for any shippable builds.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com


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

Exactly. We had to give OEMs driver before RTM WDK was available. I hope
it is no problem as OS contains newer version of everything included in
coinstallers.

Best regards,

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
Sent: Sunday, August 09, 2009 7:31 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WinUSB v2 INF-File

You forgot one problem. How do you compile an in-box driver when the
released WDK is not available?

“Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >Somehow, I don’t have problems with versionitus - unless I
> use the beta of
> >the WDK…
>
> Do not use beta tools for anything serious, i.e. for any
> shippable builds.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>
>
> —
> 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
>

For pre rtm submissions afaik, two rules apply
1 the submission is for win7 only
2 you are not allowed to include any pre rtm coinstallers (since it is win7 only, there is nothing to redist)

Once there is an rtm kit you can then resubmit with the rtm coinstallers for all downlevel sysmtems

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Michal Vodicka
Sent: Monday, August 10, 2009 1:05 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

Exactly. We had to give OEMs driver before RTM WDK was available. I hope
it is no problem as OS contains newer version of everything included in
coinstallers.

Best regards,

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

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of David Craig
> Sent: Sunday, August 09, 2009 7:31 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] WinUSB v2 INF-File
>
> You forgot one problem. How do you compile an in-box driver when the
> released WDK is not available?
>
> “Maxim S. Shatskih” wrote in message
> news:xxxxx@ntdev…
> >Somehow, I don’t have problems with versionitus - unless I
> use the beta of
> >the WDK…
>
> Do not use beta tools for anything serious, i.e. for any
> shippable builds.
>
> –
> Maxim S. Shatskih
> Windows DDK MVP
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
>
>
> —
> 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
>


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

DC> You forgot one problem. How do you compile an in-box driver
DC> when the released WDK is not available?

DH> 2 you are not allowed to include any pre rtm coinstallers […]
DH> Once there is an rtm kit you can then resubmit with
DH> the rtm coinstallers for all downlevel sysmtems

Just an idea: How about treating UMDF/KMDF and WinUSB as system
components, and do without co-installers?


Before I’m grilled again:
Most windows binaries depend on other components being in place before
it can run.
If a driver binary depends on something - e.g. a framework - that is not
installed, this must be detected and reported (and these days probably
the OS also has to offer an automatic download).

“But what if my low_level keyboard driver depends on a framework, and I
need the keyboard to install the framework in the first place?”
=> For core components like mou/kbd/vid, “inbox” drivers exist that can
be used until is installed.

On Win98SE, you could not use an USB keyboard/mouse for installation.
After installation it would work fine, but Setup you have to click “OK”
and to enter the PC network name before the USB components are
installed. So what?

=> The solution to this problem is not a co-installer that comes with
every single instance of the driver distribution, but something like an
“F6”-mechanism that allows to insert a medium with additional drivers.
Or co-installers.

Comments welcome. Probably better via PM.

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Tuesday, August 11, 2009 3:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] WinUSB v2 INF-File

Just an idea: How about treating UMDF/KMDF and WinUSB as system
components, and do without co-installers?

I believe it is the case of Win7. WDF 1.9 binaries and WinUsb are
installed with OS.

I’d like to know MS idea about WDF driver INF for Win7 and above. It
needs to reference coinstaller, right?

[CoInstallers_AddReg]
HKR,CoInstallers32,0x00010000,“WudfUpdate_01009.dll”,“WinUsbCoinstaller
2.dll”,“WdfCoInstaller01009.dll,WdfCoInstaller”

However, is it also necessary to copy coinstaller files? I.e.:

[CoInstallers_CopyFiles]
WudfUpdate_01009.dll
WdfCoInstaller01009.dll
WinUsbCoinstaller2.dll

There is one funny consequence of doing this. When files are copied,
they have to be included in driver package which is signed as complete
(WU or DTM resists on it). Catalog file contains hashes of coinstaller
files. Now imagine two packages with two different coinstaller versions.
To be clear, I mean different builds of WdfCoInstaller01009.dll file for
example. The later installed wins, no matter of file build, and breaks
the signature of previously installed driver. It is not imaginary
situation, we just received a complain from a customer about it.

You can say if all drivers use RTM coinstallers, there is no problem.
Right, but what about hotfixes? What about new WDK versions with updated
coinstallers? If you say it is not possible, I have two sets of WDK 1.7
binaries which are a bit different. 1.7.6001.0 and 1.7.6001.18000. Files
with the same name to emphasize. It would lead to signature problem. I
presume it will occur with 1.9 sooner or later. How to solve it?

Best regards,

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

Michal Vodicka wrote:

There is one funny consequence of doing this. When files are copied,
they have to be included in driver package which is signed as complete
(WU or DTM resists on it). Catalog file contains hashes of coinstaller
files. Now imagine two packages with two different coinstaller versions.
To be clear, I mean different builds of WdfCoInstaller01009.dll file for
example. The later installed wins, no matter of file build, and breaks
the signature of previously installed driver. It is not imaginary
situation, we just received a complain from a customer about it.

I don’t see how this could happen. The install-time signature checksum
doesn’t cover the files inside the co-installer DLL. It only covers the
DLL itself, as it sits in the driver store, and that DLL won’t change if
another driver with a different co-installer is copied in. What
signature are you talking about?


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

MichalVodicka>
To be clear, I mean different builds of WdfCoInstaller01009.dll file for
example. The later installed wins, no matter of file build, and breaks
the signature of previously installed driver. It is not imaginary
situation, we just received a complain from a customer about it.

How is that possible? There is only one ‘version’ of
WdfCoInstaller01009.dll that could have been used to get such a signature -
the RTM version.

Building ‘inbox’ drivers should be built against the WDF version that ships
with the O/S and not (as I understand it) actually copy the coinstaller but
simply assume it exists (at the inbox revision) on the platform.

So for an inbox driver (or really, any driver I guess) that has a NT6.0
platform requirement, you could have built against WDF 1.5 and just ‘assumed
it was present’ (is that the correct revision for Vista?). Or something
like that. Of course, later platforms might only have the later
co-installer ‘inbox’.

But ‘breaking’ another signed driver, that sounds odd. Was this with 1.9 or
with the version of WDF that got the “whoops, we need to re-release the
co-installer” treatment?

Regards,
Dave Cattley

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Tuesday, August 11, 2009 6:27 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] WinUSB v2 INF-File

Michal Vodicka wrote:
>
> There is one funny consequence of doing this. When files are copied,
> they have to be included in driver package which is signed
as complete
> (WU or DTM resists on it). Catalog file contains hashes of
coinstaller
> files. Now imagine two packages with two different
coinstaller versions.
> To be clear, I mean different builds of
WdfCoInstaller01009.dll file for
> example. The later installed wins, no matter of file build,
and breaks
> the signature of previously installed driver. It is not imaginary
> situation, we just received a complain from a customer about it.
>

I don’t see how this could happen. The install-time
signature checksum
doesn’t cover the files inside the co-installer DLL. It only
covers the
DLL itself, as it sits in the driver store, and that DLL
won’t change if
another driver with a different co-installer is copied in. What
signature are you talking about?

I’m talking about driver.cat specified in the driver INF. It references
all files in the package i.e. driver DLL, INF itself and all included
coinstallers. In other words, all files in the [SourceDisksFiles]
section + INF itself.

Best regards,

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

There is only one version of the coinstaller for x.y release, the rtm one. If there is a hotfix, the coinstaller name would most likely change

d

Sent from my phone with no t9, all spilling mistakes are not intentional.

-----Original Message-----
From: Michal Vodicka
Sent: Tuesday, August 11, 2009 1:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> Sent: Tuesday, August 11, 2009 6:27 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] WinUSB v2 INF-File
>
> Michal Vodicka wrote:
> >
> > There is one funny consequence of doing this. When files are copied,
> > they have to be included in driver package which is signed
> as complete
> > (WU or DTM resists on it). Catalog file contains hashes of
> coinstaller
> > files. Now imagine two packages with two different
> coinstaller versions.
> > To be clear, I mean different builds of
> WdfCoInstaller01009.dll file for
> > example. The later installed wins, no matter of file build,
> and breaks
> > the signature of previously installed driver. It is not imaginary
> > situation, we just received a complain from a customer about it.
> >
>
> I don’t see how this could happen. The install-time
> signature checksum
> doesn’t cover the files inside the co-installer DLL. It only
> covers the
> DLL itself, as it sits in the driver store, and that DLL
> won’t change if
> another driver with a different co-installer is copied in. What
> signature are you talking about?

I’m talking about driver.cat specified in the driver INF. It references
all files in the package i.e. driver DLL, INF itself and all included
coinstallers. In other words, all files in the [SourceDisksFiles]
section + INF itself.

Best regards,

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


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 David
R. Cattley
Sent: Tuesday, August 11, 2009 6:42 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

How is that possible? There is only one ‘version’ of
WdfCoInstaller01009.dll that could have been used to get such
a signature -
the RTM version.

Currently it occurs with in-box driver with beta coinstallers. It
shouldn’t happen but it did. There are drivers with different versions
of beta coinstallers available to OEMs and they install them together
which leads to described problem.

Later, it will occur once WDF coinstallers binaries change. In theory
only RTM version should be available forever but I’d bet it will break
sooner or later. As for 1.7 version.

Building ‘inbox’ drivers should be built against the WDF
version that ships
with the O/S and not (as I understand it) actually copy the
coinstaller but
simply assume it exists (at the inbox revision) on the platform.

Well, this is what I was asking about. How such an INF should look like.

But ‘breaking’ another signed driver, that sounds odd. Was
this with 1.9 or
with the version of WDF that got the “whoops, we need to
re-release the
co-installer” treatment?

As I said, it is 1.9 with different beta coinstallers. But the problem
is general. The odd thing is that installation doesn’t seem to check
anything and simply replaces binaries. So if you have correct driver
with RTM coinstaller and user installs another bad one with beta
coinstallers later, your signature will be broken.

Best regards,

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

In theory, Doron. As I said I have have two versions of 1.7 coinstallers
with the same name. Both released standard way, not even hotfix.

Best regards,

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

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, August 11, 2009 7:21 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WinUSB v2 INF-File

There is only one version of the coinstaller for x.y release,
the rtm one. If there is a hotfix, the coinstaller name
would most likely change

d

Sent from my phone with no t9, all spilling mistakes are not
intentional.

-----Original Message-----
From: Michal Vodicka
> Sent: Tuesday, August 11, 2009 1:18 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] WinUSB v2 INF-File
>
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
> > Sent: Tuesday, August 11, 2009 6:27 PM
> > To: Windows System Software Devs Interest List
> > Subject: Re: [ntdev] WinUSB v2 INF-File
> >
> > Michal Vodicka wrote:
> > >
> > > There is one funny consequence of doing this. When files
> are copied,
> > > they have to be included in driver package which is signed
> > as complete
> > > (WU or DTM resists on it). Catalog file contains hashes of
> > coinstaller
> > > files. Now imagine two packages with two different
> > coinstaller versions.
> > > To be clear, I mean different builds of
> > WdfCoInstaller01009.dll file for
> > > example. The later installed wins, no matter of file build,
> > and breaks
> > > the signature of previously installed driver. It is not imaginary
> > > situation, we just received a complain from a customer about it.
> > >
> >
> > I don’t see how this could happen. The install-time
> > signature checksum
> > doesn’t cover the files inside the co-installer DLL. It only
> > covers the
> > DLL itself, as it sits in the driver store, and that DLL
> > won’t change if
> > another driver with a different co-installer is copied in. What
> > signature are you talking about?
>
> I’m talking about driver.cat specified in the driver INF. It
> references
> all files in the package i.e. driver DLL, INF itself and all included
> coinstallers. In other words, all files in the [SourceDisksFiles]
> section + INF itself.
>
> Best regards,
>
> Michal Vodicka
> UPEK, Inc.
> [xxxxx@upek.com, http://www.upek.com]
>
>
> —
> 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
>
>
> —
> 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
>