Launch WDF driver in Windows XP

NTDEV
9

@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?

10

@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)

11

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

12

@“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

13

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.

14

@“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]

15

@“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”

16

@“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.

17

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

18

@“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.

19

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
20

@“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?

21

@“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, a found mistake, can you please check it…

https://pastebin.com/426056wL
This is setup log, and there he copy files to “C:\WINDOWS\system32” dir, but then, later, he tried to add service using another path: “C:\WINDOWS\system32\DRIVERS”.

And in .inf file it is setted here:

; -------------- procmon driver install sections
[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

;
;— procmon_Device Coinstaller installation ------
;

[DestinationDirs]
DefaultDestDir = 11
procmon_Device_CoInstaller_CopyFiles = 11

So, in section “procmon_Service_Inst” setting “ServiceBinary” must be: %11%\procmon.sys.
That is?

22

Yea, i check, now it work.

But can you please explain, why this invalid config was accepted and work on Win7/10?

23

Actually, buridan’s suggestion is wrong. %12% is \windows\system32\drivers. %11% is \windows\system32. So, the RIGHT answer is to change [DestinationDirs] procmon_Device_Coinstaller_CopyFiles to 12, not 11, and leave the ServiceBinary as %12%. Drivers belong in %12%.

24

@Tim_Roberts said:
Actually, buridan’s suggestion is wrong. %12% is \windows\system32\drivers. %11% is \windows\system32. So, the RIGHT answer is to change [DestinationDirs] procmon_Device_Coinstaller_CopyFiles to 12, not 11, and leave the ServiceBinary as %12%. Drivers belong in %12%.

It’s like unspoken rule, that drivers must be in %12%, so, for what uses %11% regarding the .inf driver files?

25

Kernel modules go into %12%. Many driver packages also have to install user-mode co-installers, DLLs, or other support files into %11%.

Plus, going back in history, the 16-bit systems (Win95, WIn98, WinME) didn’t understand the %12% mapping. One had to use %11%\Drivers for cross-platform driver packages.

1 Like
26

INFs can be used outside of driver installs. They existed well before the driver install engine started using them. %11% was a valid target back in the Win9x days before we knew any better.

27

Ah, good old DirID 11. I mean, who wouldn’t immediately understand what THAT is?!?

The whole idea of DirIDs is really funny these days. You know, they start at 01 and they’re a sparse namespace though 32767… and there’s a “-1” that’s a “special secret reserved” dirID (it’s not REALLY secret… it just means “this is a literal path” – The whole topic of DirIDs always makes me laugh, it’s so ancient and historic, yet we live with it today.

Peter

28

If we started over with current best practices, INFs would look and behave quite differently :slight_smile: