microsoft / microsoft/Windows-rust-driver-samples
Driver does not attach to device and does not log anything
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 356
- Forks
- 42
- PR merge metrics
- No merged PRs in 30d
Description
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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the reported sequence with pnputil, devgen, and cargo run --bin echoapp, then inspect the echo_2 driver package and its device association using DebugView and Driver Store Explorer. Done means the driver attaches to the generated device, emits log messages, and exposes an active interface that echoapp can find.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100