Install issue with KMDF 1.1

NTDEV
1

I had an interesting experience. I had delivered a test driver and a
test app based on KMDF 1.0 to another developer. I updated the driver
and in the process updated it to KMDF 1.1. This driver has an install
program that is very similar in nature to devcon.exe. The update of the
driver failed and the error in setupact.log implied that I was using the
checked version of the coinstaller on a free system or vice versa. I
double-checked the DLL and it was indeed the correct version. I
instructed the other developer to remove the old wdf*.sys files and try
it again. Same error. He removed the device in device manger, removed
the INF and PNF files, and rebooted. It then installed correctly. I
assume that there must have been a step that I missed in my install
program. Any idea what it was? Unless I missed something really obvious,
I can see this becoming a problem in the field once more WDF drivers get
released and new KMDF releases start appearing with them.

Beverly

2

What did setupact.log say exactly? Can you send out the contents? In the process of the install, did you touch wdfcoinstaller01000.dll (e.g. did you delete it?). Our test team ran the following scenario and it worked just fine

  1. install a driver using KMDF 1.0
  2. recompile the driver for v1.1 and then update the installed devnode.

If this is the only KMDF driver loaded, then this works w/out a reboot. If there are other KMDF drivers loaded, we cannot unload v1.0 of KMDF and require a reboot to get it loaded.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 2:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Install issue with KMDF 1.1

I had an interesting experience. I had delivered a test driver and a test app based on KMDF 1.0 to another developer. I updated the driver and in the process updated it to KMDF 1.1. This driver has an install program that is very similar in nature to devcon.exe.? The update of the driver failed and the error in setupact.log implied that I was using the checked version of the coinstaller on a free system or vice versa. I double-checked the DLL and it was indeed the correct version. I instructed the other developer to remove the old wdf*.sys files and try it again. Same error. He removed the device in device manger, removed the INF and PNF files, and rebooted. It then installed correctly. I assume that there must have been a step that I missed in my install program. Any idea what it was? Unless I missed something really obvious, I can see this becoming a problem in the field once more WDF drivers get released and new KMDF releases start appearing with them.
?
Beverly

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

3

Also, %windir%\Wdf010001inst.log. you can send me that entire file + snippet from setupact.log to my msft email directly, no need to spam everyone with a large email.

d

– I can spell, I just can’t type.

-----Original Message-----
From: Doron Holan
Sent: Thursday, May 18, 2006 2:44 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What did setupact.log say exactly? Can you send out the contents? In the process of the install, did you touch wdfcoinstaller01000.dll (e.g. did you delete it?). Our test team ran the following scenario and it worked just fine

  1. install a driver using KMDF 1.0
  2. recompile the driver for v1.1 and then update the installed devnode.

If this is the only KMDF driver loaded, then this works w/out a reboot. If there are other KMDF drivers loaded, we cannot unload v1.0 of KMDF and require a reboot to get it loaded.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 2:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Install issue with KMDF 1.1

I had an interesting experience. I had delivered a test driver and a test app based on KMDF 1.0 to another developer. I updated the driver and in the process updated it to KMDF 1.1. This driver has an install program that is very similar in nature to devcon.exe.? The update of the driver failed and the error in setupact.log implied that I was using the checked version of the coinstaller on a free system or vice versa. I double-checked the DLL and it was indeed the correct version. I instructed the other developer to remove the old wdf*.sys files and try it again. Same error. He removed the device in device manger, removed the INF and PNF files, and rebooted. It then installed correctly. I assume that there must have been a step that I missed in my install program. Any idea what it was? Unless I missed something really obvious, I can see this becoming a problem in the field once more WDF drivers get released and new KMDF releases start appearing with them.
?
Beverly

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

4

Correct me if I’m wrong. From year or two old discussions I had a feeling it was planned to have both static and dynamic version of KMDF. What I see here resembles MFC DLL hell. Is there a possinility to use KMDF as a static library to make things simpler?

Best regards,

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

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, May 18, 2006 11:44 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What did setupact.log say exactly? Can you send out the contents? In the process of the install, did you touch wdfcoinstaller01000.dll (e.g. did you delete it?). Our test team ran the following scenario and it worked just fine

  1. install a driver using KMDF 1.0
  2. recompile the driver for v1.1 and then update the installed devnode.

If this is the only KMDF driver loaded, then this works w/out a reboot. If there are other KMDF drivers loaded, we cannot unload v1.0 of KMDF and require a reboot to get it loaded.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 2:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Install issue with KMDF 1.1

I had an interesting experience. I had delivered a test driver and a test app based on KMDF 1.0 to another developer. I updated the driver and in the process updated it to KMDF 1.1. This driver has an install program that is very similar in nature to devcon.exe. The update of the driver failed and the error in setupact.log implied that I was using the checked version of the coinstaller on a free system or vice versa. I double-checked the DLL and it was indeed the correct version. I instructed the other developer to remove the old wdf*.sys files and try it again. Same error. He removed the device in device manger, removed the INF and PNF files, and rebooted. It then installed correctly. I assume that there must have been a step that I missed in my install program. Any idea what it was? Unless I missed something really obvious, I can see this becoming a problem in the field once more WDF drivers get released and new KMDF releases start appearing with them.

Beverly

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

There were no other KMDF drivers on the system - just the two that get installed from the same INF (one is a filter driver for the other). The existing coinstaller DLL (version 1.0) did not get touched.

Before the setup program does an update, it removes the old device nodes and finds and removes old INF and PNF files as well. It then tells the system to do a rescan. It does this so that it closely resembles a clean system when the driver gets re-installed. In the past, this has worked out best for test environments to avoid cluttering up the system with old INF and PNF files and sometimes getting the old driver re-installed inadvertently because of those files being present on the system. One thing that this setup program didn’t do, that I had done in the past was delete the old services after removing the device nodes. I’m thinking now that might be the step that I missed. Hmmm, if that’s the step that I missed, maybe I have a leak in the driver unload that was keeping the old WDF from getting unloaded completely therefore preventing a new one from getting installed for it. If that was the case, though, wouldn’t the WDF verifier report a leak?

I’ll try to reproduce it and see what triggered the problem.

In the meantime, this is a direct copy of the text from setupact.log:

WdfCoInstaller: [05/18/2006 11:03.02.625] DIF_INSTALLDEVICE: Pre-Processing

WdfCoInstaller: [05/18/2006 11:03.02.625] ReadComponents: WdfSection for Driver Service mc_tfilt using KMDF lib version Major 0x1, minor 0x1

WdfCoInstaller: [05/18/2006 11:03.02.625] ReadComponents: WdfSection for Driver Service mc_tdev using KMDF lib version Major 0x1, minor 0x1

WdfCoInstaller: [05/18/2006 11:03.02.703] VerifyMSRoot: exit: error(0) The operation completed successfully.

WdfCoInstaller: [05/18/2006 11:03.09.312] Update process returned error code :error(1603) Fatal error during installation.
. Possible causes are running fre version of coinstaller on checked version of OS and vice versa

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, May 18, 2006 5:44 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What did setupact.log say exactly? Can you send out the contents? In the process of the install, did you touch wdfcoinstaller01000.dll (e.g. did you delete it?). Our test team ran the following scenario and it worked just fine

  1. install a driver using KMDF 1.0
  2. recompile the driver for v1.1 and then update the installed devnode.

If this is the only KMDF driver loaded, then this works w/out a reboot. If there are other KMDF drivers loaded, we cannot unload v1.0 of KMDF and require a reboot to get it loaded.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 2:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Install issue with KMDF 1.1

I had an interesting experience. I had delivered a test driver and a test app based on KMDF 1.0 to another developer. I updated the driver and in the process updated it to KMDF 1.1. This driver has an install program that is very similar in nature to devcon.exe.? The update of the driver failed and the error in setupact.log implied that I was using the checked version of the coinstaller on a free system or vice versa. I double-checked the DLL and it was indeed the correct version. I instructed the other developer to remove the old wdf*.sys files and try it again. Same error. He removed the device in device manger, removed the INF and PNF files, and rebooted. It then installed correctly. I assume that there must have been a step that I missed in my install program. Any idea what it was? Unless I missed something really obvious, I can see this becoming a problem in the field once more WDF drivers get released and new KMDF releases start appearing with them.
?
Beverly

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

6

No. there is no serviceability in the static model so it was never
publicly released. Major versions (major contract changes) of KMDF live
side by side. KMDF minor versions do not change the contracts so they
are able to overwrite existing previous minor versions.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Thursday, May 18, 2006 3:09 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

Correct me if I’m wrong. From year or two old discussions I had a
feeling it was planned to have both static and dynamic version of KMDF.
What I see here resembles MFC DLL hell. Is there a possinility to use
KMDF as a static library to make things simpler?

Best regards,

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

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, May 18, 2006 11:44 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What did setupact.log say exactly? Can you send out the contents? In
the process of the install, did you touch wdfcoinstaller01000.dll (e.g.
did you delete it?). Our test team ran the following scenario and it
worked just fine

  1. install a driver using KMDF 1.0
  2. recompile the driver for v1.1 and then update the installed
    devnode.

If this is the only KMDF driver loaded, then this works w/out a
reboot. If there are other KMDF drivers loaded, we cannot unload v1.0
of KMDF and require a reboot to get it loaded.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 2:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Install issue with KMDF 1.1

I had an interesting experience. I had delivered a test driver and a
test app based on KMDF 1.0 to another developer. I updated the driver
and in the process updated it to KMDF 1.1. This driver has an install
program that is very similar in nature to devcon.exe. The update of the
driver failed and the error in setupact.log implied that I was using the
checked version of the coinstaller on a free system or vice versa. I
double-checked the DLL and it was indeed the correct version. I
instructed the other developer to remove the old wdf*.sys files and try
it again. Same error. He removed the device in device manger, removed
the INF and PNF files, and rebooted. It then installed correctly. I
assume that there must have been a step that I missed in my install
program. Any idea what it was? Unless I missed something really obvious,
I can see this becoming a problem in the field once more WDF drivers get
released and new KMDF releases start appearing with them.

Beverly

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

It’s going to take a while to duplicate because I have to rebuild and I don’t have KMDF1.0 installed anymore. Thie is why I would much prefer a side-by side install for even a minor revision change.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 6:18 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

There were no other KMDF drivers on the system - just the two that get installed from the same INF (one is a filter driver for the other). The existing coinstaller DLL (version 1.0) did not get touched.

Before the setup program does an update, it removes the old device nodes and finds and removes old INF and PNF files as well. It then tells the system to do a rescan. It does this so that it closely resembles a clean system when the driver gets re-installed. In the past, this has worked out best for test environments to avoid cluttering up the system with old INF and PNF files and sometimes getting the old driver re-installed inadvertently because of those files being present on the system. One thing that this setup program didn’t do, that I had done in the past was delete the old services after removing the device nodes. I’m thinking now that might be the step that I missed. Hmmm, if that’s the step that I missed, maybe I have a leak in the driver unload that was keeping the old WDF from getting unloaded completely therefore preventing a new one from getting installed for it. If that was the case, though, wouldn’t the WDF verifier report a leak?

I’ll try to reproduce it and see what triggered the problem.

In the meantime, this is a direct copy of the text from setupact.log:

WdfCoInstaller: [05/18/2006 11:03.02.625] DIF_INSTALLDEVICE: Pre-Processing

WdfCoInstaller: [05/18/2006 11:03.02.625] ReadComponents: WdfSection for Driver Service mc_tfilt using KMDF lib version Major 0x1, minor 0x1

WdfCoInstaller: [05/18/2006 11:03.02.625] ReadComponents: WdfSection for Driver Service mc_tdev using KMDF lib version Major 0x1, minor 0x1

WdfCoInstaller: [05/18/2006 11:03.02.703] VerifyMSRoot: exit: error(0) The operation completed successfully.

WdfCoInstaller: [05/18/2006 11:03.09.312] Update process returned error code :error(1603) Fatal error during installation.
. Possible causes are running fre version of coinstaller on checked version of OS and vice versa

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, May 18, 2006 5:44 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What did setupact.log say exactly? Can you send out the contents? In the process of the install, did you touch wdfcoinstaller01000.dll (e.g. did you delete it?). Our test team ran the following scenario and it worked just fine

  1. install a driver using KMDF 1.0
  2. recompile the driver for v1.1 and then update the installed devnode.

If this is the only KMDF driver loaded, then this works w/out a reboot. If there are other KMDF drivers loaded, we cannot unload v1.0 of KMDF and require a reboot to get it loaded.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 2:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Install issue with KMDF 1.1

I had an interesting experience. I had delivered a test driver and a test app based on KMDF 1.0 to another developer. I updated the driver and in the process updated it to KMDF 1.1. This driver has an install program that is very similar in nature to devcon.exe.? The update of the driver failed and the error in setupact.log implied that I was using the checked version of the coinstaller on a free system or vice versa. I double-checked the DLL and it was indeed the correct version. I instructed the other developer to remove the old wdf*.sys files and try it again. Same error. He removed the device in device manger, removed the INF and PNF files, and rebooted. It then installed correctly. I assume that there must have been a step that I missed in my install program. Any idea what it was? Unless I missed something really obvious, I can see this becoming a problem in the field once more WDF drivers get released and new KMDF releases start appearing with them.
?
Beverly

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

What do you mean, rebuild? I hope you aren’t doing a full reinstallation
on your target. To restore your test system to a state in which you can
install KMDF 1.0, do the following:

C:\>set devmgr_show_nonpresent_devices=1
C:\>devmgmnt.msc
Uninstall your device(s) from Device Manager.
view -> Show hidden devices
Uninstall wdf01000 (It may prompt for a reboot here, don’t do it.)
C:\>find /i "C:>del %SystemRoot%\inf\oem.* where N is the files found in the
previous step
C:>del %SystemRoot%\System32\drivers\wdf01000.sys
%SystemRoot%\System32\drivers\wdfldr.sys
C:&gt;del %SystemRoot%\System32\drivers<your driver>.sys
C:&gt;sc delete wdf01000
C:&gt;sc delete
(I had to reboot here to make the registry keys really disappear. YMMV)

Install with WdfCoinstaller01000.dll and an inf that references WDF 1.0
exclusively.

I had to do this because we don’t have the Del entry in our inf, but I’m
going to look into that.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 4:41 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

It’s going to take a while to duplicate because I have to rebuild and I
don’t have KMDF1.0 installed anymore. Thie is why I would much prefer a
side-by side install for even a minor revision change.

Beverly

9

I have to rebuild my driver because it is currenlty built with KMDF 1.1
in order to duplicate the problem. In order to rebuild my driver, I need
to uninstlal KMDF 1.1 and reinstall KMDF 1.0 and rebuild the driver.

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@seagate.com
Sent: Thursday, May 18, 2006 7:15 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What do you mean, rebuild? I hope you aren’t doing a full
reinstallation on your target. To restore your test system to a state
in which you can install KMDF 1.0, do the following:

C:\>set devmgr_show_nonpresent_devices=1 C:\>devmgmnt.msc Uninstall your
device(s) from Device Manager.
view -> Show hidden devices
Uninstall wdf01000 (It may prompt for a reboot here, don’t do it.)
C:\>find /i "del
%SystemRoot%\inf\oem.* where N is the files found in the previous
step C:&gt;del %SystemRoot%\System32\drivers\wdf01000.sys
%SystemRoot%\System32\drivers\wdfldr.sys
C:&gt;del %SystemRoot%\System32\drivers<your driver>.sys C:&gt;sc delete
wdf01000 C:&gt;sc delete (I had to reboot here to make the
registry keys really disappear. YMMV)

Install with WdfCoinstaller01000.dll and an inf that references WDF 1.0
exclusively.

I had to do this because we don’t have the Del entry in our inf, but I’m
going to look into that.

Phil

Philip D. Barila
Seagate Technology LLC
(720) 684-1842

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 4:41 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

It’s going to take a while to duplicate because I have to rebuild and I
don’t have KMDF1.0 installed anymore. Thie is why I would much prefer a
side-by side install for even a minor revision change.

Beverly

—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

10

Doron,

I can’t reply just to you, your email doesn’t show up - just the list address. I tried to attach the file but ntdev doesn’t like attachments. Where should I send the file?

I can tell you that I was able to duplicate the problem on my system with no trouble at all. Looking at the WDF log file, it appears that the problem will show up if you install a WDF filter driver and a WDF function driver in the same INF file. The filter driver updates fine, but when the coisntaller tries to update WDF for the function driver it detects that wdf01000.sys was already at 1.1 and so it failed.

Here is the pertinenet line from the WDF log file:

0.047: FileVersion of C:\WINDOWS\system32\DRIVERS\wdf01000.sys is Greater or Equal To 1.1.0.0

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, May 18, 2006 5:57 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

Also, %windir%\Wdf010001inst.log. you can send me that entire file + snippet from setupact.log to my msft email directly, no need to spam everyone with a large email.

d

– I can spell, I just can’t type.

-----Original Message-----
From: Doron Holan
Sent: Thursday, May 18, 2006 2:44 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What did setupact.log say exactly? Can you send out the contents? In the process of the install, did you touch wdfcoinstaller01000.dll (e.g. did you delete it?). Our test team ran the following scenario and it worked just fine

  1. install a driver using KMDF 1.0
  2. recompile the driver for v1.1 and then update the installed devnode.

If this is the only KMDF driver loaded, then this works w/out a reboot. If there are other KMDF drivers loaded, we cannot unload v1.0 of KMDF and require a reboot to get it loaded.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 2:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Install issue with KMDF 1.1

I had an interesting experience. I had delivered a test driver and a test app based on KMDF 1.0 to another developer. I updated the driver and in the process updated it to KMDF 1.1. This driver has an install program that is very similar in nature to devcon.exe.? The update of the driver failed and the error in setupact.log implied that I was using the checked version of the coinstaller on a free system or vice versa. I double-checked the DLL and it was indeed the correct version. I instructed the other developer to remove the old wdf*.sys files and try it again. Same error. He removed the device in device manger, removed the INF and PNF files, and rebooted. It then installed correctly. I assume that there must have been a step that I missed in my install program. Any idea what it was? Unless I missed something really obvious, I can see this becoming a problem in the field once more WDF drivers get released and new KMDF releases start appearing with them.
?
Beverly

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

11

The v1.1. to v1.1 upgrade should be just fine, but I’ll ask our testers to check out that scenario as well. Send me the email at .@microsoft.com.

Thx
d

– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 4:55 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

Doron,

I can’t reply just to you, your email doesn’t show up - just the list address. I tried to attach the file but ntdev doesn’t like attachments. Where should I send the file?

I can tell you that I was able to duplicate the problem on my system with no trouble at all. Looking at the WDF log file, it appears that the problem will show up if you install a WDF filter driver and a WDF function driver in the same INF file. The filter driver updates fine, but when the coisntaller tries to update WDF for the function driver it detects that wdf01000.sys was already at 1.1 and so it failed.

Here is the pertinenet line from the WDF log file:

0.047: FileVersion of C:\WINDOWS\system32\DRIVERS\wdf01000.sys is Greater or Equal To 1.1.0.0

Beverly

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Thursday, May 18, 2006 5:57 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

Also, %windir%\Wdf010001inst.log. you can send me that entire file + snippet from setupact.log to my msft email directly, no need to spam everyone with a large email.

d

– I can spell, I just can’t type.

-----Original Message-----
From: Doron Holan
Sent: Thursday, May 18, 2006 2:44 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What did setupact.log say exactly? Can you send out the contents? In the process of the install, did you touch wdfcoinstaller01000.dll (e.g. did you delete it?). Our test team ran the following scenario and it worked just fine

1) install a driver using KMDF 1.0
2) recompile the driver for v1.1 and then update the installed devnode.

If this is the only KMDF driver loaded, then this works w/out a reboot. If there are other KMDF drivers loaded, we cannot unload v1.0 of KMDF and require a reboot to get it loaded.

d

– I can spell, I just can’t type.
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Brown, Beverly
Sent: Thursday, May 18, 2006 2:27 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Install issue with KMDF 1.1

I had an interesting experience. I had delivered a test driver and a test app based on KMDF 1.0 to another developer. I updated the driver and in the process updated it to KMDF 1.1. This driver has an install program that is very similar in nature to devcon.exe.? The update of the driver failed and the error in setupact.log implied that I was using the checked version of the coinstaller on a free system or vice versa. I double-checked the DLL and it was indeed the correct version. I instructed the other developer to remove the old wdf*.sys files and try it again. Same error. He removed the device in device manger, removed the INF and PNF files, and rebooted. It then installed correctly. I assume that there must have been a step that I missed in my install program. Any idea what it was? Unless I missed something really obvious, I can see this becoming a problem in the field once more WDF drivers get released and new KMDF releases start appearing with them.
?
Beverly

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

12

> KMDF minor versions do not change the contracts so they

are able to overwrite existing previous minor versions.

But Doran,

This is EXACTLY the reason for DLL hell. It’s simply not possible to assure
the contracts will behave the same for all clients. There is almost always a
large amount of “undocumented” behavior, which ends up getting relied on.

My religious belief is that development time sharing of components is a
terrific thing, and run-time binding to some random component version is a
nightmare. A useful nightmare if flexibility is my priority, but if
reliability is my priority, binding together component versions never
tested/designed to work with each other, degrades reliability.

How does that work for WHQL signing? I write a driver that uses KMDF 1.x and
get it signed, and then KMDF is updated to version 1.x+ on a system. In my
book, that means KMDF 1.x+ combined with my driver has NEVER been tested,
and reliability is unknown. To assume my driver works better with KMDF 1.x+
than it did with KMDF 1.x seems like a risky gamble. To me, that means the
WHQL certification has just become invalid.

My driver release schedule is almost certainly not synchronized with every
other IHV, and from what was said here, it will not be possible for driver
A, written, tested, and signed under KMDF 1.x to continue to use KMDF 1.x if
ANY other driver on a system uses KMDF 1.x+. This causes the ugly “I
installed app/device/driver B, and app/device/driver A no longer works
right”. And if I then uninstall driver B, will the KMDF version also get
rolled back to the original version? Or am in the even uglier “I installed
B, and it broke A, and when I uninstalled B, A was still broken, so I had to
format my disk and reinstall everything to get A to work again”.

  • Jan
13

We are aware of the issues. The other alternatives are just as
problematic. Our versioning story went through many rounds of
discussions with many developers/architects various groups around
Windows; it was not something we drew up on the back of a napkin ;). I
understand and appreciate your concerns and thx for the feedback.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, May 18, 2006 10:37 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

KMDF minor versions do not change the contracts so they
are able to overwrite existing previous minor versions.

But Doran,

This is EXACTLY the reason for DLL hell. It’s simply not possible to
assure
the contracts will behave the same for all clients. There is almost
always a
large amount of “undocumented” behavior, which ends up getting relied
on.

My religious belief is that development time sharing of components is a
terrific thing, and run-time binding to some random component version is
a
nightmare. A useful nightmare if flexibility is my priority, but if
reliability is my priority, binding together component versions never
tested/designed to work with each other, degrades reliability.

How does that work for WHQL signing? I write a driver that uses KMDF 1.x
and
get it signed, and then KMDF is updated to version 1.x+ on a system. In
my
book, that means KMDF 1.x+ combined with my driver has NEVER been
tested,
and reliability is unknown. To assume my driver works better with KMDF
1.x+
than it did with KMDF 1.x seems like a risky gamble. To me, that means
the
WHQL certification has just become invalid.

My driver release schedule is almost certainly not synchronized with
every
other IHV, and from what was said here, it will not be possible for
driver
A, written, tested, and signed under KMDF 1.x to continue to use KMDF
1.x if
ANY other driver on a system uses KMDF 1.x+. This causes the ugly “I
installed app/device/driver B, and app/device/driver A no longer works
right”. And if I then uninstall driver B, will the KMDF version also get
rolled back to the original version? Or am in the even uglier “I
installed
B, and it broke A, and when I uninstalled B, A was still broken, so I
had to
format my disk and reinstall everything to get A to work again”.

  • Jan

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

14

What is problematic on static library alternative?

Best regards,

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

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, May 19, 2006 6:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

We are aware of the issues. The other alternatives are just as
problematic. Our versioning story went through many rounds of
discussions with many developers/architects various groups around
Windows; it was not something we drew up on the back of a napkin ;). I
understand and appreciate your concerns and thx for the feedback.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, May 18, 2006 10:37 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

> KMDF minor versions do not change the contracts so they
> are able to overwrite existing previous minor versions.

But Doran,

This is EXACTLY the reason for DLL hell. It’s simply not possible to
assure
the contracts will behave the same for all clients. There is almost
always a
large amount of “undocumented” behavior, which ends up getting relied
on.

My religious belief is that development time sharing of components is a
terrific thing, and run-time binding to some random component version is
a
nightmare. A useful nightmare if flexibility is my priority, but if
reliability is my priority, binding together component versions never
tested/designed to work with each other, degrades reliability.

How does that work for WHQL signing? I write a driver that uses KMDF 1.x
and
get it signed, and then KMDF is updated to version 1.x+ on a system. In
my
book, that means KMDF 1.x+ combined with my driver has NEVER been
tested,
and reliability is unknown. To assume my driver works better with KMDF
1.x+
than it did with KMDF 1.x seems like a risky gamble. To me, that means
the
WHQL certification has just become invalid.

My driver release schedule is almost certainly not synchronized with
every
other IHV, and from what was said here, it will not be possible for
driver
A, written, tested, and signed under KMDF 1.x to continue to use KMDF
1.x if
ANY other driver on a system uses KMDF 1.x+. This causes the ugly “I
installed app/device/driver B, and app/device/driver A no longer works
right”. And if I then uninstall driver B, will the KMDF version also get
rolled back to the original version? Or am in the even uglier “I
installed
B, and it broke A, and when I uninstalled B, A was still broken, so I
had to
format my disk and reinstall everything to get A to work again”.

  • Jan

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

15

MSFT can’t service the KMDF bits via WU if there is a show stopper bug
or other issues that require maintainance.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, May 19, 2006 1:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What is problematic on static library alternative?

Best regards,

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

From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, May 19, 2006 6:47 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

We are aware of the issues. The other alternatives are just as
problematic. Our versioning story went through many rounds of
discussions with many developers/architects various groups around
Windows; it was not something we drew up on the back of a napkin ;).
I understand and appreciate your concerns and thx for the feedback.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
Sent: Thursday, May 18, 2006 10:37 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

> KMDF minor versions do not change the contracts so they are able to
> overwrite existing previous minor versions.

But Doran,

This is EXACTLY the reason for DLL hell. It’s simply not possible to
assure the contracts will behave the same for all clients. There is
almost always a large amount of “undocumented” behavior, which ends up

getting relied on.

My religious belief is that development time sharing of components is
a terrific thing, and run-time binding to some random component
version is a nightmare. A useful nightmare if flexibility is my
priority, but if reliability is my priority, binding together
component versions never tested/designed to work with each other,
degrades reliability.

How does that work for WHQL signing? I write a driver that uses KMDF
1.x and get it signed, and then KMDF is updated to version 1.x+ on a
system. In my book, that means KMDF 1.x+ combined with my driver has
NEVER been tested, and reliability is unknown. To assume my driver
works better with KMDF 1.x+ than it did with KMDF 1.x seems like a
risky gamble. To me, that means the WHQL certification has just become

invalid.

My driver release schedule is almost certainly not synchronized with
every other IHV, and from what was said here, it will not be possible
for driver A, written, tested, and signed under KMDF 1.x to continue
to use KMDF 1.x if ANY other driver on a system uses KMDF 1.x+. This
causes the ugly “I installed app/device/driver B, and
app/device/driver A no longer works right”. And if I then uninstall
driver B, will the KMDF version also get rolled back to the original
version? Or am in the even uglier “I installed B, and it broke A, and
when I uninstalled B, A was still broken, so I had to format my disk
and reinstall everything to get A to work again”.

  • Jan

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

16

So it can’t if there is a bug in WDK headers, libraries and tools causing problem with built drivers. Personally I prefer if my driver is one binary which is thoroughly tested and nobody can alter it. The possibility that the important functionality of my driver is changed via WU is scaring.

One of our big customers forbad us to use WU for our driver. Just for this very reason; they thorougly tested the driver on their notebooks, approved it and didn’t want to have anything changed without their permissions. If I use KMDF for this driver, we couldn’t fulfil this requirement.

Well, yet another reason why not use KMDF. The main one is sources unavailability but this would be probably show stopper, too.

Best regards,

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

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
Reply To: Windows System Software Devs Interest List
Sent: Friday, May 19, 2006 10:16 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

MSFT can’t service the KMDF bits via WU if there is a show stopper bug
or other issues that require maintainance.

d

– I can spell, I just can’t type.

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Friday, May 19, 2006 1:03 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Install issue with KMDF 1.1

What is problematic on static library alternative?

Best regards,

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

> ----------
> From:
xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com
] on behalf of Doron Holan[SMTP:xxxxx@microsoft.com]
> Reply To: Windows System Software Devs Interest List
> Sent: Friday, May 19, 2006 6:47 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Install issue with KMDF 1.1
>
> We are aware of the issues. The other alternatives are just as
> problematic. Our versioning story went through many rounds of
> discussions with many developers/architects various groups around
> Windows; it was not something we drew up on the back of a napkin ;).
> I understand and appreciate your concerns and thx for the feedback.
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Jan Bottorff
> Sent: Thursday, May 18, 2006 10:37 PM
> To: Windows System Software Devs Interest List
> Subject: RE: [ntdev] Install issue with KMDF 1.1
>
> > KMDF minor versions do not change the contracts so they are able to
> > overwrite existing previous minor versions.
>
> But Doran,
>
> This is EXACTLY the reason for DLL hell. It’s simply not possible to
> assure the contracts will behave the same for all clients. There is
> almost always a large amount of “undocumented” behavior, which ends up

> getting relied on.
>
> My religious belief is that development time sharing of components is
> a terrific thing, and run-time binding to some random component
> version is a nightmare. A useful nightmare if flexibility is my
> priority, but if reliability is my priority, binding together
> component versions never tested/designed to work with each other,
> degrades reliability.
>
> How does that work for WHQL signing? I write a driver that uses KMDF
> 1.x and get it signed, and then KMDF is updated to version 1.x+ on a
> system. In my book, that means KMDF 1.x+ combined with my driver has
> NEVER been tested, and reliability is unknown. To assume my driver
> works better with KMDF 1.x+ than it did with KMDF 1.x seems like a >
> risky gamble. To me, that means the WHQL certification has just become

> invalid.
>
> My driver release schedule is almost certainly not synchronized with
> every other IHV, and from what was said here, it will not be possible
> for driver A, written, tested, and signed under KMDF 1.x to continue
> to use KMDF 1.x if ANY other driver on a system uses KMDF 1.x+. This
> causes the ugly “I installed app/device/driver B, and
> app/device/driver A no longer works right”. And if I then uninstall
> driver B, will the KMDF version also get rolled back to the original
> version? Or am in the even uglier “I installed B, and it broke A, and
> when I uninstalled B, A was still broken, so I had to format my disk
> and reinstall everything to get A to work again”.
>
> - Jan
>
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

17

“Michal Vodicka” wrote in message news:xxxxx@ntdev…
> The possibility that the important functionality of my driver is changed via WU is scaring.

Michal, do you realize that Windows is an open system. Every day user adds new software,
that can be very intrusive (like antivirus), and can significantly influence your driver.
So, changes in WDF runtime are just like that, no more, no less.

>One of our big customers forbad us to use WU for our driver. Just for this very reason; they thorougly tested >the driver on
>their notebooks, approved it and didn’t want to have anything changed without their permissions. If I
>use KMDF for this driver, we couldn’t fulfil this requirement.

Most of big organisations that have their own IT departments forbid WU on their
machines. But this does not mean that they never update. Instead, they get all the
same patches that are available from WU, test them, and then use their own
admin tools to push the updates to user machines.
So, after the IT of your “big customer” approves update of WDF runtime, it will meet your driver.

Regards,
–PA

18

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of Pavel A.[SMTP:xxxxx@writeme.com]
Reply To: Windows System Software Devs Interest List
Sent: Saturday, May 20, 2006 2:49 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Install issue with KMDF 1.1

“Michal Vodicka” wrote in message news:xxxxx@ntdev…
> > The possibility that the important functionality of my driver is changed via WU is scaring.
>
> Michal, do you realize that Windows is an open system. Every day user adds new software,
> that can be very intrusive (like antivirus), and can significantly influence your driver.
> So, changes in WDF runtime are just like that, no more, no less.
>
No, it is like if a DLL used by an application is changed. This is what caused DLL hell and MS had to solve it. Now every app can be bound to the exact DLL version (manifests). Why to make the same mistake again?

I understand your point but really feel it is stronger case. Well, we could take KMDF as part of OS which can be updated, too, but KMDF is too “young” and I don’t believe it is so robust or reliable as other parts of the OS. However, if I remember bugs in the USB stack…

> >One of our big customers forbad us to use WU for our driver. Just for this very reason; they thorougly tested >the driver on
> >their notebooks, approved it and didn’t want to have anything changed without their permissions. If I
> >use KMDF for this driver, we couldn’t fulfil this requirement.
>
> Most of big organisations that have their own IT departments forbid WU on their
> machines. But this does not mean that they never update. Instead, they get all the
> same patches that are available from WU, test them, and then use their own
> admin tools to push the updates to user machines.
> So, after the IT of your “big customer” approves update of WDF runtime, it will meet your driver.
>
I wasn’t clear enough. The customer is notebook manufacturer and they’re concerned about stability of preinstalled OS of their notebooks. They can’t influence WU policy, it is on their customers who buy notebooks. If there is a problem, their tech support can instruct notebook owner to refresh preinstalled OS (including our driver) from the image.

Best regards,

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