We have a kmdf driver that is a software only driver. It has no physical
hardware devices… When I run the following devcon command, the driver
installs without any issues and works with our test program. Since we are
getting close to release, I need to use DPInst to install the driver.
When I try to run it with the following command, DPInst completes and the
Wizard reports “Ready to Use”, but when I look in Device Manager, our
driver is not there. So, I ran DPInst with logging, and have the following
information. Can you please help me figure out how to get DPInst working
with our kmdf software only driver?
Thank you for your help,
Mike
SET HARDWARE_ID={0A8A3A3B-138C-4ABD-BD2E-9CE520472664}\xXXXDriver
set DEPLOYMENT_ROOT=%PROJECT_ROOT%\DEPLOYMENT\DRIVERS\X64
.
.
.
// The following command works and the driver is installed and working.
devcon.exe install %DEPLOYMENT_ROOT%%TARGET_NAME%.inf %HARDWARE_ID%
// This command reports “Ready to Use”, but the driver is not available.
DPInst.exe /PATH %DEPLOYMENT_ROOT% /C
*******************************************************************************
Installing the driver
*******************************************************************************
INFO: Option set: dumping log info to console.
INFO: Current working directory: 'C:\PROJECTS\XXXXDriver\DEPLOYMENT\DPInst\x64
’
INFO: Running on path ‘C:\PROJECTS\XXXXDriver\DEPLOYMENT\DRIVERS\X64’
INFO: No valid ‘dpinst.xml’ file provided.
INFO: Install option set: Force install if driver is not better.
INFO: Found driver package: ‘C:\PROJECTS\XXXXDriver\DEPLOYMENT\DRIVERS\X64\xxx
xdriver.inf’.
INFO: Preinstalling ‘c:\projects\XXXXDriver\deployment\drivers\x64\XXXXDriver.
inf’ …
INFO: ENTER: DriverPackagePreinstallW
SUCCESS:c:\projects\XXXXDriver\deployment\drivers\x64\XXXXDriver.inf is preinsta
lled.
INFO: RETURN: DriverPackagePreinstallW (0x0)
INFO: ENTER: DriverPackageGetPathW
INFO: RETURN: DriverPackageGetPathW (0x0)
INFO: ENTER: DriverPackageInstallW
INFO: Installing INF file ‘c:\projects\XXXXDriver\deployment\drivers\x64\xxxxd
river.inf’ (Plug and Play).
INFO: Looking for Model Section [XXXXDriver_Model.NTamd64]…
INFO: No matching devices found in INF “C:\Windows\System32\DriverStore\FileRe
pository\XXXXDriver.inf_de9bc832\XXXXDriver.inf” on the Machine.
INFO: No drivers installed. No devices found that match driver(s) contained in
‘C:\Windows\System32\DriverStore\FileRepository\XXXXDriver.inf_de9bc832\xxxxdri
ver.inf’.
INFO: RETURN: DriverPackageInstallW (0xE000020B)
INFO: No matching device was found for ‘c:\projects\XXXXDriver\deployment\driv
ers\x64\XXXXDriver.inf’. Driver will be installed when plugged in.
INFO: Created entry in Add or Remove Programs for ‘C:\Windows\System32\DriverS
tore\FileRepository\XXXXDriver.inf_de9bc832\XXXXDriver.inf’.
INFO: Returning with code 0x100
So, I have been doing more reading and discovered that, DPInst is completing its work properly. It is Pre-installing our driver, and the system is waiting for some device to ask for it to be loaded. It is interesting that none of the books or online materials that I’ve read about creating a software only driver in KMDF mentioned this deployment issue. Most likely because everything works fine with devcon, which is a developer’s tool; Whereas, MS doesn’t want devcon used for deployments, so here I am with my question.
So… It seems that our deployment plan for the installer would be…
DPInst (silently) our software only driver;
Run a tiny application that creates our PnP device node;
Do you know of any sample code in the WinDDK that I can review that shows how to create a Pnp device node?
Since we have no PnP devices to manage and no power management, is it possible to convert our KMDF software only driver to be non-PnP? Would this permit us to simply install our driver and call it from our user mode application without having to create a device node separately? Would this violate what is considered best practices?
If it is a pure software-only, kernel service (and specifically that means it’s NOT A FILTER DRIVER) – such as something that gathers data in kernel mode and sends it back to user mode – then best practice would be to write a Legacy NT V4 style software only driver.
Thanks, David, for the nudge in the correct direction… I found the source code for devcon in the WinDDK distribution at C:\WinDDK\7600.16385.1\src\setup\devcon. I am going to look at how it creates a device node so we can implement it in our installation.
Thanks, Peter, for the great reference! I had scoured the Internet looking for a comparison like the one that you’ve mentioned, but didn’t find anything! Based on what I’ve ready, our software only driver is a great candidate for becoming a legacy driver. We will never need to deal with power or PnP management. Although we are close to release, I would like to see how difficult it will be to shift to a legacy driver. 98% of the driver code is simply handling IO CTL commands, so I think that it would be easy to shift to a legacy driver. I will post more after I investigate this question…
Thanks, again, guys! It looks like I am going to have a busy Sunday afternoon!
So, I’ve looked at the Sioctl example in the WinDDK and found that it would be trivial to move our application specific code to a WDM software only driver from a KMDF one. I built a simple version and it worked properly and was easy to access from our user mode application. I also found in the Sioctl project, a file, “install.c”, that provided example code for loading the driver, which I would incorporate into a tiny application that would run during application installation.
So… The $10 question is should we move to WDM from KMDF. I realize that this is a personal decision, but based on what I have read and the following:
We have no physical device to control;
We don’t need Pnp;
We don’t need power management;
WDM is not considered a depreciated environment by Microsoft;
So… After taking a break and eating… I realized that I cannot completely move our application to WDM because we are using WDF objects! I did a little more searching and found the following KMDF project:
nonpnp
That describes how to configure a software only KMDF driver. It also includes a file that shows how to load the driver via service control. All in all… It looks like we are good to go!
…OK… I didn’t understand any part of your last post. But given that it ends “we are good to go!” I’ll assume it doesn’t matter and wish you the best of luck!