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/
Hi all, I'm currently in the process of bringing up some custom video controller hardware under Windows 10 and am running into some issues that have made the driver development process incredibly annoying. Basically, every time the device is disabled (be that manually or when trying to deploy a new version of the driver to debug), it completely disappears from the PCI bus. Attempts to re-enable it give errors indicating that the device no longer exists, and I need to perform an entire reboot cycle to get it to come back. This basically means that every attempt to deploy and debug a new driver involves at least one full restart, at which point the driver is already installed and I end up missing the startup process.
The hardware in question is a Xilinx/AMD K26 SOM FPGA on a custom carrier card that exposes the PCIe interface. From what I can tell, during the device disable process none of the PCIe endpoint state changes in the hardware - it still thinks it's connected, but Windows does not. Note that I can successfully flash Xilinx's PCIe DMA bitstream to the device and use their Windows drivers to communicate with it, so I'm pretty confident that the actual PCIe interface/hardware work.
Now, if I completely remove the drivers and reboot the machine, the device shows up as a generic Video Controller (due to its Physical Function class code settings) and I can disable and re-enable over and over without issue, leading me to believe that something about the driver is causing the device to disappear completely when it is disabled.
Note that this driver, at the moment, is completely barebones - it does basically nothing but try to map the various PCI BARs presented by the device and then read from some registers through those addresses. I can get VS to attach to the remote machine, but I have thus far been unable to actually get it to stop at a breakpoint in the driver so I can step through and actually see what it's doing. The driver IS logging trace messages that I can view using traceview, which show that it's progressing through the driver as I would expect, during both device startup and shutdown.
Somewhere, after the driver is done trying to clean up the device, Windows seems to be completely removing the device from the bus and disposing of it. The only way to get it back is to restart.
Does this make any kind of sense? Granted, I should probably spend some time getting the debugger working properly (perhaps foregoing VS' wrapper and just sticking with windbg directly?) so I can see if anything odd is happening as I step through the driver, but this behavior is still a bit confusing to me.
|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!|
|Kernel Debugging||13-17 May 2024||Live, Online|
|Developing Minifilters||1-5 Apr 2024||Live, Online|
|Internals & Software Drivers||11-15 Mar 2024||Live, Online|
|Writing WDF Drivers||26 Feb - 1 Mar 2024||Live, Online|