Handle Invalid error when trying to run a KMDF driver

OSR_Community_User · February 26, 2008, 6:32pm

Hi,

I’m trying to develop a virtual kernel-mode device driver for vista that looks like an audio device to the user but under the covers uses winsock kernel to send and receive audio over a network.

I’ve been working on the winsock functions and that builds and runs just fine using the WDK. However, as soon as I add KMDF_VERSION_MAJOR=1 to my sources file, trying to start the driver fails with a

“[SC] StartService FAILED 6:
The handle is invalid.”

After fighting with my driver for a while I tried several of the KMDF sample drivers included in the WDK (ndisprot and echo to be precise). I followed the build and installation instructions precisely but both fail to start with the same error message.

I have looked in the windows event log, setupact.log, setupapi.app.log and setupapi.dev.log (all with maximum verbosity) (I can post these logs but I don’t have attachment permissions). The one lead I have found is a message from wdf01000 in the event log, that can’t be resolved:

“The description for Event ID 1 from source Wdf01000 cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.”

So this is probably the problem, but I cannot find any information about how to reinstall the wdf. I thought that this was the job of the wdf co-installer, but it doesn’t update the file (wdf01000.sys). I tried deleting it, after which windows repair put it back again, but that didn’t fix my problem.

Any thoughts would be much appreciated.

Regards,
Joe.

Doron_Holan · February 26, 2008, 6:41pm

Which WDK are you using to build your driver? 6000 or 6001? What OS are you trying to install on? It looks like Vista from your description.

Is this a PNP driver? If so you cannot use sc.exe to start/stop it. You must device manager or devcon to install the driver and then enable/disable it to force load/unload. If this is a non pnp driver (which is what I am guessing this is based on the samples you mention), there is no INF to run which means the wdf coinstaller does not automatically get into the mix. As such you need to manually invoke the class installer to install the appropriate kmdf runtime. The nonpnp sample (\WinDDK\6000\src\kmdf\nonpnp) shows how to do this in an app

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com.au
Sent: Tuesday, February 26, 2008 3:31 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Handle Invalid error when trying to run a KMDF driver

Hi,

I’m trying to develop a virtual kernel-mode device driver for vista that looks like an audio device to the user but under the covers uses winsock kernel to send and receive audio over a network.

I’ve been working on the winsock functions and that builds and runs just fine using the WDK. However, as soon as I add KMDF_VERSION_MAJOR=1 to my sources file, trying to start the driver fails with a

“[SC] StartService FAILED 6:
The handle is invalid.”

After fighting with my driver for a while I tried several of the KMDF sample drivers included in the WDK (ndisprot and echo to be precise). I followed the build and installation instructions precisely but both fail to start with the same error message.

I have looked in the windows event log, setupact.log, setupapi.app.log and setupapi.dev.log (all with maximum verbosity) (I can post these logs but I don’t have attachment permissions). The one lead I have found is a message from wdf01000 in the event log, that can’t be resolved:

“The description for Event ID 1 from source Wdf01000 cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.”

So this is probably the problem, but I cannot find any information about how to reinstall the wdf. I thought that this was the job of the wdf co-installer, but it doesn’t update the file (wdf01000.sys). I tried deleting it, after which windows repair put it back again, but that didn’t fix my problem.

Any thoughts would be much appreciated.

Regards,
Joe.

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

OSR_Community_User · February 26, 2008, 7:38pm

Thanks for your fast reply. In answer to your questions, I tried
6001.17121; when that didn’t work, I downloaded and tried 6001.18000. My
test platform is vista. It is not a pnp driver; it is a virtual device
that looks like an audio device to the user but actually uses winsock
kernel to send the audio elsewhere.

In trying out echo/ndisprot I followed the instructions in the
documentation, including using device manager to start/stop (only they
wouldn’t start).

I have now tried out nonpnp as well, and get what seem to be equivalent
symptoms. It asks me to reboot (I doubt this is intended), but after I do
and rerun nonpnpapp.exe it just asks me to reboot again. It seems to be
tripping over upgrading wdf01000.sys. I have pasted the setupact.log below.

Regards,
Joe.

WdfCoInstaller: [02/27/2008 11:09.54.435] ReadComponents: WdfSection for
Driver Service nonpnp using KMDF lib version Major 0x1, minor 0x7
WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE: Coinstaller
version: 1.7.6001
WdfCoInstaller: [02/27/2008 11:09.54.467] GetInMemoryVersionUlong: No
information about in-memory KMDF version
WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE: KMDF
in-memory version: 0.0.0
WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: KMDF on-disk
version: 1.5.6000
WdfCoInstaller: [02/27/2008 11:09.54.560] Service Wdf01000 is running
WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: Reboot is
required, so that the newer KMDF version will be loaded to memory
WdfCoInstaller: [02/27/2008 11:09.55.122] VerifyMSRoot: exit: error(0) The
operation completed successfully.
WdfCoInstaller: [02/27/2008 11:09.55.512] Invoking
“C:\Windows\system32\wusa.exe “C:\Windows\Temp\WdfTemp\Microsoft
Kernel-Mode Driver Framework Install-v1.7-Vista.msu” /quiet /norestart”.
WdfCoInstaller: [02/27/2008 11:10.17.851] Update process returned error
code 0 :error(0) The operation completed successfully.
WdfCoInstaller: [02/27/2008 11:10.17.898] InstallComponents: KMDF
installed successfully
WdfCoInstaller: [02/27/2008 11:10.17.898] InstallComponents: Reboot needed
by windows update
WdfCoInstaller: [02/27/2008 11:16.19.659] ReadComponents: WdfSection for
Driver Service nonpnp using KMDF lib version Major 0x1, minor 0x7
WdfCoInstaller: [02/27/2008 11:16.19.690] DIF_INSTALLDEVICE: Coinstaller
version: 1.7.6001
WdfCoInstaller: [02/27/2008 11:16.19.705] GetInMemoryVersionUlong: No
information about in-memory KMDF version
WdfCoInstaller: [02/27/2008 11:16.19.705] DIF_INSTALLDEVICE: KMDF
in-memory version: 0.0.0
WdfCoInstaller: [02/27/2008 11:16.19.705] DIF_INSTALLDEVICE: KMDF on-disk
version: 1.5.6000
WdfCoInstaller: [02/27/2008 11:16.19.721] Service Wdf01000 is running
WdfCoInstaller: [02/27/2008 11:16.19.721] DIF_INSTALLDEVICE: Reboot is
required, so that the newer KMDF version will be loaded to memory
WdfCoInstaller: [02/27/2008 11:16.20.095] VerifyMSRoot: exit: error(0) The
operation completed successfully.
WdfCoInstaller: [02/27/2008 11:16.20.361] Invoking
“C:\Windows\system32\wusa.exe “C:\Windows\Temp\WdfTemp\Microsoft
Kernel-Mode Driver Framework Install-v1.7-Vista.msu” /quiet /norestart”.
WdfCoInstaller: [02/27/2008 11:16.41.202] Update process returned error
code 0 :error(0) The operation completed successfully.
WdfCoInstaller: [02/27/2008 11:16.41.233] InstallComponents: KMDF
installed successfully
WdfCoInstaller: [02/27/2008 11:16.41.249] InstallComponents: Reboot needed
by windows update

On Wed, 27 Feb 2008 10:38:16 +1100, Doron Holan
wrote:

> Which WDK are you using to build your driver? 6000 or 6001? What OS
> are you trying to install on? It looks like Vista from your description.
>
> Is this a PNP driver? If so you cannot use sc.exe to start/stop it.
> You must device manager or devcon to install the driver and then
> enable/disable it to force load/unload. If this is a non pnp driver
> (which is what I am guessing this is based on the samples you mention),
> there is no INF to run which means the wdf coinstaller does not
> automatically get into the mix. As such you need to manually invoke the
> class installer to install the appropriate kmdf runtime. The nonpnp
> sample (\WinDDK\6000\src\kmdf\nonpnp) shows how to do this in an app
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of
> xxxxx@yahoo.com.au
> Sent: Tuesday, February 26, 2008 3:31 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Handle Invalid error when trying to run a KMDF driver
>
> Hi,
>
> I’m trying to develop a virtual kernel-mode device driver for vista that
> looks like an audio device to the user but under the covers uses winsock
> kernel to send and receive audio over a network.
>
> I’ve been working on the winsock functions and that builds and runs just
> fine using the WDK. However, as soon as I add KMDF_VERSION_MAJOR=1 to my
> sources file, trying to start the driver fails with a
>
> “[SC] StartService FAILED 6:
> The handle is invalid.”
>
> After fighting with my driver for a while I tried several of the KMDF
> sample drivers included in the WDK (ndisprot and echo to be precise). I
> followed the build and installation instructions precisely but both fail
> to start with the same error message.
>
> I have looked in the windows event log, setupact.log, setupapi.app.log
> and setupapi.dev.log (all with maximum verbosity) (I can post these
> logs but I don’t have attachment permissions). The one lead I have found
> is a message from wdf01000 in the event log, that can’t be resolved:
>
> “The description for Event ID 1 from source Wdf01000 cannot be found.
> Either the component that raises this event is not installed on your
> local computer or the installation is corrupted. You can install or
> repair the component on the local computer.”
>
> So this is probably the problem, but I cannot find any information about
> how to reinstall the wdf. I thought that this was the job of the wdf
> co-installer, but it doesn’t update the file (wdf01000.sys). I tried
> deleting it, after which windows repair put it back again, but that
> didn’t fix my problem.
>
> Any thoughts would be much appreciated.
>
> Regards,
> Joe.
>
>
> —
> 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

–
Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/

Tim_Roberts · February 26, 2008, 8:07pm

Joseph Thomas-Kerr wrote:

I have now tried out nonpnp as well, and get what seem to be
equivalent symptoms. It asks me to reboot (I doubt this is intended),
but after I do and rerun nonpnpapp.exe it just asks me to reboot
again. It seems to be tripping over upgrading wdf01000.sys. I have
pasted the setupact.log below.

Regards,
Joe.

WdfCoInstaller: [02/27/2008 11:09.54.435] ReadComponents: WdfSection
for Driver Service nonpnp using KMDF lib version Major 0x1, minor 0x7
WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE:
Coinstaller version: 1.7.6001
WdfCoInstaller: [02/27/2008 11:09.54.467] GetInMemoryVersionUlong: No
information about in-memory KMDF version
WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE: KMDF
in-memory version: 0.0.0
WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: KMDF
on-disk version: 1.5.6000
WdfCoInstaller: [02/27/2008 11:09.54.560] Service Wdf01000 is running
WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: Reboot is
required, so that the newer KMDF version will be loaded to memory

Yes, unfortunately, the reboot is intentional. This is the rather
significant downside of the decision to ship KMDF as a kernel DLL
instead of a linkable library, like USBCAMD. If any KMDF driver is
loaded, installing another device with a newer KMDF will require a
reboot. I suspect there are going to be some angry support calls about
it, and it is only going to get worse as KMDF gets more popular.

The hope, of course, is that KMDF will stabilize very quickly, and that
1.7 will last us many years.

The confusion here seems to stem from the installer’s determination that
a KMDF driver is running (“Service Wdf01000 is running”), even though it
couldn’t contact it. It could be that there is a registry confusion.

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

OSR_Community_User · February 26, 2008, 8:20pm

Hi Tim,

Thanks for the info. But its not the reboot that I am complaining about.
Its the fact that KMDF doesn’t work before or after the reboot.

Regards,
Joe.

On Wed, 27 Feb 2008 12:06:24 +1100, Tim Roberts wrote:

> Joseph Thomas-Kerr wrote:
>>
>> I have now tried out nonpnp as well, and get what seem to be equivalent
>> symptoms. It asks me to reboot (I doubt this is intended), but after I
>> do and rerun nonpnpapp.exe it just asks me to reboot again. It seems to
>> be tripping over upgrading wdf01000.sys. I have pasted the setupact.log
>> below.
>>
>> Regards,
>> Joe.
>>
>> WdfCoInstaller: [02/27/2008 11:09.54.435] ReadComponents: WdfSection
>> for Driver Service nonpnp using KMDF lib version Major 0x1, minor 0x7
>> WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE:
>> Coinstaller version: 1.7.6001
>> WdfCoInstaller: [02/27/2008 11:09.54.467] GetInMemoryVersionUlong: No
>> information about in-memory KMDF version
>> WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE: KMDF
>> in-memory version: 0.0.0
>> WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: KMDF
>> on-disk version: 1.5.6000
>> WdfCoInstaller: [02/27/2008 11:09.54.560] Service Wdf01000 is running
>> WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: Reboot is
>> required, so that the newer KMDF version will be loaded to memory
>
> Yes, unfortunately, the reboot is intentional. This is the rather
> significant downside of the decision to ship KMDF as a kernel DLL
> instead of a linkable library, like USBCAMD. If any KMDF driver is
> loaded, installing another device with a newer KMDF will require a
> reboot. I suspect there are going to be some angry support calls about
> it, and it is only going to get worse as KMDF gets more popular.
>
> The hope, of course, is that KMDF will stabilize very quickly, and that
> 1.7 will last us many years.
>
> The confusion here seems to stem from the installer’s determination that
> a KMDF driver is running (“Service Wdf01000 is running”), even though it
> couldn’t contact it. It could be that there is a registry confusion.
>

–
Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/

OSR_Community_User · February 26, 2008, 8:56pm

We’ve been getting questions about problems with KMDF 1.7 installation on top of Vista RTM. There’s an issue with a recent update (http://support.microsoft.com/kb/938371) released by MS as a prerequisite for Windows Vista Service Pack 1 (SP1). It is preventing installation of KMDF 1.7 due to versioning issues. We’re investigating the causes of the version problems and are trying to come up with a solution. In the meantime, we suggest rejecting (or delaying) installation of that patch on your test machines. Also, we ask that you do not release driver packages with the currently available KMDF 1.7 co-installer until we’ve got a solution for this problem.

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Thomas-Kerr
Sent: Tuesday, February 26, 2008 5:20 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Handle Invalid error when trying to run a KMDF driver

Hi Tim,

Thanks for the info. But its not the reboot that I am complaining about.
Its the fact that KMDF doesn’t work before or after the reboot.

Regards,
Joe.

On Wed, 27 Feb 2008 12:06:24 +1100, Tim Roberts wrote:

> Joseph Thomas-Kerr wrote:
>>
>> I have now tried out nonpnp as well, and get what seem to be equivalent
>> symptoms. It asks me to reboot (I doubt this is intended), but after I
>> do and rerun nonpnpapp.exe it just asks me to reboot again. It seems to
>> be tripping over upgrading wdf01000.sys. I have pasted the setupact.log
>> below.
>>
>> Regards,
>> Joe.
>>
>> WdfCoInstaller: [02/27/2008 11:09.54.435] ReadComponents: WdfSection
>> for Driver Service nonpnp using KMDF lib version Major 0x1, minor 0x7
>> WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE:
>> Coinstaller version: 1.7.6001
>> WdfCoInstaller: [02/27/2008 11:09.54.467] GetInMemoryVersionUlong: No
>> information about in-memory KMDF version
>> WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE: KMDF
>> in-memory version: 0.0.0
>> WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: KMDF
>> on-disk version: 1.5.6000
>> WdfCoInstaller: [02/27/2008 11:09.54.560] Service Wdf01000 is running
>> WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: Reboot is
>> required, so that the newer KMDF version will be loaded to memory
>
> Yes, unfortunately, the reboot is intentional. This is the rather
> significant downside of the decision to ship KMDF as a kernel DLL
> instead of a linkable library, like USBCAMD. If any KMDF driver is
> loaded, installing another device with a newer KMDF will require a
> reboot. I suspect there are going to be some angry support calls about
> it, and it is only going to get worse as KMDF gets more popular.
>
> The hope, of course, is that KMDF will stabilize very quickly, and that
> 1.7 will last us many years.
>
> The confusion here seems to stem from the installer’s determination that
> a KMDF driver is running (“Service Wdf01000 is running”), even though it
> couldn’t contact it. It could be that there is a registry confusion.
>

–
Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/

—
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

OSR_Community_User · February 26, 2008, 9:26pm

Also, another workaround that you can do for testing purposes in your test machines is to “disassemble” the coinstaller, as is described at
http://blogs.msdn.com/bobkjelgaard/archive/2007/12/13/kmdf-1-7-and-the-server-2008-vista-sp1-rc1-wdk.aspx, get the KMDF files (wdf0100.sys and wdfldr.sys) and use the technique described at http://kernelmustard.com/2007/03/27/the-death-of-wfp/ to install them in your Vista RTM test machines.

As I said above, we’re already working on providing a permanent solution for this issue.

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ilias Tsigkogiannis
Sent: Tuesday, February 26, 2008 5:55 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Handle Invalid error when trying to run a KMDF driver

We’ve been getting questions about problems with KMDF 1.7 installation on top of Vista RTM. There’s an issue with a recent update (http://support.microsoft.com/kb/938371) released by MS as a prerequisite for Windows Vista Service Pack 1 (SP1). It is preventing installation of KMDF 1.7 due to versioning issues. We’re investigating the causes of the version problems and are trying to come up with a solution. In the meantime, we suggest rejecting (or delaying) installation of that patch on your test machines. Also, we ask that you do not release driver packages with the currently available KMDF 1.7 co-installer until we’ve got a solution for this problem.

Ilias

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph Thomas-Kerr
Sent: Tuesday, February 26, 2008 5:20 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Handle Invalid error when trying to run a KMDF driver

Hi Tim,

Thanks for the info. But its not the reboot that I am complaining about.
Its the fact that KMDF doesn’t work before or after the reboot.

Regards,
Joe.

On Wed, 27 Feb 2008 12:06:24 +1100, Tim Roberts wrote:

> Joseph Thomas-Kerr wrote:
>>
>> I have now tried out nonpnp as well, and get what seem to be equivalent
>> symptoms. It asks me to reboot (I doubt this is intended), but after I
>> do and rerun nonpnpapp.exe it just asks me to reboot again. It seems to
>> be tripping over upgrading wdf01000.sys. I have pasted the setupact.log
>> below.
>>
>> Regards,
>> Joe.
>>
>> WdfCoInstaller: [02/27/2008 11:09.54.435] ReadComponents: WdfSection
>> for Driver Service nonpnp using KMDF lib version Major 0x1, minor 0x7
>> WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE:
>> Coinstaller version: 1.7.6001
>> WdfCoInstaller: [02/27/2008 11:09.54.467] GetInMemoryVersionUlong: No
>> information about in-memory KMDF version
>> WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE: KMDF
>> in-memory version: 0.0.0
>> WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: KMDF
>> on-disk version: 1.5.6000
>> WdfCoInstaller: [02/27/2008 11:09.54.560] Service Wdf01000 is running
>> WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: Reboot is
>> required, so that the newer KMDF version will be loaded to memory
>
> Yes, unfortunately, the reboot is intentional. This is the rather
> significant downside of the decision to ship KMDF as a kernel DLL
> instead of a linkable library, like USBCAMD. If any KMDF driver is
> loaded, installing another device with a newer KMDF will require a
> reboot. I suspect there are going to be some angry support calls about
> it, and it is only going to get worse as KMDF gets more popular.
>
> The hope, of course, is that KMDF will stabilize very quickly, and that
> 1.7 will last us many years.
>
> The confusion here seems to stem from the installer’s determination that
> a KMDF driver is running (“Service Wdf01000 is running”), even though it
> couldn’t contact it. It could be that there is a registry confusion.
>

–
Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/

—
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

OSR_Community_User · February 27, 2008, 1:15am

Thanks for the info. It’s done the trick :). Apologies for the
cross-posting.

On Wed, 27 Feb 2008 10:25:39 +0800, Ilias Tsigkogiannis
wrote:

> Also, another workaround that you can do for testing purposes in your
> test machines is to “disassemble” the coinstaller, as is described at
> http://blogs.msdn.com/bobkjelgaard/archive/2007/12/13/kmdf-1-7-and-the-server-2008-vista-sp1-rc1-wdk.aspx,
> get the KMDF files (wdf0100.sys and wdfldr.sys) and use the technique
> described at http://kernelmustard.com/2007/03/27/the-death-of-wfp/ to
> install them in your Vista RTM test machines.
>
> As I said above, we’re already working on providing a permanent solution
> for this issue.
>
> Ilias
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Ilias
> Tsigkogiannis
> Sent: Tuesday, February 26, 2008 5:55 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Handle Invalid error when trying to run a KMDF
> driver
>
> We’ve been getting questions about problems with KMDF 1.7 installation
> on top of Vista RTM. There’s an issue with a recent update
> (http://support.microsoft.com/kb/938371) released by MS as a
> prerequisite for Windows Vista Service Pack 1 (SP1). It is preventing
> installation of KMDF 1.7 due to versioning issues. We’re investigating
> the causes of the version problems and are trying to come up with a
> solution. In the meantime, we suggest rejecting (or delaying)
> installation of that patch on your test machines. Also, we ask that you
> do not release driver packages with the currently available KMDF 1.7
> co-installer until we’ve got a solution for this problem.
>
> Ilias
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Joseph
> Thomas-Kerr
> Sent: Tuesday, February 26, 2008 5:20 PM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Handle Invalid error when trying to run a KMDF
> driver
>
> Hi Tim,
>
> Thanks for the info. But its not the reboot that I am complaining about.
> Its the fact that KMDF doesn’t work before or after the reboot.
>
> Regards,
> Joe.
>
> On Wed, 27 Feb 2008 12:06:24 +1100, Tim Roberts wrote:
>
>> Joseph Thomas-Kerr wrote:
>>>
>>> I have now tried out nonpnp as well, and get what seem to be equivalent
>>> symptoms. It asks me to reboot (I doubt this is intended), but after I
>>> do and rerun nonpnpapp.exe it just asks me to reboot again. It seems to
>>> be tripping over upgrading wdf01000.sys. I have pasted the setupact.log
>>> below.
>>>
>>> Regards,
>>> Joe.
>>>
>>> WdfCoInstaller: [02/27/2008 11:09.54.435] ReadComponents: WdfSection
>>> for Driver Service nonpnp using KMDF lib version Major 0x1, minor 0x7
>>> WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE:
>>> Coinstaller version: 1.7.6001
>>> WdfCoInstaller: [02/27/2008 11:09.54.467] GetInMemoryVersionUlong: No
>>> information about in-memory KMDF version
>>> WdfCoInstaller: [02/27/2008 11:09.54.467] DIF_INSTALLDEVICE: KMDF
>>> in-memory version: 0.0.0
>>> WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: KMDF
>>> on-disk version: 1.5.6000
>>> WdfCoInstaller: [02/27/2008 11:09.54.560] Service Wdf01000 is running
>>> WdfCoInstaller: [02/27/2008 11:09.54.560] DIF_INSTALLDEVICE: Reboot is
>>> required, so that the newer KMDF version will be loaded to memory
>>
>> Yes, unfortunately, the reboot is intentional. This is the rather
>> significant downside of the decision to ship KMDF as a kernel DLL
>> instead of a linkable library, like USBCAMD. If any KMDF driver is
>> loaded, installing another device with a newer KMDF will require a
>> reboot. I suspect there are going to be some angry support calls about
>> it, and it is only going to get worse as KMDF gets more popular.
>>
>> The hope, of course, is that KMDF will stabilize very quickly, and that
>> 1.7 will last us many years.
>>
>> The confusion here seems to stem from the installer’s determination that
>> a KMDF driver is running (“Service Wdf01000 is running”), even though it
>> couldn’t contact it. It could be that there is a registry confusion.
>>
>
>
>
> –
> Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/
>
> —
> 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

–
Using Opera’s revolutionary e-mail client: http://www.opera.com/mail/

OSR_Community_User · February 27, 2008, 2:54am

Tim Roberts wrote:

The hope, of course, is that KMDF will stabilize very quickly, and that
1.7 will last us many years.

IIRC someone here stated that KMDF 1.9 is already in QA. Looks like this
hope is in vain.

Doron_Holan · February 27, 2008, 10:54am

There will typically be a new version of WDF (both kmdf and umdf) in each OS release. This is not a sign of immaturity though. While each release brings bug fixes and new features (as requested by you our customers), the core functionality of the framework remains the same. If we did not do this, I am sure people would complain that we released a framework and then failed to continue to support, innovate, and keep it relevant for today’s driver writers.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Tuesday, February 26, 2008 11:54 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

Tim Roberts wrote:

The hope, of course, is that KMDF will stabilize very quickly, and that
1.7 will last us many years.

IIRC someone here stated that KMDF 1.9 is already in QA. Looks like this
hope is in vain.

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

OSR_Community_User · February 27, 2008, 11:33am

Doron Holan wrote:

There will typically be a new version of WDF (both kmdf and umdf) in
each OS release.

How about treating it as a “Windows System Component”, then?
Making it available as an extra download (similar to DirectX).
It should also be automatically updated by Windows Update.

Then it would not be necessary to always include a co-installer with a
driver - only to state a requirement for a minimum WDF version in the
driver’s INF file.

Currently, for every WDF driver you always have to include the relevant
co-installer. And in most cases the one delivered with the driver is
probably already superseded by a more current version. Also newer
versions of the framework completely replace older ones.
So why not handle it as an extra component and stop wasting all this
install space and bandwith?

OK, (now that MS started it) I would not take away the option of
delivering a WDF co-installer in a package with a driver.

But I always wondered why there was not just a “WDF_install_X_yy_z.msi”
available. And if a driver needs a newer version, I would get a message
(something like “Required WDF version for this driver is v1.9. Currently
installed version is v1.5. Upgrade now?”).

-H

OSR_Community_User · February 27, 2008, 2:41pm

It’s a tempting idea … the problem is that it then ties all this new device installation technology into specific versions of Windows. Sure your driver package could state that it needs update Y but the code to understand that is probably in update X which has to be applied first.

The only way to resolve the chicken-and-egg problem on downlevel versions of Windows is to use the coinstaller. I’m hoping in the future we can make the coinstaller a little more general purpose since the problems facing KMDF are the same ones that face UMDF, WinUSB, and any other device technology we release out-of-band, but that’s my hope not a plan or a promise.

We’ve made the assumption that no one wants to have separate installation packages - one for pre Win7 and another for Win7 to deal with a radical change in the installation model. So we instead have to use a coinstaller.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Hagen Patzke
Sent: Wednesday, February 27, 2008 8:33 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

Doron Holan wrote:

There will typically be a new version of WDF (both kmdf and umdf) in
each OS release.

How about treating it as a “Windows System Component”, then?
Making it available as an extra download (similar to DirectX).
It should also be automatically updated by Windows Update.

Then it would not be necessary to always include a co-installer with a
driver - only to state a requirement for a minimum WDF version in the
driver’s INF file.

Currently, for every WDF driver you always have to include the relevant
co-installer. And in most cases the one delivered with the driver is
probably already superseded by a more current version. Also newer
versions of the framework completely replace older ones.
So why not handle it as an extra component and stop wasting all this
install space and bandwith?

OK, (now that MS started it) I would not take away the option of
delivering a WDF co-installer in a package with a driver.

But I always wondered why there was not just a “WDF_install_X_yy_z.msi”
available. And if a driver needs a newer version, I would get a message
(something like “Required WDF version for this driver is v1.9. Currently
installed version is v1.5. Upgrade now?”).

-H

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

Don_Burn_1 · February 27, 2008, 2:49pm

One problem I don’t see how you will address with the co-installer approach
is the need for drivers to run at Windows installation time. I now have had
two different customers who jumped on the KMDF bandwagon and then discovered
after rewriting their drivers to KMDF that they could not use them as part
of an install. Since in both cases the drivers were needed for Windows to
work, both firms now have corporate edicts “NO WDF!!!”

This is frustrating, since I have just finished some new drivers for them
that otherwise would be perfect for KMDF, but need to be part of the
install.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
It’s a tempting idea … the problem is that it then ties all this new
device installation technology into specific versions of Windows. Sure your
driver package could state that it needs update Y but the code to understand
that is probably in update X which has to be applied first.

The only way to resolve the chicken-and-egg problem on downlevel versions of
Windows is to use the coinstaller. I’m hoping in the future we can make the
coinstaller a little more general purpose since the problems facing KMDF are
the same ones that face UMDF, WinUSB, and any other device technology we
release out-of-band, but that’s my hope not a plan or a promise.

We’ve made the assumption that no one wants to have separate installation
packages - one for pre Win7 and another for Win7 to deal with a radical
change in the installation model. So we instead have to use a coinstaller.

-p

Tim_Roberts · February 27, 2008, 2:56pm

Peter Wieland wrote:

…
The only way to resolve the chicken-and-egg problem on downlevel versions of Windows is to use the coinstaller. I’m hoping in the future we can make the coinstaller a little more general purpose since the problems facing KMDF are the same ones that face UMDF, WinUSB, and any other device technology we release out-of-band, but that’s my hope not a plan or a promise.

We’ve made the assumption that no one wants to have separate installation packages - one for pre Win7 and another for Win7 to deal with a radical change in the installation model. So we instead have to use a coinstaller.

Making it a statically linked library would have solved many of these
issues. If my driver is tested with KMDF 1.5, then it can use KMDF
forever, even if other drivers are using 1.7 and 1.9.

May I ask why the decision was made to call the helper wdf01000.sys,
instead of wdf01001.sys, wdf01005.sys, and wdf01007.sys? That, also,
would have solved this problem, at the expense of 0.025c worth of disk
space.

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

OSR_Community_User · February 27, 2008, 3:12pm

And would have resulted in a large body of MS kernel-mode code which couldn’t be detected, serviced or blocked if a major security vulnerability was found.

And while you might be kind enough to re-release your drivers should such an issue be found I’m quite certain there are many many other drivers that would never get re-released and would just continue to propagate that flaw across the entire ecosystem.

Side-by-side support has a similar issue. From an IT administrator point of view it’s better to have a single patch which will fix a problem and can be rolled back than to have a new form of DLL hell where each driver has to be managed individually.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, February 27, 2008 11:56 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Handle Invalid error when trying to run a KMDF driver

Peter Wieland wrote:

…
The only way to resolve the chicken-and-egg problem on downlevel versions of Windows is to use the coinstaller. I’m hoping in the future we can make the coinstaller a little more general purpose since the problems facing KMDF are the same ones that face UMDF, WinUSB, and any other device technology we release out-of-band, but that’s my hope not a plan or a promise.

We’ve made the assumption that no one wants to have separate installation packages - one for pre Win7 and another for Win7 to deal with a radical change in the installation model. So we instead have to use a coinstaller.

Making it a statically linked library would have solved many of these
issues. If my driver is tested with KMDF 1.5, then it can use KMDF
forever, even if other drivers are using 1.7 and 1.9.

May I ask why the decision was made to call the helper wdf01000.sys,
instead of wdf01001.sys, wdf01005.sys, and wdf01007.sys? That, also,
would have solved this problem, at the expense of 0.025c worth of disk
space.

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

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

OSR_Community_User · February 27, 2008, 3:28pm

I’d like to give some more info on the issue of using an msi to update WDF.

As you know, there are 2 ways to install a device and its driver:

Hardware-first: Plug-in the device, point the “add-new hardware wizard” to the inf and install the driver
Software-first: Install the driver, then plug-in the device

In KMDF and UMDF we want to provide support for both ways and we don’t want to change the model that windows drivers have been using so far. This means that we need an inf to install the driver. If we provided just an msi, which you’d have to install before pluging-in your device, this means that we’re breaking the hardware-first installation. We don’t want to do that, that’s why we have the coinstaller

So, the inf calls the coinstaller, which includes a windows update package. This package updates the WDF binaries that are on disk. From the user’s perspective, it doesn’t have any difference, if the coinstaller is internally using an msi, a windows update package or any other technology. So, just by replacing the update technology and using an msi, wouldn’t give any benefit. On the contrary, we’d have to start development and testing from scratch and find solutions to problems like how it’s possible to overcome Secure File Protection in Windows Vista in such a way that we don’t break support for Windows 2000. At the same time, we also need to keep our binary small. That’s why we’re not changing the current architecture (yet).

Having said that, I’d like to say that we’ve spent a considerable amount of time testing the KMDF 1.7 coinstaller and its behavior in key areas is very different than the KMDF 1.5 one. KB937381 was released after the testing of coinstallers was finished, so it was impossible to predict something like that. Even in this case, though, we were informed about the problem last week and within a few days we were able to find what’s causing it and provide 2 workarounds. At the same time we’re working on providing a permanent fix. Indeed, we understand the pain of driver installation, that’s why many WDF developers and testers are monitoring ntdev, as well as other relevant mailing lists and newsgroups, so that we’re always on speed with what problems people are facing.

Ilias

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Peter Wieland [xxxxx@windows.microsoft.com]
Sent: Wednesday, February 27, 2008 12:11 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Handle Invalid error when trying to run a KMDF driver

And would have resulted in a large body of MS kernel-mode code which couldn’t be detected, serviced or blocked if a major security vulnerability was found.

And while you might be kind enough to re-release your drivers should such an issue be found I’m quite certain there are many many other drivers that would never get re-released and would just continue to propagate that flaw across the entire ecosystem.

Side-by-side support has a similar issue. From an IT administrator point of view it’s better to have a single patch which will fix a problem and can be rolled back than to have a new form of DLL hell where each driver has to be managed individually.

-p

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Wednesday, February 27, 2008 11:56 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Handle Invalid error when trying to run a KMDF driver

Peter Wieland wrote:

…
The only way to resolve the chicken-and-egg problem on downlevel versions of Windows is to use the coinstaller. I’m hoping in the future we can make the coinstaller a little more general purpose since the problems facing KMDF are the same ones that face UMDF, WinUSB, and any other device technology we release out-of-band, but that’s my hope not a plan or a promise.

We’ve made the assumption that no one wants to have separate installation packages - one for pre Win7 and another for Win7 to deal with a radical change in the installation model. So we instead have to use a coinstaller.

Making it a statically linked library would have solved many of these
issues. If my driver is tested with KMDF 1.5, then it can use KMDF
forever, even if other drivers are using 1.7 and 1.9.

May I ask why the decision was made to call the helper wdf01000.sys,
instead of wdf01001.sys, wdf01005.sys, and wdf01007.sys? That, also,
would have solved this problem, at the expense of 0.025c worth of disk
space.

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

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

OSR_Community_User · February 27, 2008, 3:40pm

Peter Wieland wrote:

It’s a tempting idea … the problem is that it then ties all this
new device installation technology into specific versions of Windows.
Sure your driver package could state that it needs update Y but the
code to understand that is probably in update X which has to be
applied first.

So you are telling me that in all of these Windows older driver
installers there is absolutely no mechanism to inform anybody that a
system component necessary for driver installation is missing?
Not even with a text message?

Come on, even then there could be a ‘stub’ that informs the user of the
fact. As we had (still have?) in Windows EXE files that tell you “This
program does not run in DOS mode.”.

And don’t underestimate the amount of install hassle ordinary Windows
users have become used to during all these years of “Windows
Experience”. YOu use an outdated version? OK, it will even be harder.

Or someone has to get a system architect to MS. Quick. Swap her for
someone from marketing - they are excellent and surely can spare one person.

We’ve made the assumption that no one wants to have separate
> installation packages - one for pre Win7 and another for Win7 to deal
> with a radical change in the installation model. So we instead have
> to use a coinstaller.

People have become used to have separate drivers for Win16, Win32s,
Win95, Win98, Win98SE, WinME, Win2000, Win2003Server, WinXP and
WinVista. Oh, and the 64 bit versions, of course.
So used that some of them who happen to be driver developers even deny
the possibility of writing one driver for everything from Win98 (with
limitations) up to Vista.

Great - I’m looking forward to a brave new world where every driver
package will even bigger than in earlier times because now not only a
bloated install program is delivered (to make sure the files are
actually found), but additionally with every WDF driver comes a
coinstaller. Well, the price of progress, I guess…

Sorry for ranting, but this reminds me painfully of a three-disk
installer for an external CD writer that would not run on NT4 with a
“file not found” message.
Luckily it was an old archive type that I managed to find an unpacker
for. Turns out that more 2 and 3/4 disks were actually the (compressed!)
install program.
The real driver consisted of one INF and two SYS files, totalling less
than 200kB. And of course someone had made a typo in the INF file, and
obviously forgot to test it on NT4.
The standard Windows device installer was absolutely happy taking the
INF/SYS from a subdirectory on a single 3.5" disk.

Now we will at least a single CD. Or DVD. Heck, now I know why BlueRay
had to be invented. (Grrrrrr!)

So much my 2cents of steam-off. No offense.

OSR_Community_User · February 27, 2008, 3:47pm

While were close to the subject, any idea of what a ‘.wdf’ file with a
size of 0 bytes that lives in ‘\Windows\System32\Drivers’ does. For
example, ‘msftwdf_kernel_01005_coninstaller_critical.wdf.’ They may be
unrelated to WDF, they may be malware; I have no idea. I just saw three
files like this ‘msft_…’ one one of my targets.

Thanks,

mm

Tim Roberts wrote:

Peter Wieland wrote:
> …
> The only way to resolve the chicken-and-egg problem on downlevel
> versions of Windows is to use the coinstaller. I’m hoping in the
> future we can make the coinstaller a little more general purpose since
> the problems facing KMDF are the same ones that face UMDF, WinUSB, and
> any other device technology we release out-of-band, but that’s my hope
> not a plan or a promise.
>
> We’ve made the assumption that no one wants to have separate
> installation packages - one for pre Win7 and another for Win7 to deal
> with a radical change in the installation model. So we instead have
> to use a coinstaller.
>

Making it a statically linked library would have solved many of these
issues. If my driver is tested with KMDF 1.5, then it can use KMDF
forever, even if other drivers are using 1.7 and 1.9.

May I ask why the decision was made to call the helper wdf01000.sys,
instead of wdf01001.sys, wdf01005.sys, and wdf01007.sys? That, also,
would have solved this problem, at the expense of 0.025c worth of disk
space.

OSR_Community_User · February 27, 2008, 3:51pm

The coinstaller just by itself is just a few kb. It’s not bloated at all. The big size of the redistributable is caused by the update package that’s inside the coinstaller. And yes, it’s really easy to say “this driver cannot be installed in the system. Please use wdf17.msi”. However, do think that customers would like it, if they are not able to do hardware-first device installations? For an additional explation, please look at my previous email.

Ilias

From: xxxxx@lists.osr.com [xxxxx@lists.osr.com] On Behalf Of Hagen Patzke [xxxxx@hotmail.com]
Sent: Wednesday, February 27, 2008 12:40 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Handle Invalid error when trying to run a KMDF driver

Peter Wieland wrote:

It’s a tempting idea … the problem is that it then ties all this
new device installation technology into specific versions of Windows.
Sure your driver package could state that it needs update Y but the
code to understand that is probably in update X which has to be
applied first.

So you are telling me that in all of these Windows older driver
installers there is absolutely no mechanism to inform anybody that a
system component necessary for driver installation is missing?
Not even with a text message?

Come on, even then there could be a ‘stub’ that informs the user of the
fact. As we had (still have?) in Windows EXE files that tell you “This
program does not run in DOS mode.”.

And don’t underestimate the amount of install hassle ordinary Windows
users have become used to during all these years of “Windows
Experience”. YOu use an outdated version? OK, it will even be harder.

Or someone has to get a system architect to MS. Quick. Swap her for
someone from marketing - they are excellent and surely can spare one person.

We’ve made the assumption that no one wants to have separate
> installation packages - one for pre Win7 and another for Win7 to deal
> with a radical change in the installation model. So we instead have
> to use a coinstaller.

People have become used to have separate drivers for Win16, Win32s,
Win95, Win98, Win98SE, WinME, Win2000, Win2003Server, WinXP and
WinVista. Oh, and the 64 bit versions, of course.
So used that some of them who happen to be driver developers even deny
the possibility of writing one driver for everything from Win98 (with
limitations) up to Vista.

Great - I’m looking forward to a brave new world where every driver
package will even bigger than in earlier times because now not only a
bloated install program is delivered (to make sure the files are
actually found), but additionally with every WDF driver comes a
coinstaller. Well, the price of progress, I guess…

Sorry for ranting, but this reminds me painfully of a three-disk
installer for an external CD writer that would not run on NT4 with a
“file not found” message.
Luckily it was an old archive type that I managed to find an unpacker
for. Turns out that more 2 and 3/4 disks were actually the (compressed!)
install program.
The real driver consisted of one INF and two SYS files, totalling less
than 200kB. And of course someone had made a typo in the INF file, and
obviously forgot to test it on NT4.
The standard Windows device installer was absolutely happy taking the
INF/SYS from a subdirectory on a single 3.5" disk.

Now we will at least a single CD. Or DVD. Heck, now I know why BlueRay
had to be invented. (Grrrrrr!)

So much my 2cents of steam-off. No offense.

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

OSR_Community_User · February 27, 2008, 3:52pm

You mean drivers that need to be loaded in txtsetup I assume?

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Wednesday, February 27, 2008 11:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Re:Handle Invalid error when trying to run a KMDF driver

One problem I don’t see how you will address with the co-installer approach
is the need for drivers to run at Windows installation time. I now have had
two different customers who jumped on the KMDF bandwagon and then discovered
after rewriting their drivers to KMDF that they could not use them as part
of an install. Since in both cases the drivers were needed for Windows to
work, both firms now have corporate edicts “NO WDF!!!”

This is frustrating, since I have just finished some new drivers for them
that otherwise would be perfect for KMDF, but need to be part of the
install.

–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

“Peter Wieland” wrote in message
news:xxxxx@ntdev…
It’s a tempting idea … the problem is that it then ties all this new
device installation technology into specific versions of Windows. Sure your
driver package could state that it needs update Y but the code to understand
that is probably in update X which has to be applied first.

The only way to resolve the chicken-and-egg problem on downlevel versions of
Windows is to use the coinstaller. I’m hoping in the future we can make the
coinstaller a little more general purpose since the problems facing KMDF are
the same ones that face UMDF, WinUSB, and any other device technology we
release out-of-band, but that’s my hope not a plan or a promise.

We’ve made the assumption that no one wants to have separate installation
packages - one for pre Win7 and another for Win7 to deal with a radical
change in the installation model. So we instead have to use a coinstaller.

-p

—
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