I’m new to drivers in general. I’ve been able to build and install a wdm driver. Trying to do the same with a wdf driver. Downloaded an example driver from the CodeProject site for a “basic” driver for KMDF1.0.
http://www.codeproject.com/system/wdf_kmdf_basic.asp
I have only installed KMDF1.1(not 1.0 as well). I have been able to compile the driver properly via the Windows server 2003 x86 checked build. I modified the inf file in this way to reflect version 1.1:
WdfCoinstaller01000.dll=1
to
WdfCoinstaller01001.dll=1
in the 3 places I found it
I added my device to the “Device List” by cutting the info out of my wdm driver(which works).
Not sure if I need to change this value. I don’t know what it is.
[CoInstaller_AddReg]
HKR,CoInstallers32,“”“”“”“”““0x00010000"””“”“”“”"
I also replaced the GUID with the one from my wdm driver. I changed it in the driver and inf. I tried not changing it as well. I have the ddk and kmdf installed on my target system (for the dll). Not quite sure where I should put the WdfCoinstaller01001.dll.???
After all this I bring up the hardware manager and try to install the driver for my device(a PLX bridge chip). It has a hard time finding the driver and dll but I point it in the right direction. But I can’t even get to a BSOD(not that I want to). The Device Manager return this error: There was a problem installing the hardware
Basic WDF device
An error occurred during the installation of the device.
Fatal error during installation.
The driver doesn’t do anythng so I don’t think it is the driver. Am I missing something? My target system is running XP(I’ve tried 2000 too with the sam result). Or maybe is there a better sample out there? What causes this error? Is it the inf, driver, or system setup?
I tried this site already:
http://www.microsoft.com/whdc/driver/tips/KMDF_install.mspx
Steps 1 and 2 were ok.
Step 3 shouldn’t be a problem. I did change the “KmdfLibraryVersion = 1.1”(from 1.0 to 1.1). Same problem I had before I changed this version.
As far as step 4 is concerned:
I can’t find a wdf01001inst.log on my system
Most l;ikely it is your INF.
The first place to begin in looking for answers or insights with device installation problems is setupapi.log (pre-Vista) or setupapi.dev.log (post-Vista). It will give more detailed information on the installation failure. Where to find it and how to work with it is described in the DDK documentation.
You should also read the KMDF Documentation on what you need in an INF for installing a KMDF Driver. Among other things, it sounds like you didn’t update the entries for the KMDF library version for your driver. Nor does it sound like you updated the Coinstallers key to reflect the different coinstaller.
All of the formats for standard INF sections like AddReg are described in the DDK documentation.
One more update. I did find the wdf01001inst.log file. I was looking on the wrong partion. I don’t understand this file though.
The wdf01001inst.log file looks like this:
0.016: 2006/10/20 11:58:20.468 (local)
0.016: d:\82aa515ccde285395869ce\update\update.exe (version 6.2.29.0)
0.016: Hotfix started with following command line: /quiet
0.032: CheckSystem: GetCheckedFree failed :STATUS_CHECKED_FREE_MISMATCH
0.032: DoInstallation: CheckSystem Failed: 0xf002
0.032: Wdf01001 Setup cannot update a checked (debug) system with a free (retail) version of Wdf01001, or vice versa.
0.032: Update.exe extended error code = 0xf002
0.032: Update.exe return code was masked to 0x643 for MSI custom action compliance.
But I have tried deleting the dll from the system32 folder and it gives the same error. I even tried using a free build of the driver and it still complains the same way.
If this is still the case, you can certainly post what you can’t understand here.
Or (as I attempted via your email) you can send it to my email and I’m sure I can help resolve your issue. While I’m (definitely) not Doron, I am a part of the team.
The coinstaller comes in checked and free versions for each architecture. These have to match the build on which you are installing your driver.
This has nothing to do with which version of your driver you are using.
If you are on a checked build use the chk from the redist directory. Otherwise use the fre one.
xxxxx@yahoo.com wrote:
The wdf01001inst.log file looks like this:
0.016: 2006/10/20 11:58:20.468 (local)
0.016: d:\82aa515ccde285395869ce\update\update.exe (version 6.2.29.0)
0.016: Hotfix started with following command line: /quiet
0.032: CheckSystem: GetCheckedFree failed :STATUS_CHECKED_FREE_MISMATCH
0.032: DoInstallation: CheckSystem Failed: 0xf002
0.032: Wdf01001 Setup cannot update a checked (debug) system with a free (retail) version of Wdf01001, or vice versa.
0.032: Update.exe extended error code = 0xf002
0.032: Update.exe return code was masked to 0x643 for MSI custom action compliance.
But I have tried deleting the dll from the system32 folder and it gives the same error. I even tried using a free build of the driver and it still complains the same way.
Is the error correct? Are you running a checked build of the operating
system with a free version of wdf01001.dll, or a free build of the
operating system with a checked version of wdf01001.dll? That’s not
allowed. I’m not clear on why, but it’s not allowed.
Note that this is not talking about your driver at all. This is
strictly about the operating system and the coinstaller.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
>>Are you running a checked build of the operating
system with a free version of wdf01001.dll, or a free build of the
operating system with a checked version of wdf01001.dll? That’s not
allowed. I’m not clear on why, but it’s not allowed.<<
I’d like to try to clarify this point. You can’t INSTALL mismatched versions. Once they are installed, you could get the binaries from a machine of the opposite flavor, copy them over, and use them without any problems.
As for why, the simplest answer is it’s a restriction imposed by the need to use Windows Update as a mechanism for fixing critical framework issues.
>> Once they are installed, you could get the binaries from a machine of the opposite flavor, copy them over, and use them without any problems.<<
Specifically you can copy the .sys files in this way. Don’t try to swap coinstallers.
I have been trying all sorts of combinations here. My main focus has been on .sys and coinstallers of the same type. I just got deperate and have been trying all sorts of wacky stuff. Still with no sucess. So the problem is definetly a build versus coinstaller issue? I shouldn’t be looking anywhere else?
I have even gone so far as too destroy the extension on all of my coinstaller dlls except the one I want to use. Just to ensure the wrong one does not get loaded.
I seem to have it past that error. Thanks for the help. Not quite sure what did it though. I may have overlooked the solution because I was still getting a similar error and didn’t bother to read it. This time it says the driver may be corrupted or missing. (Code 39)
The log file has no information. Sounds like it is a bad driver. Do you know of any very simple sample drivers that I can use on an arbitray device for KMDF?
Not build [of your driver]. The *OS* on the target machine and the coinstaller used to install KMDF on that machine have to match. If they do, then I will work with you to resolve the issue.
What do you mean by “The *OS* on the target machine and the coinstaller used to install KMDF on that machine have to match”? I understand what the OS on the target machine means. Not sure what you mean by “the coinstaller used to install KMDF”. And how do you match them?
Under winddk\wdf\kmdf10\residt\wdf there are 6 directories, each with a coinstaller:
If you are installing on an IA64 machine with a retail OS, use the one in the ia64fre directory.
If you are installing on an IA64 machine with a checked OS, use the one in the ia64chk directory.
If you are installing on an AMD64/Intel em64T machine with a retail 64 bit OS, use the one in the amd64fre directory.
If you are installing on an AMD64/Intel em64T machine with a checked 64 bit OS, use the one in the amd64chk directory.
If you are installing on an AMD64 or Intel (anything not IA64) machine with a retail 32 bit OS, use the one in the x86fre directory.
If you are installing on an AMD64 or Intel (anything not IA64) machine with a checked 32 bit OS, use the one in the x86chk directory.
That naming convention for binaries is used throughout the DDK, FWTW.
>>Do you know of any very simple sample drivers that I can use on an arbitrary device for KMDF?<<
The toaster sample drivers in the KMDF kit are software only, so you don’t need any device. IF you want a driver to work with your device. Though, this probably isn’t the best place to start.
>This time it says the driver may be corrupted or missing. (Code 39)<<
SetupApi.log contains information useful for most installation issues (for sanity checks if nothing else). It can help avoid jumping to conclusions about what is wrong, then going off and utterly trashing things based upon erroneous conclusions.
>Sounds like it is a bad driver.<<
If you have a kernel debugger attached and proper symbols, then there are quite a few other things you can do before jumping to conclusions like this. I was going to list them, but since that could be construed as my jumping to conclusions about your own knowledge and skill level, and probably insulting you in the process, I haven’t.
Yes that was a typo (or dyslexia, if you prefer): winddk\wdf\kmdf10\redist\wdf. And to be ever more precise, the naming convention is for paths to binaries, and not the binaries themselves.
-----Original Message-----
Under winddk\wdf\kmdf10\residt\wdf there are 6 directories, each with a coinstaller:
If you are installing on an IA64 machine with a retail OS, use the one in the ia64fre directory.
If you are installing on an IA64 machine with a checked OS, use the one in the ia64chk directory.
If you are installing on an AMD64/Intel em64T machine with a retail 64 bit OS, use the one in the amd64fre directory.
If you are installing on an AMD64/Intel em64T machine with a checked 64 bit OS, use the one in the amd64chk directory.
If you are installing on an AMD64 or Intel (anything not IA64) machine with a retail 32 bit OS, use the one in the x86fre directory.
If you are installing on an AMD64 or Intel (anything not IA64) machine with a checked 32 bit OS, use the one in the x86chk directory.
That naming convention for binaries is used throughout the DDK, FWTW.
In that case I was going about everything correctly but I still get the failure to install error and the log file describing a checked/free mismatch.
My set up is this:
Target:
Processor:AMD64
OS:Windows XP(32 bit version)
WdfCoinstaller01000.dll from the x86 checked build is being loaded
Host:
Intel Pentium(32 bit)
OS: Windows 2000(must be 32 bit)
Build driver using Windows DDK 3790.1830
Build environment: Windows Server 2003 x86 checked
I still get the error you saw (Failure to load) with the wdf01001inst.log file reporting the checked/free mismatched error.
Mistakenly, I had tried the AMD64 checked build and that is when I saw the corrupt driver Code 39 error. But since you described the OS/coinstaller scenario above I changed it back to the way I was originally building the driver.
The setupapi.log does not change unless I use the wrong build(the 64 bit build).
The wdf01001inst.log updates only when I use the correct 32 bit build and always reports the same free/checked mismatch error.
And I would never feel insulted when asking someone for help. I am very green. I have windbg on the host.
Windbdg reports:
WdfCoInstaller: [10/20/2006 15:15.49.750] DIF_INSTALLINTERFACES
WdfCoInstaller: [10/20/2006 15:15.49.812] Path to INF files: d:\windows\inf\
WdfCoInstaller: [10/20/2006 15:15.49.828] ReadWdfSection: Checking WdfSection [DriverInstall.NTx86.Wdf]
WdfCoInstaller: [10/20/2006 15:15.49.843] Extracting WDFCAB_RESOURCE from WdfCoinstaller01001.dll to D:\WINDOWS\Temp\WdfTemp\WDF.cab
WdfCoInstaller: [10/20/2006 15:15.49.937] file: D:\WINDOWS\Temp\WdfTemp\WDF.cab, time-stamp: [10/20/2006 22:15.49.906], size: 1402926 bytes
WdfCoInstaller: [10/20/2006 15:15.49.953] Check D:\WINDOWS\Temp\WdfTemp\WDF.cab for trusted signature
WdfCoInstaller: [10/20/2006 15:15.49.984] CheckWinTrust(D:\WINDOWS\Temp\WdfTemp\WDF.cab) returns S_OK
WdfCoInstaller: [10/20/2006 15:15.50.000] VerifyFileTrust: exit: D:\WINDOWS\Temp\WdfTemp\WDF.cab, error(0) The operation completed successfully.
WdfCoInstaller: [10/20/2006 15:15.50.046] D:\WINDOWS\Temp\WdfTemp\WDF.cab has been extracted to D:\WINDOWS\Temp\WdfTemp
WdfCoInstaller: [10/20/2006 15:15.50.062] component [0] : D:\WINDOWS\Temp\WdfTemp\wdf01000.inf
WdfCoInstaller: [10/20/2006 15:15.51.765] Final status: error(1603) Fatal error during installation.
WdfCoInstaller: [10/20/2006 15:15.55.125] DIF_DESTROYPRIVATEDATA
And I don’t see anything helpful here but I also don’t know all the details.