WDF co-installer v1.9 has dependencies on Vista OS.

We?ve been facing some troubles with the latest WDF co-installer v1.9 when trying to install our virtual COM port driver on Vista OS (x86 and x64). We had also verified this with a couple of other devices which use WDF co-installer v1.9 and the same installation error was reproduced. For example, this can be reproduced by overriding the default serial driver (which handles the default COM1 in any machine) with the WDF serial driver example (provided within the latest DDK 7600) which uses WDF co-installer v1.9.

It?s quite simple to reproduce the issue:

  1. Go to the ?Services? window.
  2. Stop and disable ?Windows Update? service.
  3. Override the default serial driver with the WDF serial driver example.
  4. An error saying ?Windows encountered a problem installing the driver software for your device?.
  5. Driver cannot be installed.

Then I noticed that there are some dependencies with ?Windows Update? service so I followed the next steps:

a. Enabled the ?windows update? service in manual or automatic mode (it doesn?t matter which mode). Do not start the service.
b. Proceed with the serial driver override.
c. Now you will be able to install the driver.
d. Vista will ask to reboot the machine.
e. The COM port will be only available and properly installed after rebooting the machine.

Also, when doing the reboot after successful driver installation, the following messages while rebooting:

* Before rebooting: Configuring updates: Stage 2 of 3 ?

* After rebooting: Configuring updates: Stage 3 of 3 ?

Some additional inputs could be the following:

  • It happens on all Vista distributions.
  • It doesn?t happen on XP or Win 7.
  • XP doesn?t have the ?Windows Update? service.
  • Win 7 has ?Windows Update? service.
  • And one very important: Whenever serial driver is installed on Vista, it always asks for a ?reboot?.
  • When on Vista, if ?Windows Update? service is enabled (it doesn?t matter if it?s started or stopped) after the reboot, there are messages like: Configuring updates: Stage ?
  • You can reproduce the issue with any WDF driver using WDF co-installer v1.9 under Vista OS.

I hope anyone can help me out to address this issue, since it?s not a good behavior for a WDF co-installer (it didn?t happen with previous version like v1.7 or v1.5).

Thanks and Best Regards,

Ismael

Yes you are correct that WDF relies on the windows update mechanism on Vista and Win7. For XP/2K3/2k we use a different update mechanism.

The reason you are seeing a reboot when you install 1.9 on Vista is that Vista ships with 1.5 (or 1.7 for SP1) version of WDF inbox. Whenever a framework driver is installed, we will check the version that is currently on the system. If the framework version of this new driver is newer than what is currently on the system than we need to update the framework. Unfortunately this requires a reboot. You are not seeing this behavior on XP, likely because there are no WDF drivers on the system and Win7 ships with 1.9 so we don’t need to update. We will take your feedback into consideration when you say this is a poor experience.

I think that addresses your concerns, let us know if you have any more questions.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of iduron@ti.com
Sent: Thursday, December 17, 2009 7:58 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

We?ve been facing some troubles with the latest WDF co-installer v1.9 when trying to install our virtual COM port driver on Vista OS (x86 and x64). We had also verified this with a couple of other devices which use WDF co-installer v1.9 and the same installation error was reproduced. For example, this can be reproduced by overriding the default serial driver (which handles the default COM1 in any machine) with the WDF serial driver example (provided within the latest DDK 7600) which uses WDF co-installer v1.9.

It?s quite simple to reproduce the issue:

  1. Go to the ?Services? window.
  2. Stop and disable ?Windows Update? service.
  3. Override the default serial driver with the WDF serial driver example.
  4. An error saying ?Windows encountered a problem installing the driver software for your device?.
  5. Driver cannot be installed.

Then I noticed that there are some dependencies with ?Windows Update? service so I followed the next steps:

a. Enabled the ?windows update? service in manual or automatic mode (it doesn?t matter which mode). Do not start the service.
b. Proceed with the serial driver override.
c. Now you will be able to install the driver.
d. Vista will ask to reboot the machine.
e. The COM port will be only available and properly installed after rebooting the machine.

Also, when doing the reboot after successful driver installation, the following messages while rebooting:

* Before rebooting: Configuring updates: Stage 2 of 3 ?

* After rebooting: Configuring updates: Stage 3 of 3 ?

Some additional inputs could be the following:

  • It happens on all Vista distributions.
  • It doesn?t happen on XP or Win 7.
  • XP doesn?t have the ?Windows Update? service.
  • Win 7 has ?Windows Update? service.
  • And one very important: Whenever serial driver is installed on Vista, it always asks for a ?reboot?.
  • When on Vista, if ?Windows Update? service is enabled (it doesn?t matter if it?s started or stopped) after the reboot, there are messages like: Configuring updates: Stage ?
  • You can reproduce the issue with any WDF driver using WDF co-installer v1.9 under Vista OS.

I hope anyone can help me out to address this issue, since it?s not a good behavior for a WDF co-installer (it didn?t happen with previous version like v1.7 or v1.5).

Thanks and Best Regards,

Ismael


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 Brandon for your prompt reply.

About WDF co-installer versions, you said that Vista (no service pack) had v1.5 and Vista SP1 has v1.7. Which co-installer is included in SP2 for example?

Also, why a co-installer v1.7 didn’t have any troubles when updating v1.5 regardless if Windows Update service is enabled? Why there’s no need to enable windows update service on Win 7 when using co-installer v1.9?

Best Regards,

Ismael

iduron@ti.com wrote:

Thanks Brandon for your prompt reply.

About WDF co-installer versions, you said that Vista (no service pack) had v1.5 and Vista SP1 has v1.7. Which co-installer is included in SP2 for example?

Also 1.7.

Why there’s no need to enable windows update service on Win 7 when using co-installer v1.9?

Because Win 7 already includes KMDF 1.9.


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

Tim, thanks!

I understand the Win 7 case…

Nevertheless, why updating v1.5 with v1.7 didn’t show troubles in Vista? Why updating v1.7 with v1.9 does have troubles?

It is still not answered…

thanks for the help,

Ismael

iduron@ti.com wrote:

Nevertheless, why updating v1.5 with v1.7 didn’t show troubles in Vista? Why updating v1.7 with v1.9 does have troubles?

Don’t know. Perhaps KMDF did not use the Windows Update service until 1.9.

It is still not answered…

Well, I don’t think knowing the answer actually helps you at all. It is
what it is, and you have to deal with it.


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

Updating with v1.5 with v1.7 should have had these troubles as well. If you are testing on Vista RTM it is possible another driver has already updated to v1.7. That driver would have taken the reboot request instead of yours. If this is not the case, I would be interested to know what circumstances led to a v1.5 to v1.7 upgrade did not require a reboot, this would most likely indicate a bug.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of iduron@ti.com
Sent: Thursday, December 17, 2009 10:14 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

Tim, thanks!

I understand the Win 7 case…

Nevertheless, why updating v1.5 with v1.7 didn’t show troubles in Vista? Why updating v1.7 with v1.9 does have troubles?

It is still not answered…

thanks for the help,

Ismael


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

Brandon,

I’ll try again updating v1.5 to v1.7 on a clean Vista install… I’m quite sure that I loaded a fresh Vista image when doing my testing…

I’ll be back with an answer, and if in case it’s reproduced again, how should I proceed reporting this bug?

Thanks again for your comments!

Best,

Ismael

Best place to start would be sending me the setup logs. Ilias has a couple of good blog posts discussion how to debug WDF installation which includes the list of all the important log files. You can find the latest post here:

http://blogs.msdn.com/iliast/archive/2009/06/09/analyzing-the-installation-of-wdf-1-7-and-1-9-drivers.aspx

Brandon

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of iduron@ti.com
Sent: Thursday, December 17, 2009 12:07 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

Brandon,

I’ll try again updating v1.5 to v1.7 on a clean Vista install… I’m quite sure that I loaded a fresh Vista image when doing my testing…

I’ll be back with an answer, and if in case it’s reproduced again, how should I proceed reporting this bug?

Thanks again for your comments!

Best,

Ismael


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

> 2. Stop and disable ?Windows Update? service.

Windows is not guaranteed to work properly if you disable some of its important services.

It is normal that there are bugs in such a case.

  • XP doesn?t have the ?Windows Update? service.

It has.


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

This seems rather unacceptable. Plugging, for example, a usb device
into a system and having that system demand a reboot is annoying as
hell. One might even say it is broken.

Too bad kmdf does this sort of thing. I seem to recall having a
discussion about this sort of dll version malfunction way before kmdf
ever got released.

Mark Roddy

On Thu, Dec 17, 2009 at 11:08 AM, Brandon Wilson wrote:
> Yes you are correct that WDF relies on the windows update mechanism on Vista and Win7. ?For XP/2K3/2k we use a different update mechanism.
>
> The reason you are seeing a reboot when you install 1.9 on Vista is that Vista ships with 1.5 (or 1.7 for SP1) version of WDF inbox. ?Whenever a framework driver is installed, we will check the version that is currently on the system. ?If the framework version of this new driver is newer than what is currently on the system than we need to update the framework. ?Unfortunately this requires a reboot. ?You are not seeing this behavior on XP, likely because there are no WDF drivers on the system and Win7 ships with 1.9 so we don’t need to update. ?We will take your feedback into consideration when you say this is a poor experience.
>
> I think that addresses your concerns, let us know if you have any more questions.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of iduron@ti.com
> Sent: Thursday, December 17, 2009 7:58 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.
>
> We?ve been facing some troubles with the latest WDF co-installer v1.9 when trying to install our virtual COM port driver on Vista OS (x86 and x64). We had also verified this with a couple of other devices which use WDF co-installer v1.9 and the same installation error was reproduced. For example, this can be reproduced by overriding the default serial driver (which handles the default COM1 in any machine) with the WDF serial driver example (provided within the latest DDK 7600) which uses WDF co-installer v1.9.
>
> It?s quite simple to reproduce the issue:
>
> 1. Go to the ?Services? window.
> 2. Stop and disable ?Windows Update? service.
> 3. Override the default serial driver with the WDF serial driver example.
> 4. An error saying ?Windows encountered a problem installing the driver software for your device?.
> 5. Driver cannot be installed.
>
> Then I noticed that there are some dependencies with ?Windows Update? service so I followed the next steps:
>
> a. Enabled the ?windows update? service in manual or automatic mode (it doesn?t matter which mode). Do not start the service.
> b. Proceed with the serial driver override.
> c. Now you will be able to install the driver.
> d. Vista will ask to reboot the machine.
> e. The COM port will be only available and properly installed after rebooting the machine.
>
> Also, when doing the reboot after successful driver installation, the following messages while rebooting:
>
> * Before rebooting: Configuring updates: Stage 2 of 3 ?
>
> * After rebooting: Configuring updates: Stage 3 of 3 ?
>
> Some additional inputs could be the following:
>
> - It happens on all Vista distributions.
> - It doesn?t happen on XP or Win 7.
> - XP doesn?t have the ?Windows Update? service.
> - Win 7 has ?Windows Update? service.
> - And one very important: Whenever serial driver is installed on Vista, it always asks for a ?reboot?.
> - When on Vista, if ?Windows Update? service is enabled (it doesn?t matter if it?s started or stopped) after the reboot, there are messages like: Configuring updates: Stage ?
> - You can reproduce the issue with any WDF driver using WDF co-installer v1.9 under Vista OS.
>
> I hope anyone can help me out to address this issue, since it?s not a good behavior for a WDF co-installer (it didn?t happen with previous version like v1.7 or v1.5).
>
> Thanks and Best Regards,
>
> Ismael
>
> —
> 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
>

+1

mm

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

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brandon Wilson
Sent: Thursday, December 17, 2009 5:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF co-installer v1.9 has dependencies
on Vista OS.

Yes you are correct that WDF relies on the windows update
mechanism on Vista and Win7.

Can you elaborate? Does it rely just on running service or on the live
connection to WU?

The reason you are seeing a reboot when you install 1.9 on
Vista is that Vista ships with 1.5 (or 1.7 for SP1) version
of WDF inbox. Whenever a framework driver is installed, we
will check the version that is currently on the system. If
the framework version of this new driver is newer than what
is currently on the system than we need to update the
framework. Unfortunately this requires a reboot.

As Mark said, it is rather unacceptable. Like a time machine, back to NT
3.51 days. Static linking which was refused without a convincing reason
would solve it.

Best regards,

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

Static linking would solve a truly amazing number of serious windows problems…

mm

> Static linking would solve a truly amazing number of serious windows

problems…

What I find curious about the lack of KMDF static linking can be described
in the December 2009 MSDN Magazine article (page 12) about .Net 4.0
In-Process Side-By-Side assemblies. It says “…it was impossible to make
any significant changes or additions to our platform and still ensure that
the latest version could run any application as well as older versions
could”.

It seems like the KMDF group believes it can release ABSOLUTLY upwardly
compatible KMDF versions, and at the same time the .Net CLR group is
expending significant engineering effort to add new features to the CLR
because they believe it’s impossible to assure ABSOLUTLY upward compatible
versions. The CLR folks seems like pretty smart people, and perhaps the two
groups should have a conversation about why they each believe what they do.

I certainly agree with Mark’s comment that plugging in a USB device and
finding it requires a reboot is bad.

It seems like there is an even worse scenario if I read the PnP-X (Windows
Rally) documents correctly. It says the IPBusEnum service can detect a new
device on the network, and query it’s hardware id, and initiate an INF file
based PnP device install. I assume this is capable of installing a kernel
driver that uses KMDF. The user experience would be, they are sitting at
their computer, and somebody across the office plugs a new gizmo into the
network, and out of what seems like thin air their system wants to reboot,
to update the KMDF version for the PnP-X detected device on the network. If
we assume this is a corporate/academic environment, many machines will ALL
detect the new PnP-X device on the network, then all of a sudden everybody
in the office is being asked to reboot, because somebody plugged a new gizmo
into the network.

Jan

The clr has a much larger code surface than kmdf and willfully change implementations over time, esp between major versions. They also have a much larger number of clients which means any change they make will effect someone. So yes, the wdf team believes we can make changes and maintain compat, we explicitly test for that. One size does not fit all for servicing across all of msft

As for rally devices, just because they are present and discovered does not mean they are installed, typically you still have to explicitly choose to use the device which may then install software (but if you look at pnp x the only real device class that is defined is printing)

d

-----Original Message-----
From: Jan Bottorff
Sent: Saturday, December 19, 2009 4:02 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

> Static linking would solve a truly amazing number of serious windows
> problems…

What I find curious about the lack of KMDF static linking can be described
in the December 2009 MSDN Magazine article (page 12) about .Net 4.0
In-Process Side-By-Side assemblies. It says “…it was impossible to make
any significant changes or additions to our platform and still ensure that
the latest version could run any application as well as older versions
could”.

It seems like the KMDF group believes it can release ABSOLUTLY upwardly
compatible KMDF versions, and at the same time the .Net CLR group is
expending significant engineering effort to add new features to the CLR
because they believe it’s impossible to assure ABSOLUTLY upward compatible
versions. The CLR folks seems like pretty smart people, and perhaps the two
groups should have a conversation about why they each believe what they do.

I certainly agree with Mark’s comment that plugging in a USB device and
finding it requires a reboot is bad.

It seems like there is an even worse scenario if I read the PnP-X (Windows
Rally) documents correctly. It says the IPBusEnum service can detect a new
device on the network, and query it’s hardware id, and initiate an INF file
based PnP device install. I assume this is capable of installing a kernel
driver that uses KMDF. The user experience would be, they are sitting at
their computer, and somebody across the office plugs a new gizmo into the
network, and out of what seems like thin air their system wants to reboot,
to update the KMDF version for the PnP-X detected device on the network. If
we assume this is a corporate/academic environment, many machines will ALL
detect the new PnP-X device on the network, then all of a sudden everybody
in the office is being asked to reboot, because somebody plugged a new gizmo
into the network.

Jan


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

> Can you elaborate? Does it rely just on running service or on the live

connection to WU?

It just relies on the running service since the co-installers still function on computers with no network connection.

As Mark said, it is rather unacceptable. Like a time machine, back to NT
3.51 days. Static linking which was refused without a convincing reason
would solve it.

While static linking would solve some problems, it creates other problems as well. This includes making patching any bugs in WDF much harder and increasing the in-memory size of the kernel. While a single driver statically linked will only add ~.5 MB, this can quickly add up and there is a very real pressure to reduce the memory footprint of windows, especially for netbooks and VM server environments.

With that being said we are investigating other ways that we can avoid reboots and your feedback has certainly been heard.

Brandon

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, December 18, 2009 9:31 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brandon Wilson
Sent: Thursday, December 17, 2009 5:08 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF co-installer v1.9 has dependencies
on Vista OS.

Yes you are correct that WDF relies on the windows update
mechanism on Vista and Win7.

Can you elaborate? Does it rely just on running service or on the live
connection to WU?

The reason you are seeing a reboot when you install 1.9 on
Vista is that Vista ships with 1.5 (or 1.7 for SP1) version
of WDF inbox. Whenever a framework driver is installed, we
will check the version that is currently on the system. If
the framework version of this new driver is newer than what
is currently on the system than we need to update the
framework. Unfortunately this requires a reboot.

As Mark said, it is rather unacceptable. Like a time machine, back to NT
3.51 days. Static linking which was refused without a convincing reason
would solve it.

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

Thanks, Brandon.

mm

Is it difficult to change the KMDF loader behavior so that adding a driver
that installs 1.11 does not require a reboot if drivers are currently
running against 1.10? In other words, an explicit ‘make before break’
upgrade? The drivers presently bound to 1.10 could remain so bound until
they unload and reload, whereby the loader stub could bind them to the later
1.11 binary.

KMDF can still be ‘serviced’ if each time a driver loads it binds against
the ‘latest’ version but avoiding the ‘force a reboot’ to install a newer
version of KMDF would be nice. Perhaps there are implementation details
that prevent having ‘side-by-side’ implementations loaded simultaneously
(and if so, that is too bad).

Dave Cattley

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brandon Wilson
Sent: Monday, December 21, 2009 12:14 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] WDF co-installer v1.9 has dependencies on Vista OS.

Can you elaborate? Does it rely just on running service or on the live
connection to WU?

It just relies on the running service since the co-installers still function
on computers with no network connection.

As Mark said, it is rather unacceptable. Like a time machine, back to NT
3.51 days. Static linking which was refused without a convincing reason
would solve it.

While static linking would solve some problems, it creates other problems as
well. This includes making patching any bugs in WDF much harder and
increasing the in-memory size of the kernel. While a single driver
statically linked will only add ~.5 MB, this can quickly add up and there is
a very real pressure to reduce the memory footprint of windows, especially
for netbooks and VM server environments.

With that being said we are investigating other ways that we can avoid
reboots and your feedback has certainly been heard.

Brandon

David R. Cattley wrote:

Is it difficult to change the KMDF loader behavior so that adding a driver
that installs 1.11 does not require a reboot if drivers are currently
running against 1.10? In other words, an explicit ‘make before break’
upgrade? The drivers presently bound to 1.10 could remain so bound until
they unload and reload, whereby the loader stub could bind them to the later
1.11 binary.

This would require some pretty obscure magic. It is certainly possible
to replace a driver binary while the driver is loaded (unlike a
user-mode executable), but new devices will continue to use the
in-memory version until it unloads. So, your driver that needs 1.11
would link to the loaded 1.10 KMDF until reboot.

Perhaps there are implementation details
that prevent having ‘side-by-side’ implementations loaded simultaneously
(and if so, that is too bad).

Barring magic, I think that is exactly the case.

It’s a tough situation. Given the desire to allow all KMDF-based
drivers to share in the benefits of the most recent library, there just
isn’t a good solution to this problem. They could have called the
driver “wdf01005.sys” and “wdf01007.sys” and “wdf01009.sys”, but that
means a driver using 1.5 would use 1.5 forever, which is exactly the
situation they were trying to avoid. (That’s also one of the arguments
against static linking.)

I guess they could have used the separate driver names, then updated all
of the binaries at once to the newest version. That would allow the
situation you describe, but it seems a little silly.

In the end, I think the “reboot” required problem is less of an issue
than we think. When a new KMDF comes out, there is a whole spate of
“not another reboot!” complaints, but as soon as the new library gets
spread around, it’s not a problem any more.


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