Wdf coinstaller bug

NTDEV
1

The WDF coinstaller apparently looks for presence of wdf01000.sys in
system32\drivers to determine if Kmdf is already installed, and doesn’t do
anything if it’s there. This is an insufficient test, as no effort is made
to determine whether the services registry key exists and is correct.

This can easily happen through selecting the “Last known good” boot option,
as it reverts the registry, but does not affect the file system.

In order to make this easy, and eliminate my INF files and install program
from suspicion, I have reproduced the error with the nonpnp sample from WDK
6000. To reproduce, run the nonpnpapp.exe program. Reboot and select the
“Last known good” config. Run nonpnpapp.exe again–it will fail to load the
driver. Manually deleting wdf01000.sys corrects the problem.

  • Dan.
2

This is a known issue (for one thing I wrote about it in my blog in the very first set of posts), and it has been fixed (I believe beginning with 1.7, but it may be 1.9- I’ll have to wait for Ilias to confirm).

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 9:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Wdf coinstaller bug

The WDF coinstaller apparently looks for presence of wdf01000.sys in
system32\drivers to determine if Kmdf is already installed, and doesn’t do
anything if it’s there. This is an insufficient test, as no effort is made
to determine whether the services registry key exists and is correct.

This can easily happen through selecting the “Last known good” boot option,
as it reverts the registry, but does not affect the file system.

In order to make this easy, and eliminate my INF files and install program
from suspicion, I have reproduced the error with the nonpnp sample from WDK
6000. To reproduce, run the nonpnpapp.exe program. Reboot and select the
“Last known good” config. Run nonpnpapp.exe again–it will fail to load the
driver. Manually deleting wdf01000.sys corrects the problem.

  • Dan.
3

>I wrote about it in my blog in the very first set of posts

I don’t see it there, unless it’s buried somewhere in the discussion of the
accvio on non-English systems.

Do you have a suggestion for a workaround in 1.5? While the nonpnp failure
seems not-so-serious, my driver is an upper volume class filter, so a
failure to load results in an unbootable system with an
INACCESSIBLE_BOOT_DEVICE bugcheck. The customers don’t seem to care for
that…

Off the top of my head, my approach would be: before calling the
coinstaller’s preinstall routine, if the wdf01000 services key does not
exist, delete the wdf01000.sys binary if it exists.

Any big issues with that?

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Wednesday, January 16, 2008 10:36 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Wdf coinstaller bug

This is a known issue (for one thing I wrote about it in my blog in the very
first set of posts), and it has been fixed (I believe beginning with 1.7,
but it may be 1.9- I’ll have to wait for Ilias to confirm).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 9:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Wdf coinstaller bug

The WDF coinstaller apparently looks for presence of wdf01000.sys in
system32\drivers to determine if Kmdf is already installed, and doesn’t do
anything if it’s there. This is an insufficient test, as no effort is made
to determine whether the services registry key exists and is correct.

This can easily happen through selecting the “Last known good” boot option,
as it reverts the registry, but does not affect the file system.

In order to make this easy, and eliminate my INF files and install program
from suspicion, I have reproduced the error with the nonpnp sample from WDK
6000. To reproduce, run the nonpnpapp.exe program. Reboot and select the
“Last known good” config. Run nonpnpapp.exe again–it will fail to load the
driver. Manually deleting wdf01000.sys corrects the problem.

  • Dan.

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

4

The KMDF 1.7 coinstaller opens the service using the SCM APIs and if it fails, then it upgrades/fixes the framework (and installs the driver). So this should take care of your problem. Since the 1.7 coinstallers will be available soon (with the Windows Server 2008 WDK) would it be possible for you to wait and use them (there are many issues that were fixed both in the 1.7 coinstallers and in WDF 1.7. You can look at http://blogs.msdn.com/iliast/archive/2007/12/13/wdf-1-7-rc1-has-been-released.aspx and http://blogs.msdn.com/bobkjelgaard/archive/2007/12/13/kmdf-1-7-and-the-server-2008-vista-sp1-rc1-wdk.aspx for more info) or do you absolutely need to deploy a quick fix right now?

My suggestion is that if you can wait, then please use the KMDF 1.7 RC1 coinstaller for development and testing (from the Windows Server 2008 RC1 WDK) and shortly you’ll be able to use the RTM version, in order to deploy your driver.

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 10:10 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Wdf coinstaller bug

I wrote about it in my blog in the very first set of posts

I don’t see it there, unless it’s buried somewhere in the discussion of the
accvio on non-English systems.

Do you have a suggestion for a workaround in 1.5? While the nonpnp failure
seems not-so-serious, my driver is an upper volume class filter, so a
failure to load results in an unbootable system with an
INACCESSIBLE_BOOT_DEVICE bugcheck. The customers don’t seem to care for
that…

Off the top of my head, my approach would be: before calling the
coinstaller’s preinstall routine, if the wdf01000 services key does not
exist, delete the wdf01000.sys binary if it exists.

Any big issues with that?

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Wednesday, January 16, 2008 10:36 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Wdf coinstaller bug

This is a known issue (for one thing I wrote about it in my blog in the very
first set of posts), and it has been fixed (I believe beginning with 1.7,
but it may be 1.9- I’ll have to wait for Ilias to confirm).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 9:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Wdf coinstaller bug

The WDF coinstaller apparently looks for presence of wdf01000.sys in
system32\drivers to determine if Kmdf is already installed, and doesn’t do
anything if it’s there. This is an insufficient test, as no effort is made
to determine whether the services registry key exists and is correct.

This can easily happen through selecting the “Last known good” boot option,
as it reverts the registry, but does not affect the file system.

In order to make this easy, and eliminate my INF files and install program
from suspicion, I have reproduced the error with the nonpnp sample from WDK
6000. To reproduce, run the nonpnpapp.exe program. Reboot and select the
“Last known good” config. Run nonpnpapp.exe again–it will fail to load the
driver. Manually deleting wdf01000.sys corrects the problem.

  • Dan.

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

5

>>I wrote about it in my blog in the very first set of posts

I don’t see it there, unless it’s buried somewhere in the discussion of the
accvio on non-English systems.

[OT] Cut-n-paste from the very first post near the end:

Unfortunately, the way the check for prior version installation works is this: we check if the files are where they belong, and if they are, we see what version they are. On these machines, this check tells us that the correct version is present, so all subsequent installations “succeed”. But none of them actually work (because the steps to make KMDF usable were never taken).

So I make another “suggestion”- that initial check needs to be strengthened- some malicious soul could just drop a file in the right place on an end user’s machine that wasn’t using our technology and we could never successfully install on it (for me clearing up an earlier mystery from NTDEV, where a developer trying to troubleshoot an installation issue did this to himself more than once).

Admittedly not written for a technical audience, so I glossed over details like the services key. Definitely not prize-winning material, either, but a writer’s gotta start somewhere. ----

Do you have a suggestion for a workaround in 1.5? …

Off the top of my head, my approach would be: before calling the
coinstaller’s preinstall routine, if the wdf01000 services key does not
exist, delete the wdf01000.sys binary if it exists.

Any big issues with that?

Off the top of my head, no. If I were wearing your shoes, I’m sure I’d be at least considering it. I haven’t been out of the “massively frustrated dev customer of the evil empire” role myself for all that long. At one time, I’d have made a few frequent contributors and voluble detractors sound like fanboys…

BUT, putting on my “dutiful minion of said empire” hat- I must add that this isn’t a practice we’re encouraging, so if you can wait for 1.7, that would be the recommendation. It might also avoid any issues that weren’t on the top of my head (got caught in my beard, perhaps).

(All opinions expressed are clearly my own, BTW).

6

This has probably already been answered, and I think the answer is yes,
but have the issues with the 1.7 coninstallers working on XP/2K3/et. c.
been addressed? This would seem important, as it sounds like 1.7 will
solve a lot of other problems, but lack of XP support would mean that
1.7 RC1 won’t help most installations.

Thanks,

mm

Ilias Tsigkogiannis wrote:

The KMDF 1.7 coinstaller opens the service using the SCM APIs and if it fails, then it upgrades/fixes the framework (and installs the driver). So this should take care of your problem. Since the 1.7 coinstallers will be available soon (with the Windows Server 2008 WDK) would it be possible for you to wait and use them (there are many issues that were fixed both in the 1.7 coinstallers and in WDF 1.7. You can look at http://blogs.msdn.com/iliast/archive/2007/12/13/wdf-1-7-rc1-has-been-released.aspx and http://blogs.msdn.com/bobkjelgaard/archive/2007/12/13/kmdf-1-7-and-the-server-2008-vista-sp1-rc1-wdk.aspx for more info) or do you absolutely need to deploy a quick fix right now?

My suggestion is that if you can wait, then please use the KMDF 1.7 RC1 coinstaller for development and testing (from the Windows Server 2008 RC1 WDK) and shortly you’ll be able to use the RTM version, in order to deploy your driver.

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 10:10 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Wdf coinstaller bug

> I wrote about it in my blog in the very first set of posts

I don’t see it there, unless it’s buried somewhere in the discussion of the
accvio on non-English systems.

Do you have a suggestion for a workaround in 1.5? While the nonpnp failure
seems not-so-serious, my driver is an upper volume class filter, so a
failure to load results in an unbootable system with an
INACCESSIBLE_BOOT_DEVICE bugcheck. The customers don’t seem to care for
that…

Off the top of my head, my approach would be: before calling the
coinstaller’s preinstall routine, if the wdf01000 services key does not
exist, delete the wdf01000.sys binary if it exists.

Any big issues with that?

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Wednesday, January 16, 2008 10:36 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Wdf coinstaller bug

This is a known issue (for one thing I wrote about it in my blog in the very
first set of posts), and it has been fixed (I believe beginning with 1.7,
but it may be 1.9- I’ll have to wait for Ilias to confirm).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 9:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Wdf coinstaller bug

The WDF coinstaller apparently looks for presence of wdf01000.sys in
system32\drivers to determine if Kmdf is already installed, and doesn’t do
anything if it’s there. This is an insufficient test, as no effort is made
to determine whether the services registry key exists and is correct.

This can easily happen through selecting the “Last known good” boot option,
as it reverts the registry, but does not affect the file system.

In order to make this easy, and eliminate my INF files and install program
from suspicion, I have reproduced the error with the nonpnp sample from WDK
6000. To reproduce, run the nonpnpapp.exe program. Reboot and select the
“Last known good” config. Run nonpnpapp.exe again–it will fail to load the
driver. Manually deleting wdf01000.sys corrects the problem.

  • Dan.

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

7

Yes, the 1.7 coinstaller in the latest 6001 WDK RC now installs on downlevel platforms, XP included

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, January 16, 2008 8:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Wdf coinstaller bug

This has probably already been answered, and I think the answer is yes,
but have the issues with the 1.7 coninstallers working on XP/2K3/et. c.
been addressed? This would seem important, as it sounds like 1.7 will
solve a lot of other problems, but lack of XP support would mean that
1.7 RC1 won’t help most installations.

Thanks,

mm

Ilias Tsigkogiannis wrote:

The KMDF 1.7 coinstaller opens the service using the SCM APIs and if it fails, then it upgrades/fixes the framework (and installs the driver). So this should take care of your problem. Since the 1.7 coinstallers will be available soon (with the Windows Server 2008 WDK) would it be possible for you to wait and use them (there are many issues that were fixed both in the 1.7 coinstallers and in WDF 1.7. You can look at http://blogs.msdn.com/iliast/archive/2007/12/13/wdf-1-7-rc1-has-been-released.aspx and http://blogs.msdn.com/bobkjelgaard/archive/2007/12/13/kmdf-1-7-and-the-server-2008-vista-sp1-rc1-wdk.aspx for more info) or do you absolutely need to deploy a quick fix right now?

My suggestion is that if you can wait, then please use the KMDF 1.7 RC1 coinstaller for development and testing (from the Windows Server 2008 RC1 WDK) and shortly you’ll be able to use the RTM version, in order to deploy your driver.

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 10:10 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Wdf coinstaller bug

> I wrote about it in my blog in the very first set of posts

I don’t see it there, unless it’s buried somewhere in the discussion of the
accvio on non-English systems.

Do you have a suggestion for a workaround in 1.5? While the nonpnp failure
seems not-so-serious, my driver is an upper volume class filter, so a
failure to load results in an unbootable system with an
INACCESSIBLE_BOOT_DEVICE bugcheck. The customers don’t seem to care for
that…

Off the top of my head, my approach would be: before calling the
coinstaller’s preinstall routine, if the wdf01000 services key does not
exist, delete the wdf01000.sys binary if it exists.

Any big issues with that?

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Wednesday, January 16, 2008 10:36 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Wdf coinstaller bug

This is a known issue (for one thing I wrote about it in my blog in the very
first set of posts), and it has been fixed (I believe beginning with 1.7,
but it may be 1.9- I’ll have to wait for Ilias to confirm).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 9:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Wdf coinstaller bug

The WDF coinstaller apparently looks for presence of wdf01000.sys in
system32\drivers to determine if Kmdf is already installed, and doesn’t do
anything if it’s there. This is an insufficient test, as no effort is made
to determine whether the services registry key exists and is correct.

This can easily happen through selecting the “Last known good” boot option,
as it reverts the registry, but does not affect the file system.

In order to make this easy, and eliminate my INF files and install program
from suspicion, I have reproduced the error with the nonpnp sample from WDK
6000. To reproduce, run the nonpnpapp.exe program. Reboot and select the
“Last known good” config. Run nonpnpapp.exe again–it will fail to load the
driver. Manually deleting wdf01000.sys corrects the problem.

  • Dan.

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

8

And in the “would have been nice if we’d told you so” category- the RC0 (September roughly) WDK’s coinstallers also worked downlevel, EXCEPT for Vista. On the other hand, people get confused enough by these missing pieces, all or nothing may have been the best guidance, anyway.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, January 16, 2008 9:05 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Wdf coinstaller bug

Yes, the 1.7 coinstaller in the latest 6001 WDK RC now installs on downlevel platforms, XP included

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, January 16, 2008 8:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Wdf coinstaller bug

This has probably already been answered, and I think the answer is yes,
but have the issues with the 1.7 coninstallers working on XP/2K3/et. c.
been addressed? This would seem important, as it sounds like 1.7 will
solve a lot of other problems, but lack of XP support would mean that
1.7 RC1 won’t help most installations.

Thanks,

mm

Ilias Tsigkogiannis wrote:

The KMDF 1.7 coinstaller opens the service using the SCM APIs and if it fails, then it upgrades/fixes the framework (and installs the driver). So this should take care of your problem. Since the 1.7 coinstallers will be available soon (with the Windows Server 2008 WDK) would it be possible for you to wait and use them (there are many issues that were fixed both in the 1.7 coinstallers and in WDF 1.7. You can look at http://blogs.msdn.com/iliast/archive/2007/12/13/wdf-1-7-rc1-has-been-released.aspx and http://blogs.msdn.com/bobkjelgaard/archive/2007/12/13/kmdf-1-7-and-the-server-2008-vista-sp1-rc1-wdk.aspx for more info) or do you absolutely need to deploy a quick fix right now?

My suggestion is that if you can wait, then please use the KMDF 1.7 RC1 coinstaller for development and testing (from the Windows Server 2008 RC1 WDK) and shortly you’ll be able to use the RTM version, in order to deploy your driver.

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 10:10 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Wdf coinstaller bug

> I wrote about it in my blog in the very first set of posts

I don’t see it there, unless it’s buried somewhere in the discussion of the
accvio on non-English systems.

Do you have a suggestion for a workaround in 1.5? While the nonpnp failure
seems not-so-serious, my driver is an upper volume class filter, so a
failure to load results in an unbootable system with an
INACCESSIBLE_BOOT_DEVICE bugcheck. The customers don’t seem to care for
that…

Off the top of my head, my approach would be: before calling the
coinstaller’s preinstall routine, if the wdf01000 services key does not
exist, delete the wdf01000.sys binary if it exists.

Any big issues with that?

  • Dan.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
Sent: Wednesday, January 16, 2008 10:36 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Wdf coinstaller bug

This is a known issue (for one thing I wrote about it in my blog in the very
first set of posts), and it has been fixed (I believe beginning with 1.7,
but it may be 1.9- I’ll have to wait for Ilias to confirm).

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
Sent: Wednesday, January 16, 2008 9:12 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Wdf coinstaller bug

The WDF coinstaller apparently looks for presence of wdf01000.sys in
system32\drivers to determine if Kmdf is already installed, and doesn’t do
anything if it’s there. This is an insufficient test, as no effort is made
to determine whether the services registry key exists and is correct.

This can easily happen through selecting the “Last known good” boot option,
as it reverts the registry, but does not affect the file system.

In order to make this easy, and eliminate my INF files and install program
from suspicion, I have reproduced the error with the nonpnp sample from WDK
6000. To reproduce, run the nonpnpapp.exe program. Reboot and select the
“Last known good” config. Run nonpnpapp.exe again–it will fail to load the
driver. Manually deleting wdf01000.sys corrects the problem.

  • Dan.

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

9

Thanks, Doron.

mm
Doron Holan wrote:

Yes, the 1.7 coinstaller in the latest 6001 WDK RC now installs on downlevel platforms, XP included

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, January 16, 2008 8:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Wdf coinstaller bug

This has probably already been answered, and I think the answer is yes,
but have the issues with the 1.7 coninstallers working on XP/2K3/et. c.
been addressed? This would seem important, as it sounds like 1.7 will
solve a lot of other problems, but lack of XP support would mean that
1.7 RC1 won’t help most installations.

Thanks,

mm

Ilias Tsigkogiannis wrote:
> The KMDF 1.7 coinstaller opens the service using the SCM APIs and if it fails, then it upgrades/fixes the framework (and installs the driver). So this should take care of your problem. Since the 1.7 coinstallers will be available soon (with the Windows Server 2008 WDK) would it be possible for you to wait and use them (there are many issues that were fixed both in the 1.7 coinstallers and in WDF 1.7. You can look at http://blogs.msdn.com/iliast/archive/2007/12/13/wdf-1-7-rc1-has-been-released.aspx and http://blogs.msdn.com/bobkjelgaard/archive/2007/12/13/kmdf-1-7-and-the-server-2008-vista-sp1-rc1-wdk.aspx for more info) or do you absolutely need to deploy a quick fix right now?
>
> My suggestion is that if you can wait, then please use the KMDF 1.7 RC1 coinstaller for development and testing (from the Windows Server 2008 RC1 WDK) and shortly you’ll be able to use the RTM version, in order to deploy your driver.
>
> Ilias
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
> Sent: Wednesday, January 16, 2008 10:10 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Wdf coinstaller bug
>
>> I wrote about it in my blog in the very first set of posts
> I don’t see it there, unless it’s buried somewhere in the discussion of the
> accvio on non-English systems.
>
> Do you have a suggestion for a workaround in 1.5? While the nonpnp failure
> seems not-so-serious, my driver is an upper volume class filter, so a
> failure to load results in an unbootable system with an
> INACCESSIBLE_BOOT_DEVICE bugcheck. The customers don’t seem to care for
> that…
>
> Off the top of my head, my approach would be: before calling the
> coinstaller’s preinstall routine, if the wdf01000 services key does not
> exist, delete the wdf01000.sys binary if it exists.
>
> Any big issues with that?
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
> Sent: Wednesday, January 16, 2008 10:36 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Wdf coinstaller bug
>
> This is a known issue (for one thing I wrote about it in my blog in the very
> first set of posts), and it has been fixed (I believe beginning with 1.7,
> but it may be 1.9- I’ll have to wait for Ilias to confirm).
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
> Sent: Wednesday, January 16, 2008 9:12 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Wdf coinstaller bug
>
> The WDF coinstaller apparently looks for presence of wdf01000.sys in
> system32\drivers to determine if Kmdf is already installed, and doesn’t do
> anything if it’s there. This is an insufficient test, as no effort is made
> to determine whether the services registry key exists and is correct.
>
> This can easily happen through selecting the “Last known good” boot option,
> as it reverts the registry, but does not affect the file system.
>
> In order to make this easy, and eliminate my INF files and install program
> from suspicion, I have reproduced the error with the nonpnp sample from WDK
> 6000. To reproduce, run the nonpnpapp.exe program. Reboot and select the
> “Last known good” config. Run nonpnpapp.exe again–it will fail to load the
> driver. Manually deleting wdf01000.sys corrects the problem.
>
> - Dan.
>
> —
> 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

10

Thanks, Bob

mm
Bob Kjelgaard wrote:

And in the “would have been nice if we’d told you so” category- the RC0 (September roughly) WDK’s coinstallers also worked downlevel, EXCEPT for Vista. On the other hand, people get confused enough by these missing pieces, all or nothing may have been the best guidance, anyway.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, January 16, 2008 9:05 PM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Wdf coinstaller bug

Yes, the 1.7 coinstaller in the latest 6001 WDK RC now installs on downlevel platforms, XP included

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Martin O’Brien
Sent: Wednesday, January 16, 2008 8:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Wdf coinstaller bug

This has probably already been answered, and I think the answer is yes,
but have the issues with the 1.7 coninstallers working on XP/2K3/et. c.
been addressed? This would seem important, as it sounds like 1.7 will
solve a lot of other problems, but lack of XP support would mean that
1.7 RC1 won’t help most installations.

Thanks,

mm

Ilias Tsigkogiannis wrote:
> The KMDF 1.7 coinstaller opens the service using the SCM APIs and if it fails, then it upgrades/fixes the framework (and installs the driver). So this should take care of your problem. Since the 1.7 coinstallers will be available soon (with the Windows Server 2008 WDK) would it be possible for you to wait and use them (there are many issues that were fixed both in the 1.7 coinstallers and in WDF 1.7. You can look at http://blogs.msdn.com/iliast/archive/2007/12/13/wdf-1-7-rc1-has-been-released.aspx and http://blogs.msdn.com/bobkjelgaard/archive/2007/12/13/kmdf-1-7-and-the-server-2008-vista-sp1-rc1-wdk.aspx for more info) or do you absolutely need to deploy a quick fix right now?
>
> My suggestion is that if you can wait, then please use the KMDF 1.7 RC1 coinstaller for development and testing (from the Windows Server 2008 RC1 WDK) and shortly you’ll be able to use the RTM version, in order to deploy your driver.
>
> Ilias
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
> Sent: Wednesday, January 16, 2008 10:10 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Wdf coinstaller bug
>
>> I wrote about it in my blog in the very first set of posts
> I don’t see it there, unless it’s buried somewhere in the discussion of the
> accvio on non-English systems.
>
> Do you have a suggestion for a workaround in 1.5? While the nonpnp failure
> seems not-so-serious, my driver is an upper volume class filter, so a
> failure to load results in an unbootable system with an
> INACCESSIBLE_BOOT_DEVICE bugcheck. The customers don’t seem to care for
> that…
>
> Off the top of my head, my approach would be: before calling the
> coinstaller’s preinstall routine, if the wdf01000 services key does not
> exist, delete the wdf01000.sys binary if it exists.
>
> Any big issues with that?
>
> - Dan.
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Bob Kjelgaard
> Sent: Wednesday, January 16, 2008 10:36 AM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Wdf coinstaller bug
>
> This is a known issue (for one thing I wrote about it in my blog in the very
> first set of posts), and it has been fixed (I believe beginning with 1.7,
> but it may be 1.9- I’ll have to wait for Ilias to confirm).
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dan Kyler
> Sent: Wednesday, January 16, 2008 9:12 AM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Wdf coinstaller bug
>
> The WDF coinstaller apparently looks for presence of wdf01000.sys in
> system32\drivers to determine if Kmdf is already installed, and doesn’t do
> anything if it’s there. This is an insufficient test, as no effort is made
> to determine whether the services registry key exists and is correct.
>
> This can easily happen through selecting the “Last known good” boot option,
> as it reverts the registry, but does not affect the file system.
>
> In order to make this easy, and eliminate my INF files and install program
> from suspicion, I have reproduced the error with the nonpnp sample from WDK
> 6000. To reproduce, run the nonpnpapp.exe program. Reboot and select the
> “Last known good” config. Run nonpnpapp.exe again–it will fail to load the
> driver. Manually deleting wdf01000.sys corrects the problem.
>
> - Dan.
>
> —
> 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