Launch WDF driver in Windows XP

I have a KMDF driver, that work on Windows7/10. Now I tried to build driver for Windows XP(x64) and used for it WinDDK7600. So I compile sys file, generate test sign and sign him.
On the test machine I ve try to load hiw with sc, OSRLoader, KMDManager, and I always get error: The system cannot find the file specified.
P.s. if i compile old version of driver, that doesn’t use WDF it will be loaded.

I take dlls from redist dir if WinDDK7600, there was WdfCoInstaller*.dlls, and place them to %system32% dir, but it doesn’t help me. After I watch WdfDriver in drivers dir, and doesn’t find them.
I don’t understand where can I find WDF redist files for WinXP and install them…

P.s. i set KMDF_VERSION in source file to 1.9, on MDSN saied this is the version, which support Windows XP

Your INF needs to point to the co-installers so that the system calls the co-installers on your behalf. Just having them present isn’t enough. You have to add the co-installer to your driver package, and point to it in your INF. Remember that XP (and Vista) knew NOTHING about KMDF. As far as it’s concerned, KMDF is just part of your driver. Here’s the instructions on how to add the xxx.NT.CoInstallers section to your INF. Your driver package will still work on the newer systems.

https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/installing-the-framework-s-co-installer

@Tim_Roberts said:
Your INF needs to point to the co-installers so that the system calls the co-installers on your behalf. Just having them present isn’t enough. You have to add the co-installer to your driver package, and point to it in your INF. Remember that XP (and Vista) knew NOTHING about KMDF. As far as it’s concerned, KMDF is just part of your driver. Here’s the instructions on how to add the xxx.NT.CoInstallers section to your INF. Your driver package will still work on the newer systems.

https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/installing-the-framework-s-co-installer

vista had framework preinstalled https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/kmdf-version-history

@Tim_Roberts said:
Your INF needs to point to the co-installers so that the system calls the co-installers on your behalf. Just having them present isn’t enough. You have to add the co-installer to your driver package, and point to it in your INF. Remember that XP (and Vista) knew NOTHING about KMDF. As far as it’s concerned, KMDF is just part of your driver. Here’s the instructions on how to add the xxx.NT.CoInstallers section to your INF. Your driver package will still work on the newer systems.

https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/installing-the-framework-s-co-installer

How does installer know, where to find WdfCoInstaller(ver).dll, it must be placed near sys/inf file, in the same dir?

It is part of your driver package. The INF file tells the system where to find all of the files. Usually, yes, they are in the same directory as the SYS file. Remember that you have to use the co-installer that matches your driver, which for XP means you have to grab the 32-bit co-installer.

@buridan said:

@Tim_Roberts said:
Your INF needs to point to the co-installers so that the system calls the co-installers on your behalf. Just having them present isn’t enough. You have to add the co-installer to your driver package, and point to it in your INF. Remember that XP (and Vista) knew NOTHING about KMDF. As far as it’s concerned, KMDF is just part of your driver. Here’s the instructions on how to add the xxx.NT.CoInstallers section to your INF. Your driver package will still work on the newer systems.

https://docs.microsoft.com/en-us/windows-hardware/drivers/wdf/installing-the-framework-s-co-installer

How does installer know, where to find WdfCoInstaller(ver).dll, it must be placed near sys/inf file, in the same dir?

If I test driver on Windows XP x64, so CoInstaller must be 64, or on WinXP the CoInstaller must be 32bit for both editions of OS(x64/x32)?

So, finaly for generate ready package i need:

  1. Create .inf file, with setted CoInstaller

  2. Sign driver.sys

  3. Generate .cat file for:

    • driver.sys
    • driver.inf
    • WdfCoInstaller(VER).dll

Is that right?

I said the co-installer has to match your driver. I assumed you weren’t targeting XP64; it was a strange beast that didn’t get much love. It was really Windows Server 2003 with the branding changed.

Signing is only required for the 64-bit systems. You’ll need to sign and cross-sign either the SYS or the CAT.

1 Like

@Tim_Roberts said:
I said the co-installer has to match your driver. I assumed you weren’t targeting XP64; it was a strange beast that didn’t get much love. It was really Windows Server 2003 with the branding changed.

Signing is only required for the 64-bit systems. You’ll need to sign and cross-sign either the SYS or the CAT.

Yeaa, I need this beast)) If i enable debug mode on OS, and enable test-sign, I need only my own certificate, right?

@Tim_Roberts said:
I said the co-installer has to match your driver. I assumed you weren’t targeting XP64; it was a strange beast that didn’t get much love. It was really Windows Server 2003 with the branding changed.

Signing is only required for the 64-bit systems. You’ll need to sign and cross-sign either the SYS or the CAT.

Can you please advise material, where can I find all stages need for driver deploy. Because I build it only with VS, and it does a lot of work in the background. But with DDK it doesn’t work, so is there some kind of instruction that I need to with a bare binary file of the driver.

I know that WDF include utilities such as Inf2Cat, stampinf, and others, but I don’t know the full pipeline to proceed ready KMDF driver for WinXP(x32/x64)

There’s a lot to cover here. SO much, I’m not sure we’re going to be able to do it effectively. But let’s try to start:

First, you need to install your driver using an INF. That means you would not use OSRLOADER. That’s used for NON-PnP legacy type drivers only.

Second, if you’re not using the WDK integrated with Visual Studio, stop what you’re doing and do that now. This will eliminate all those questions you have about checkinf and stampinf and all that other stuff that you don’t care about right now.

Third, your INF needs to include the co-installer “stuff” as Mr. Roberts said. Read the docs to which he linked. There’s a section at the bottom of the doc page that shows how to add the necessary co-installer “stuff” – You need ALL OF IT not just putting the Co-Installer in copy files.

Forth, if you have the kernel-mode debugger hooked-up to your test system and enabled, you don’t need to sign the driver at all. But if you disconnect the debugger, your driver will not load. This requires that you have debugging enabled on the test system… which you presumably do. If not, stop now and get that working.

Fifth, copy your entire driver package… this includes your driver binary, your INF, and the appropriate co-installer DLL to a dedicated directory on the target system. You can install your driver using Device Manager or using DevCon. If you want to use DevCon, copy it from the WDK (it’s in <WDK_DIR>\10\Tools\x64\devcon.txt). If you use DevCon to install your driver, you’ll need to use the devcon update command. Note carefully what I just wrote. As much as it’s intuitive that it should be, the command is not “devcon install”. It’s devcon update. Run this from the dedicated directory in which you’ve located your driver binary, your INF file, and the co-installer DLL. You’ll need the full hardware ID of your device (like, “USB\VID_0547&PID_1002”).

OK? That should give you a few hours of work to do.

Have fun,

Peter

@“Peter_Viscarola_(OSR)” said:
There’s a lot to cover here. SO much, I’m not sure we’re going to be able to do it effectively. But let’s try to start:

First, you need to install your driver using an INF. That means you would not use OSRLOADER. That’s used for NON-PnP legacy type drivers only.

Second, if you’re not using the WDK integrated with Visual Studio, stop what you’re doing and do that now. This will eliminate all those questions you have about checkinf and stampinf and all that other stuff that you don’t care about right now.

Third, your INF needs to include the co-installer “stuff” as Mr. Roberts said. Read the docs to which he linked. There’s a section at the bottom of the doc page that shows how to add the necessary co-installer “stuff” – You need ALL OF IT not just putting the Co-Installer in copy files.

Forth, if you have the kernel-mode debugger hooked-up to your test system and enabled, you don’t need to sign the driver at all. But if you disconnect the debugger, your driver will not load. This requires that you have debugging enabled on the test system… which you presumably do. If not, stop now and get that working.

Fifth, copy your entire driver package… this includes your driver binary, your INF, and the appropriate co-installer DLL to a dedicated directory on the target system. You can install your driver using Device Manager or using DevCon. If you want to use DevCon, copy it from the WDK (it’s in <WDK_DIR>\10\Tools\x64\devcon.txt). If you use DevCon to install your driver, you’ll need to use the devcon update command. Note carefully what I just wrote. As much as it’s intuitive that it should be, the command is not “devcon install”. It’s devcon update. Run this from the dedicated directory in which you’ve located your driver binary, your INF file, and the co-installer DLL. You’ll need the full hardware ID of your device (like, “USB\VID_0547&PID_1002”).

OK? That should give you a few hours of work to do.

Have fun,

Peter

  1. This is my inf file from VS generated proj:
    [Pastebin]

  2. You said using WDK without integration with VS bad solution, but… how cant I set Windows XP platform in VS, the minimal of platform I have is Windows 7.
    If I set the platform to it and set KMDF version to 1.9, does it will work for WinXP?
    Does it work in VS2017 or 2019? I try to change this setting, but… after that VS can’t show project setting, it breaked, so… Do I need to install some of the older versions of VS?
    P.s. in the beginning I read this article and thought that is is the way to built driver for winXP…(
    [CodeProject Article]

  3. There set options like in the example, that Mr. Roberts mentioned.

  4. About this… now I have machine with an enabled debugger, but what will I do with it, when I need to run a machine without debugger?
    I have a few machines, and… I don’t want to connect debuggers to all of them when I will use driver for monitoring, not testing, in the future.

  5. Did not try it yet, because I have a question in 2 item…
    P.s. on the Windows 10, we just install driver with .inf file, set service in the registry, and then load him by calling NtLoadDriver function

You’re welcome, by the way.

You said using WDK without integration with VS bad solution, but… how cant I set Windows XP platform in VS

Set it to KMDF V1.9 and target Win7 with the VS build environment. This works. I have built multiple commercially shipping drivers that support XP this way.

in the beginning I read this article and thought that is is the way to built driver for winXP

There is almost nothing on CodeProject about driver development that is worth reading. Mr. van Dooren is, perhaps, an exception to this. But, no matter… the article is outdated.

but what will I do with it, when I need to run a machine without debugger?

How about you walk before you run? Don’t try to solve too many problems at once.

The answer is: For testing without the debugger, you can enable test signing on the platform as described here. When you want to run your driver “for real” you’ll need to sign it with a real Class 3 Code Signing Certificate, and cross sign it with the right certificate chain. But don’t worry about that now. Get the driver working on a machine with the debugger first.

on the Windows 10, we just install driver with .inf file, set service in the registry, and then load him by calling NtLoadDriver function

Huh?? There is no difference – none, zero – between how you install a driver for debugging on Win10 and how you install that same driver on Win XP. Well, the UI looks a little different, but… whatever. I have no idea what the above sentence that you wrote means.

Peter

ETA: Clarify my install statement about Win10 vs XP relates to debugging… not a general statement on how production drivers are installed… though it’s still the same… just the required signing is different.

@“Peter_Viscarola_(OSR)” said:
You’re welcome, by the way.

You said using WDK without integration with VS bad solution, but… how cant I set Windows XP platform in VS

Set it to KMDF V1.9 and target Win7 with the VS build environment. This works. I have built multiple commercially shipping drivers that support XP this way.

in the beginning I read this article and thought that is is the way to built driver for winXP

There is almost nothing on CodeProject about driver development that is worth reading. Mr. van Dooren is, perhaps, an exception to this. But, no matter… the article is outdated.

but what will I do with it, when I need to run a machine without debugger?

How about you walk before you run? Don’t try to solve too many problems at once.

The answer is: For testing without the debugger, you can enable test signing on the platform as described here. When you want to run your driver “for real” you’ll need to sign it with a real Class 3 Code Signing Certificate, and cross sign it with the right certificate chain. But don’t worry about that now. Get the driver working on a machine with the debugger first.

on the Windows 10, we just install driver with .inf file, set service in the registry, and then load him by calling NtLoadDriver function

Huh?? There is no difference – none, zero – between how you install a driver for debugging on Win10 and how you install that same driver on Win XP. Well, the UI looks a little different, but… whatever. I have no idea what the above sentence that you wrote means.

Peter

ETA: Clarify my install statement about Win10 vs XP relates to debugging… not a general statement on how production drivers are installed… though it’s still the same… just the required signing is different.

I 've tried to setup on WinXP driver, that I built in VS, with setting KMDF version to 1.9, platform Windows7, but it’s failed. I used devcon for it.
Main error from log is: Default installer failed. Error 0xe0000228: There are no compatible drivers for this device.
Here setupapi.log from machine: [pastebin]

@“Peter_Viscarola_(OSR)” said:
You’re welcome, by the way.

You said using WDK without integration with VS bad solution, but… how cant I set Windows XP platform in VS

Set it to KMDF V1.9 and target Win7 with the VS build environment. This works. I have built multiple commercially shipping drivers that support XP this way.

in the beginning I read this article and thought that is is the way to built driver for winXP

There is almost nothing on CodeProject about driver development that is worth reading. Mr. van Dooren is, perhaps, an exception to this. But, no matter… the article is outdated.

but what will I do with it, when I need to run a machine without debugger?

How about you walk before you run? Don’t try to solve too many problems at once.

The answer is: For testing without the debugger, you can enable test signing on the platform as described here. When you want to run your driver “for real” you’ll need to sign it with a real Class 3 Code Signing Certificate, and cross sign it with the right certificate chain. But don’t worry about that now. Get the driver working on a machine with the debugger first.

on the Windows 10, we just install driver with .inf file, set service in the registry, and then load him by calling NtLoadDriver function

Huh?? There is no difference – none, zero – between how you install a driver for debugging on Win10 and how you install that same driver on Win XP. Well, the UI looks a little different, but… whatever. I have no idea what the above sentence that you wrote means.

Peter

ETA: Clarify my install statement about Win10 vs XP relates to debugging… not a general statement on how production drivers are installed… though it’s still the same… just the required signing is different.

I’ve built a driver in VS with setted platform to Windows 7, and KMDF version to 1.9. Then I use devcon (update) for setup driver, and it’s failed. The debugger was connected to machine.
Error log(setupapi.log) on [pastebin]
The default installer failed. Error 0xe0000228: There are no compatible drivers for this device.

devcon cmd was: “devcon.exe update .\win7_xp\procmon.sys root\procmon”

@“Peter_Viscarola_(OSR)” said:
You’re welcome, by the way.

You said using WDK without integration with VS bad solution, but… how cant I set Windows XP platform in VS

Set it to KMDF V1.9 and target Win7 with the VS build environment. This works. I have built multiple commercially shipping drivers that support XP this way.

in the beginning I read this article and thought that is is the way to built driver for winXP

There is almost nothing on CodeProject about driver development that is worth reading. Mr. van Dooren is, perhaps, an exception to this. But, no matter… the article is outdated.

but what will I do with it, when I need to run a machine without debugger?

How about you walk before you run? Don’t try to solve too many problems at once.

The answer is: For testing without the debugger, you can enable test signing on the platform as described here. When you want to run your driver “for real” you’ll need to sign it with a real Class 3 Code Signing Certificate, and cross sign it with the right certificate chain. But don’t worry about that now. Get the driver working on a machine with the debugger first.

on the Windows 10, we just install driver with .inf file, set service in the registry, and then load him by calling NtLoadDriver function

Huh?? There is no difference – none, zero – between how you install a driver for debugging on Win10 and how you install that same driver on Win XP. Well, the UI looks a little different, but… whatever. I have no idea what the above sentence that you wrote means.

Peter

ETA: Clarify my install statement about Win10 vs XP relates to debugging… not a general statement on how production drivers are installed… though it’s still the same… just the required signing is different.

I built the driver with VS. Set KMDF version to 1.9, a platform to Windows 7;
On debug machine(with the enabled debugger), I installed a certificate, that was generated by VS, and after that try to install .inf file with devcon, but it’s failed.
Error from a log is: “Default installer failed. Error 0xe0000228: There are no compatible drivers for this device.”
Full log pastebin
In the inf file, WdfCoInstaller01009.dll setted, and I place him nearby the .sys file.

OK… this is NOT a PnP driver? It’s a root-enumerated pseudo device driver?

In THAT case, you DO want “devcon install” not “devcon update”…

You might try reading the docs on this stuff… you know?

Peter

@“Peter_Viscarola_(OSR)” said:
OK… this is NOT a PnP driver? It’s a root-enumerated pseudo device driver?

In THAT case, you DO want “devcon install” not “devcon update”…

You might try reading the docs on this stuff… you know?

Peter

Yea, it’s pseudo device driver, used for getting features available in kernel-space.

I used devcon like in this example: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/using-the-devcon-tool-to-install-a-driver-package

It’s failed. The logfile is the same as I attached in previous messages.

Use devcon like:

Devcon install

So:

devcon.exe install procmon.inf root\procmon

Run this from the directory in which you have copied the INF, co-installer, and sys file… as I said before. Make sure the INF is correct, and that the paths all are correct.

This isn’t rocket science. Spend some time debugging the problem. We’re trying to help, but we can do your work for you.

Peter

1 Like

@“Peter_Viscarola_(OSR)” said:
Use devcon like:

Devcon install

So:

devcon.exe install procmon.inf root\procmon

Run this from the directory in which you have copied the INF, co-installer, and sys file… as I said before. Make sure the INF is correct, and that the paths all are correct.

This isn’t rocket science. Spend some time debugging the problem. We’re trying to help, but we can do your work for you.

Peter

I think i find error< can you please check it?
There is setup log of driver:
https://pastebin.com/426056wL

By the log he copy files in “C:\WINDOWS\system32\procmon.sys”.
Later he try to add service, and path for sys is: “C:\WINDOWS\system32\DRIVERS\procmon.sys”

So… in the inf file:

[procmon_Service_Inst]
DisplayName = %procmon.SVCDESC%
ServiceType = 1 ; SERVICE_KERNEL_DRIVER
StartType = 3 ; SERVICE_DEMAND_START
ErrorControl = 1 ; SERVICE_ERROR_NORMAL
ServiceBinary = %12%\procmon.sys

[DestinationDirs]
DefaultDestDir = 11
procmon_Device_CoInstaller_CopyFiles = 11


I think in section “procmon_Service_Inst”.ServiceBinary must be: “%11%\procmon.sys”

Is that’s right?