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/
I'm attempting to develop a KMDF driver for a legacy (non-PNP) ISA device. My test set up is Windows 10 21H2 running on VirtualBox with a custom plugin that simulates the I/O, IRQ and memory of the target hardware.
Despite this being a non-PNP device I believe I should be developing a PNP driver and using the INF file to specify the actual resources to be used. These will then be passed to the driver through the EvtDevicePrepareHardware callback.
I'm using the FactDef section rather than LogConfig because from what I've read the LogConfig section is both deprecated and ignored whereas FactDef is only deprecated. The INF section looks like this:
[MyISADrv_Device.NT.FactDef] ConfigPriority=HARDRECONFIG IOConfig=1C00-1C03(0FFF::) IRQConfig=5 ;MemConfig=D0000-DFFFF
The driver is installed by using the "Add legacy hardware" option in device manager. I see a call to EvtDriverDeviceAdd followed by a call to EvtDevicePrepareHardware with the specifed resources and everything works as expected.
If I uncomment the MemConfig line then I see the call to EvtDriverDeviceAdd but EvtDevicePrepareHardware is never called and the device is flagged as having a problem:
"This device cannot find enough free resources that it can use. (Code 12)"
After reading this article on hardware resources I added additional callbacks for EvtDeviceFilterRemoveResourceRequirements, EvtDeviceFilterAddResourceRequirements and EvtDeviceRemoveAddedResources. I see calls to the first two functions with the expected resources however the third function is never called.
The article above talks about the resource requests being passed to the bus driver, but I don't know what bus driver that would be as this is effectively a root-enumerated device.
As far as I can tell there doesn't appear to be a conflict with any other hardware for the address range D0000-DFFFF so does that mean that Windows thinks that those addresses simply don't exist and therefore cannot be used?
It may be that this works just fine on the target hardware but that isn't available for testing just yet so I'd like to understand why it fails in the virtual environment.
|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|