Problems installing the 'Toaster' simple function driver sample

Hello.

I’m coming back to windows drivers after a very long hiatus and am in the process of getting a feel for current state of windows KMDF drivers. With that caveat, I’m seeing some odd issues after installing one of the sample drivers on my test machine.

Apologies in advance for the rather lengthy post, but given my newbie status, I just wanted to provide all the pertinent details :slight_smile:

The core issue is that I do not see the device node in ‘device manager’ after driver installation and one of the sample test apps, ‘toaster.exe’ app does absolutely nothing.

This is what I did:

  • setup and connect to a physical target machine over kernel debugger (network) from a different, physical dev machine
  • use bcdedit to enable test signing on target machine
  • reboot target machine
  • start with the function driver sample in ‘general/toaster/toastDrv/kmdf/func/simple’ and build it (‘msbuild /p:configuration=“Debug” /p:platform=“x64” .\wdfsimple.vcxproj’) ‘as-is’ on dev machine, without any modifications at all
  • copy over the required files (.cer, .inf, .sys) to target machine
  • install the test certificate for both ‘current user’ and ‘local machine’ on target machine
  • install sample driver using ‘pnputil /add-driver wdfsimple.inf /install’. Output shows published name of ‘oem30.inf’ and that 1 driver package was added successfully.
    (the page at https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/devcon suggests using pnputil.exe instead of devcon.exe)

Per the README.md from the sample, the device node should now be visible under ‘Device Manager’ but I don’t see it. I tried listing devices ‘by type’ and ‘by connection’, enabled ‘show hidden devices’, refreshed a few times but none of it helped.

I then checked windows/inf/setupapi.dev.log for install time errors. Among the usual output, It also had a line saying ‘dvs: Unable to find matching devices’, but the exit status said ‘SUCCESS’. Next I verified correct driver installation by running ‘pnputil.exe /enum-drivers’ and made sure wdfsimple.inf was present in the output, mapped to oem30.inf in my case.

That said, running ‘driverquery.exe’ in normal and verbose modes did not show wdfsimple.sys/oem30.inf listed anywhere.

Wanting to rule out a case of ‘create node on first access’, I tried running the toast.exe app (general/toaster/toastDrv/exe/toast) on the target machine. Strangely, it did absolutely nothing, no output of any sort even when passed junk parameters as was expected based on it’s source.

Out of curiosity, I deleted (‘pnputil /delete-driver wdfsimple.inf /uninstall’) the supposedly installed driver, verified the ‘delete’ operation in setupapi.dev.log and tried reinstalling it using the ‘devcon install WdfSimple.inf {b85b7c50-6a01-11d2-b841-00c04fad5171}\MsToaster’ command mentioned in the README.md. This command also failed with some errors in setupapi.dev.log but I did see the node being created. From the devcon console output it seems the node is created first and then the driver installation is attempted? In any case, the node is not named as mentioned in the README.md but shows up as an ‘unknown device’.

If it helps, this is the devcon related output in setupapi.dev.log:

>>>  [Device Install (UpdateDriverForPlugAndPlayDevices) - -encodedCommand]
>>>  Section start 2020/11/27 17:05:24.459
      cmd: "C:\wrk\TestTools\devcon.exe" install .\wdfsimple.inf -encodedCommand YgA4ADUAYgA3AGMANQAwAC0ANgBhADAAMQAtADEAMQBkADIALQBiADgANAAxAC0AMAAwAGMAMAA0AGYAYQBkADUAMQA3ADEA \\MsToaster -inputFormat xml -outputFormat text
     ndv: INF path: C:\wrk\wdfsimple\wdfsimple.inf
     ndv: Install flags: 0x00000001
     ndv: {Update Device Driver - ROOT\TOASTER\0000}
     ndv:      Search options: 0x00000080
     ndv:      Searching single INF 'C:\wrk\wdfsimple\wdfsimple.inf'
     dvi:      {Build Driver List} 17:05:24.964
     dvi:           Searching for hardware ID(s):
     dvi:                -encodedcommand
     dvi:      {Build Driver List - exit(0x00000000)} 17:05:25.268
!    ndv:      No matching drivers found in single INF
     dvi:      {DIF_SELECTBESTCOMPATDRV} 17:05:25.429
     dvi:           Default installer: Enter 17:05:25.521
     dvi:                {Select Best Driver}
!    dvi:                     Selecting driver failed(0xe0000228)
     dvi:                {Select Best Driver - exit(0xe0000228)}
!    dvi:           Default installer: failed
!    dvi:           Error 0xe0000228: There are no compatible drivers for this device.
     dvi:      {DIF_SELECTBESTCOMPATDRV - exit(0xe0000228)} 17:05:26.029
!    ndv:      Unable to select best compatible driver. Error = 0xe0000228
     ndv:      No drivers found for device.
     ndv: {Update Device Driver - exit(00000103)}
!    ndv: No better matching drivers found for device 'ROOT\TOASTER\0000'.
!    ndv: No devices were updated.
<<<  Section end 2020/11/27 17:05:26.532
<<<  [Exit status: FAILURE(0x00000103)]

(What’s with the hardware id being set to ‘-encodedcommand’ up there?)

My questions:

  1. is pnputil.exe the right tool for installing this sample? If so, do I need to do something more after running this command to actually create the device node or will it be created dynamically at ‘first use’ by some application/entity?

  2. if devcon.exe is still an ‘acceptable’ way of installing the driver and creating the device node, why does it fail in my use case?

  3. why does the ‘toast.exe’ app fail so silently? did I miss a readme that lists the implicit dependency binaries that also need to be installed on the test machine? this is really puzzling 'coz were the machine missing some implicitly linked shared libraries I’d expect some errors popups to that effect. As mentioned above, even passing junk parameters to force usage output does
    nothing. I can certainly write my own app, but am really curious about what’s going on here.

If it matters, the target machine is running windows 10 20H2 (amd64), build 19042.630, and the build env is Enterprise WDK version vb_release.19041.1. The wdfsimple.sys, toast.exe binaries are built for amd64, chk.

I think I’m missing something fundamental here and any pointers/reminders would be highly appreciated.

tia

  • fibo

found the issue. One word - Powershell.

Turns out powershell was interpreting commandline parameters meant for devcon.exe. It mangled the {b85b7c50-6a01-11d2-b841-00c04fad5171}\MsToaster to somehow generate a hwid of ‘-encodedCommand’ for the actual devcon commandline . It was staring at me all along and I was too dumb to see it. Enclosing that that entire hwid in single quotes did the trick.

As for the app failing mysteriously? Yep. Powershell again. The target machine was missing debug versions of some of the ‘universal’ dlls and as a consequence the app loading bombed out. For some reason, powershell decided to suppress the ‘missing dll’ popups and let the app loading fail silently. It was only after I ran the commands under ‘good old dos box’ that I saw those popups. I was running a debug version of the app and the ‘debug’ version of the ucrtbased.dll was not present on the target machine. Running a ‘release’ version (and installing the VC 2019 x64 redistributables for good measure) fixed the issue.

As for why use powershell in the first place? Well, for me at least, the returns are worth such times when I begin questioning my sanity :expressionless:

Or so I like to tell myself.