The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Like others before me, I'm trying to create a virtual display driver using the Idd(Cx)SampleApp from the WDK for Windows 10 1903. I've written for Windows since the late '80s, but I'm new to the DDK/WDK. I've been working on this for several weeks, and I've read everything relevant that I can find online.
In a response to a older post from someone attempting a similar goal, Marcel Ruedinger (Datronisoft) stated:
Two types of WDDM display drivers can reasonably be written by regular driver developers:
- WDDM DOD Display Only Drivers (e.g. KMDOD).
- WDDM IddCx Indirect Display Drivers.
The downside of both: Currently they both need real hardware.
This was a non-starter for me, because I'm trying to create a virtual display (adapter/monitor) with no hardware backing (1).
But then I read this in another post:
For those who want to go beyond the regular and documented scope of Windows operating system support and really write a contemporary virtual display driver:
- Write a USB bus driver which emulates a USB bus with connected display device (e.g. DisplayLink USB display).
- Then install the WDDM IddCx Indirect Display sample [from the WDK] on the virtual USB driver's emulated display device.
Voila - there is your virtual display!
So, I added a USB Bus Emulator driver project to my solution.
Hint: I heard that the above named IddCx sample can supposedly even be operated without hardware (2) when starting Windows with "Driver Signature Enforcement" disabled (F7).
Hmm, I assumed that the emulated USB Bus eliminated the need for physical hardware...?
And then a bit later, I discovered the following discussion involving Doron Holan and Marcel Ruedinger, leading me to think I didn't need the USB Bus Emulator driver after all...:
You need a root enumerated bus driver which will then enumerate a child display device(s).
Doron's approach is correct and would work, but usually it is not necessary in a WDDM IddCx driver.
Typically it is not the graphics adapter itself, but the display monitor which is hot-plugged.
The display monitor is a child device object of the WDDM IddCx Adapter device object.
The IddCx framework itself (namely IndirectKmd.sys kernel mode filter driver) acts as a bus driver creating a child device object (PDO) for each hot-plugged display monitor.
In a WDDM IddCx driver, a new display monitor child device object is created using IddCxMonitorCreate(...).
After being created, it can be hot-plugged using IddCxMonitorArrival(...).
I have a driver based upon the IddSampleDriver from the latest WDK, signed with a test cert. With Driver Signature Enforcement disabled on the Windows 10 Pro  VM, I'm able to install it successfully (at least, there are no obvious signs otherwise -- I wasn't ever able to get driver install debugging working).
Nothing shows up in Device Manager until I run the test program, which just calls SwDeviceCreate to enumerate the device and then waits for a key press to exit. Once enumeration has completed successfully, the device shows up in Device Manager under "Other devices" with the /!\ icon. Looking at Properties and Details, the device appears to be in an unconfigured or misconfigured state (3).
I'm at a disadvantage, because I haven't worked on Windows drivers before. I don't know what to expect, and sometimes it's difficult to know whether something is a real problem or my expectations are just wrong. Books and documentation are helping, but it's been slow going.
Is the 'not configured correctly' status a cause or a symptom? The vanilla IddSampleDriver project gives the same behavior/result.
Running IddSampleTest.exe, I never see WUDFHost.exe come up in the remote debugger after SwDeviceCreate is called. The creation callback in the test app seems to get a non-zero handle passed in. Shouldn't I see the driver being loaded, or is this due to lack of physical hardware? Not sure what to expect here...
(1) At least for now. The virtual display(s) may eventually be backed by something. TBD
(2) I took this to mean that using this approach, the "virtual display" driver I'm trying to create didn't need to be backed by hardware. However, now I realize Marcel may have been saying that that's only possible during testing, when Driver Signature Enforcement is turned off.
This device is not configured correctly. (Code 1) This operation returned because the timeout period expired. To find a driver for this device, click Update Driver.
Windows Developer since 1989
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Writing WDF Drivers||7 Dec 2020||LIVE ONLINE|
|Internals & Software Drivers||25 Jan 2021||LIVE ONLINE|
|Developing Minifilters||8 March 2021||LIVE ONLINE|