Driver does not attach to device and does not log anything

[JohnAZoidberg]

Hi I'm succesfully loading the driver:

PS C:\Users\Daniel\clone\Windows-rust-driver-samples> pnputil.exe /add-driver target\debug\echo_2_package\echo_2.inf /install
Microsoft PnP Utility

Adding driver package:  echo_2.inf
Driver package added successfully.
Published Name:         oem2.inf

Total driver packages:  1
Added driver packages:  1

Then I use devgen to create a device:

PS C:\Users\Daniel\clone\Windows-rust-driver-samples> .\devgen.exe /add /hardwareid "root\ECHO_2"
Microsoft Device Generator

Device successfully created. Device Instance ID: SWD\DEVGEN\{6cbf6930-9e19-ad4d-9ce3-8a8550e7d784}

But I don't see any log messages in DebugView:

And Driver Store Explorer also does not show any device associated with the driver (last column "Device Name"):

Consequently the demo app does not find the driver:

PS C:\Users\Daniel\clone\Windows-rust-driver-samples> cargo run --bin echoapp
   Compiling echoapp v0.1.0 (C:\Users\Daniel\clone\Windows-rust-driver-samples\general\echo\kmdf\exe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.54s
     Running `target\debug\echoapp.exe`
Error: "Error: No active device interfaces found.  Is the sample driver loaded?"
error: process didn't exit successfully: `target\debug\echoapp.exe` (exit code: 1)

Anything I could've done wrong? I did load the certificates into Trusted Root Certification Authorities and Trusted Publishers.
Bitlocker is off, testsigning is on, secureboot is off.

[wmmc88]

Hi Daniel!

Couple questions to help debug this:

• What version of windows(winver) are you using?
• What WDK are you using? (and how did you obtain it i.e. ewdk, wdk installer, winget, nuget etc)
• what commit of the sample are you using?
• Whats the output of pnputil /enum-devices /class Sample /connected
• Do you see any driver installed on the root\ECHO_2 device node? (Note: the Drivers by Type option)
  
• If you see a Sample Device , but a different driver is getting installed(ex. the inbox c_swdevice.inf), its possible that either the certificates were installed improperly (although from you description it seems like thats fine), or maybe there's a mismatch between the os version and what its signed for. The Events tab for the Sample Device Node in Device Manager may have more clues as to what's going on

[JohnAZoidberg]

Thanks so much for your quick response!
I'm excited for this project and to use it :D

• What version of windows(winver) are you using?

Windows 11 Pro 24H2 OS Build 26100.1882

• What WDK are you using? (and how did you obtain it i.e. ewdk, wdk installer, winget, nuget etc)

The EWDK titlebar says: "Enterprise WDK with VS 17.8.6 [34525.116.d17.8]".
I just downloaded it this week, so I think it's the latest one.

I installed Visual Studio and WDK as well before using EWDK, I hope that doesn't conflict.

• what commit of the sample are you using?

8b8847f

• Whats the output of pnputil /enum-devices /class Sample /connected

No devices were found on the system

But that must be because I changed the

• Do you see any driver installed on the root\ECHO_2 device node? (Note: the Drivers by Type option)

• If you see a Sample Device , but a different driver is getting installed(ex. the inbox c_swdevice.inf), its possible that either the certificates were installed improperly (although from you description it seems like thats fine), or maybe there's a mismatch between the os version and what its signed for. The Events tab for the Sample Device Node in Device Manager may have more clues as to what's going on

Itlooks like this. What does that mean?

---

Oh I have to say that I'm not building from the clean commit. I had to make a change to make it build.
I changed the class and I generated a new GUID.

diff --git a/general/echo/kmdf/driver/DriverSync/echo_2.inx b/general/echo/kmdf/driver/DriverSync/echo_2.inx
index 7b9daaa..0890930 100644
--- a/general/echo/kmdf/driver/DriverSync/echo_2.inx
+++ b/general/echo/kmdf/driver/DriverSync/echo_2.inx
@@ -7,8 +7,8 @@

 [Version]
 Signature   = "$WINDOWS NT$"
-Class       = Sample
-ClassGuid   = {78A1C341-4539-11d3-B88D-00C04FAD5171}
+Class       = RustSample
+ClassGuid   = {0de61b41-c8a4-44d5-812a-81e5cb731728}
 Provider    = %ProviderString%
 PnpLockDown = 1

Without this change I see the following error when trying to build:

[cargo-make][1] INFO - Running Task: infverif
[cargo-make][1] INFO - Execute Command: "infverif" "/v" "/w" "/msft" "C:\\Users\\Daniel\\clone\\Windows-rust-driver-samples\\target/debug/echo_2.inf"
Running in Verbose
Running Windows Driver INF check
Running in MSFT driver mode

Validating echo_2.inf
ERROR(1284) in C:\Users\Daniel\clone\Windows-rust-driver-samples\target\debug\echo_2.inf, line 10: Class "Sample" is reserved for use by Microsoft.
ERROR(1285) in C:\Users\Daniel\clone\Windows-rust-driver-samples\target\debug\echo_2.inf, line 28: Cannot specify [ClassInstall32] section for Microsoft-defined class.
INF is NOT VALID

Checked 1 INF(s) in 0 m 0 s 1 ms
Error while executing command, exit code: 1627
[cargo-make] ERROR - Error while running duckscript: Source: Unknown Line: 11 - Error while executing command, exit code: 105
[cargo-make] WARN - Build Failed.

Maybe this is the key issue.

I just found this: #21 (comment)
Trying with the branch from #18 also does not help.
But at least I don't have to modify anything.

[wmmc88]

It's great to hear your enthusiasm :)

From what you've shared, it looks like its an issue with the test device's setup. Your screenshot of device manager shows that the driver is installed, but it isn't on any device nodes.

I'm going to assume you're building from #18 now.

1. To rule out a cert issue, since you're building on the same device you're testing on, can you build the driver with signtool verification enabled: https://github.com/microsoft/windows-drivers-rs?tab=readme-ov-file#driver-package-signature-verification. I don't think its the issue here, but a common problem is people installing the certs in Current User instead of Local Machine.

2. Remove all existing devgen device nodes you created. You can list all the devgen nodes via pnputil /enum-devices /deviceid "root\ECHO_2". AFAIK, these are only supposed to persist until reboot, but you can also manually remove them via devgen.exe /remove <Instance ID>

3. Remove the existing installed echo drivers. The newer compiled drivers should take precedence, but just to make sure there isn't conflicts with the wrong, you should remove the old ones via pnputil /delete-driver oem<XYZ>.inf /uninstall. You can see all the installed drivers via pnputil /enum-drivers

4. Startup debugview so you see logs from driver install after the driver is installed and the devgen devnode is created

5. Install the newly compiled driver via pnputil /add-driver

6. Create a new devgen node via .\devgen.exe /add /hardwareid "root\ECHO_2"

7. You should see some logs now. Also, the output of pnputil /enum-devices /deviceid "root\ECHO_2" should show Started status. The output of pnputil /enum-devices /class Sample /connected should also show the driver and device properly

8. running echoapp.exe should work now. If not, let me know at what step things didn't work out :)

[JohnAZoidberg]

Ok let's start fresh from #18. I remove everything and then rebooted.

PS C:\Users\Daniel> pnputil /enum-devices /deviceid "root\ECHO_2"
Microsoft PnP Utility

No devices were found on the system.
PS C:\Users\Daniel> pnputil /enum-drivers
Microsoft PnP Utility

[Using Terminal search I can't find any echo driver]

Let's clean and build fresh from EWDK:

C:\Users\Daniel\clone\Windows-rust-driver-samples>cargo clean
     Removed 50358 files, 1.6GiB total

C:\Users\Daniel\clone\Windows-rust-driver-samples>cargo make --env WDK_BUILD_ENABLE_SIGNTOOL_VERIFY=true
[...]

During the build it says this, I think this is the certificate verification you're referring to?

[cargo-make][1] INFO - Execute Command: "signtool" "verify" "/v" "/pa" "C:\\Users\\Daniel\\clone\\Windows-rust-driver-samples\\target/debug/fail_driver_pool_leak_package/fail_driver_pool_leak.cat"

Verifying: C:\Users\Daniel\clone\Windows-rust-driver-samples\target/debug/fail_driver_pool_leak_package/fail_driver_pool_leak.cat

Signature Index: 0 (Primary Signature)
Hash of file (sha256): DEE00330175C4CEFE46E38F3D7D1821FC5B9DBC4F3119817CFED148A0F806B53

Signing Certificate Chain:
    Issued to: WDRLocalTestCert
    Issued by: WDRLocalTestCert
    Expires:   Sun Jan 01 07:59:59 2040
    SHA1 hash: 6BCAA321D20AAA828C6CC408730001AADC406AF3

The signature is timestamped: Sun Oct 06 20:07:32 2024
Timestamp Verified by:
    Issued to: DigiCert Assured ID Root CA
    Issued by: DigiCert Assured ID Root CA
    Expires:   Mon Nov 10 08:00:00 2031
    SHA1 hash: 0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43

        Issued to: DigiCert Trusted Root G4
        Issued by: DigiCert Assured ID Root CA
        Expires:   Mon Nov 10 07:59:59 2031
        SHA1 hash: A99D5B79E9F1CDA59CDAB6373169D5353F5874C6

            Issued to: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
            Issued by: DigiCert Trusted Root G4
            Expires:   Mon Mar 23 07:59:59 2037
            SHA1 hash: B6C8AF834D4E53B673C76872AA8C950C7C54DF5F

                Issued to: DigiCert Timestamp 2024
                Issued by: DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA
                Expires:   Mon Nov 26 07:59:59 2035
                SHA1 hash: DBD385EE62DBD23E7BE4F67148508724D5865B45

Successfully verified: C:\Users\Daniel\clone\Windows-rust-driver-samples\target/debug/echo_2_package/echo_2.cat

Number of files successfully Verified: 1
Number of warnings: 0
Number of errors: 0

Install the driver

C:\Users\Daniel\clone\Windows-rust-driver-samples\target\debug\echo_2_package>pnputil.exe /add-driver echo_2.inf /install
Microsoft PnP Utility

Adding driver package:  echo_2.inf
Driver package added successfully.
Published Name:         oem2.inf

Total driver packages:  1
Added driver packages:  1

Checking whether it's installed or not (I cut just the relevant output):

C:\Users\Daniel\clone\Windows-rust-driver-samples\target\debug\echo_2_package> pnputil /enum-drivers
Microsoft PnP Utility

Published Name:     oem2.inf
Original Name:      echo_2.inf
Provider Name:      TODO-Set-Provider
Class Name:         Sample
Class GUID:         {78a1c341-4539-11d3-b88d-00c04fad5171}
Driver Version:     10/06/2024 20.8.48.925
Signer Name:        Unknown

Add device, check if it's present and try to access it.

C:\Users\Daniel\clone\Windows-rust-driver-samples>.\devgen.exe /add /hardwareid "root\ECHO_2"
Microsoft Device Generator

Device successfully created. Device Instance ID: SWD\DEVGEN\{4379876b-fe75-2b4c-a284-dbaaa815146b}

C:\Users\Daniel\clone\Windows-rust-driver-samples>pnputil /enum-devices /deviceid "root\ECHO_2"
Microsoft PnP Utility

Instance ID:                SWD\DEVGEN\{4379876b-fe75-2b4c-a284-dbaaa815146b}
Device Description:         Generic software device
Class Name:                 SoftwareDevice
Class GUID:                 {62f9c741-b25a-46ce-b54c-9bccce08b6f2}
Manufacturer Name:          Microsoft
Status:                     Started
Driver Name:                c_swdevice.inf

C:\Users\Daniel\clone\Windows-rust-driver-samples>cargo run --bin echoapp
   Compiling syn v2.0.79
   Compiling uuid-macro-internal v1.8.0
   Compiling uuid v1.8.0
   Compiling echoapp v0.1.0 (C:\Users\Daniel\clone\Windows-rust-driver-samples\general\echo\kmdf\exe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 6.11s
     Running `target\debug\echoapp.exe`
Error: "Error: No active device interfaces found.  Is the sample driver loaded?"
error: process didn't exit successfully: `target\debug\echoapp.exe` (exit code: 1)

DbgView does not show anything relevant, as far as I can tell:

If not, let me know at what step things didn't work out :)

I don't know :( Everything seems fine until the last step.

[JohnAZoidberg]

The system I'm running on is not activated. Might that be the problem?

The certificate does not change if I rebuild or clean, right? Do I have to install the cert again?

[wmmc88]

During the build it says this, I think this is the certificate verification you're referring to?

yes. this is it and it looks like the cert is fine. Just for one more sanity check, can you run certlm and make sure that WDRLocalTestCert is in Trusted Publishers and Trusted Root Certifcate Authorities?

The certificate does not change if I rebuild or clean, right? Do I have to install the cert again?

After first build, it will reuse generated certificates. You should see a WDRLocalTestCert found in WDRTestCertStore. Skipping certificate generation. message in the build log.

C:\Users\Daniel\clone\Windows-rust-driver-samples>.\devgen.exe /add /hardwareid "root\ECHO_2"
Microsoft Device Generator

Device successfully created. Device Instance ID: SWD\DEVGEN\{4379876b-fe75-2b4c-a284-dbaaa815146b}

C:\Users\Daniel\clone\Windows-rust-driver-samples>pnputil /enum-devices /deviceid "root\ECHO_2"
Microsoft PnP Utility

Instance ID:                SWD\DEVGEN\{4379876b-fe75-2b4c-a284-dbaaa815146b}
Device Description:         Generic software device
Class Name:                 SoftwareDevice
Class GUID:                 {62f9c741-b25a-46ce-b54c-9bccce08b6f2}
Manufacturer Name:          Microsoft
Status:                     Started
Driver Name:                c_swdevice.inf

This output is actually very useful. You see that the devgen-created devnode has c_swdevice.inf installed on it instead of oem2.inf (which is the name of echo_2.inf on your system). Now, you just need to find out why that is... https://learn.microsoft.com/en-us/windows-hardware/drivers/install/how-setup-ranks-drivers--windows-vista-and-later- explains driver ranking and possible reasons why echo2 driver was outranked.

In Device Manager, under the Sample Device Node, you will also get valuable info in the Events Tab, where one of the events should list the Driver Rank and any drivers it outranked. The SetupAPI.dev.log will also list out more details on the outranked drivers, and what the outranked drivers' ranks were. Usually this is a certificate issue, or a driver with wrong version of windows targetted (wdk sets the default value).

[wmmc88]

C:\Users\Daniel\clone\Windows-rust-driver-samples\target\debug\echo_2_package> pnputil /enum-drivers
Microsoft PnP Utility

Published Name:     oem2.inf
Original Name:      echo_2.inf
Provider Name:      TODO-Set-Provider
Class Name:         Sample
Class GUID:         {78a1c341-4539-11d3-b88d-00c04fad5171}
Driver Version:     10/06/2024 20.8.48.925
Signer Name:        Unknown

This output is also important. The signer name is Unknown so it looks like the certificate is not setup correctly and Windows is treating the driver as unsigned. This would explain the outranking. This output should look like (with the Published Name and Driver Version being different):

PS C:\Users\Melvin> pnputil /enum-drivers
Microsoft PnP Utility

Published Name:     oem1.inf
Original Name:      echo_2.inf
Provider Name:      TODO-Set-Provider
Class Name:         Sample
Class GUID:         {78a1c341-4539-11d3-b88d-00c04fad5171}
Driver Version:     10/01/2024 17.2.27.199
Signer Name:        WDRLocalTestCert

[wmmc88]

a common problem is people installing the certs in Current User instead of Local Machine

I just did a quick test of installing the test cert to Current User instead of Local Machine, and I repro all the behaviour you are experiencing(ie. c_swdevice outranking the echo2 driver, and the Unknown signer name). Can you double check to make sure your test cert is installed to Local Machine via the certlm steps above? If it is not, you must install the cert to Local machine, and then remove and re-add the driver.

[JohnAZoidberg]

installing the test cert to Current User instead of Local Machine, and I repro all the behaviour you are

Wow I'm so sorry. That was it exactly.
I thought when I ran the WDK_BUILD_ENABLE_SIGNTOOL_VERIFY it would've checked for that, too.
Is there a way we can do that?

Now it works:

PS C:\Users\Daniel\clone\Windows-rust-driver-samples\target\debug\echo_2_package> pnputil.exe /add-driver echo_2.inf /install
Microsoft PnP Utility

Adding driver package:  echo_2.inf
Driver package added successfully.
Published Name:         oem2.inf
Driver package installed on device: SWD\DEVGEN\{4379876b-fe75-2b4c-a284-dbaaa815146b}

Total driver packages:  1
Added driver packages:  1


PS C:\Users\Daniel\clone\Windows-rust-driver-samples\target\debug\echo_2_package> cargo run --bin echoapp
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.14s
     Running `C:\Users\Daniel\clone\Windows-rust-driver-samples\target\debug\echoapp.exe`
DevicePath: \\?\SWD#DEVGEN#{4379876b-fe75-2b4c-a284-dbaaa815146b}#{cdc35b6e-0be4-4936-bf5f-5537380a7c1a}
Opened device successfully
512 Pattern Bytes Written successfully
512 Pattern Bytes Read successfully
Pattern Verified successfully

I also see the logs in DbgView.

[JohnAZoidberg]

Ah now I can also see the certificate in cert manager!

[wmmc88]

The existing WDK_BUILD_ENABLE_SIGNTOOL_VERIFY used the /pa Microsoft Authenticode Verification Policy per https://learn.microsoft.com/en-us/windows-hardware/drivers/install/verifying-the-signature-of-a-test-signed-driver-file. It looks like the current signing requirements have become stricter, and align with the /kp Kernel Driver Policy (including UMDF drivers). I will update the signtool verification task: microsoft/windows-drivers-rs#232

[JohnAZoidberg]

Fantastic, thanks! I hope that can avoid more people running into the same issue 😅
At least I learned a lot about Windows drivers in the process of debugging this!

About the logging, is the current plan to keep using DbgView or also add WPF tracing (and include that in the PDB)?
I'm happy as long as I can see logs somewhere but for other drivers so far I've used only WPF with TraceView and selecting the PDB file to get tracing information.

[wmmc88]

I'm assuming that's a typo for wpp tracing: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/wpp-software-tracing.

Right now, your options for tracing/logging are:

1. DbgView for quick developer logs
2. https://github.com/microsoft/tracelogging for manifest-free etw logs (i.e. tracelogging). (km support was added in Added kernel_mode and user_mode features in tracelogging crate tracelogging#61)
3. There is also a much newer https://github.com/microsoft/tracing-etw crate, that takes advantage of the almost-defacto-standard tracing-rs facades, and then routes to ETW. This is essentially also tracelogging, but I don't think the crate currently supports km yet, so this won't yet work for kmdf or wdm drivers

We are early on in experimenting with wpp in rust right now, but that is a lot more involved and is not going to be available anytime soon (if at all).

[JohnAZoidberg]

I'm assuming that's a typo for wpp tracing: https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/wpp-software-tracing

Yes, that's right, thanks! So many similar terms and abbreviations 😵

2. https://github.com/microsoft/tracelogging for manifest-free etw logs (i.e. tracelogging). (km support was added in Added kernel_mode and user_mode features in tracelogging crate tracelogging#61)

Wow that looks very interesting. Have you got an example how to use that with the echo2 driver?

3. There is also a much newer https://github.com/microsoft/tracing-etw crate, that takes advantage of the almost-defacto-standard tracing-rs facades, and then routes to ETW. This is essentially also tracelogging, but I don't think the crate currently supports km yet, so this won't yet work for kmdf or wdm drivers

We are early on in experimenting with wpp in rust right now, but that is a lot more involved and is not going to be available anytime soon (if at all).

No problem at all, honestly, I'm just happy to get logs working at all.
I'm used to Linux where everything (espeially logs) is a text file somewhere on the filesystem, so it's a bit difficult to find how to find out what's going on and debug things on Windows.

With DbgView can I filter the log messages to show only those from my driver?
Or do I have to manually prefix them and use "Edit => Filter/Highlight"? to filter them with a regex?