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/
As an FYI (some/ most/ all of the readers here already know this) MS for some time has had mechanisms in place to protect PCI config spaces from access (read or write) from "unauthorized methods", i.e. something that does not use BUS_INTERFACE_STANDARD or originates from a bus driver for that PCI device [https://learn.microsoft.com/en-us/windows-hardware/drivers/pci/accessing-pci-device-configuration-space]
Essentially, as some/ most/ all readers here know the MS position is that hardware PCI resources belong exclusively to the bus driver that was installed for and loaded for them; so, the "ReadWriteEverything" driver is no bueno. MS will enforce this with a BSOD "SECURE_PCI_CONFIG_SPACE_ACCESS_VIOLATION"
And as some/ most/ all readers here know you need to have three things for this enforcement operation to take place: 1) run a build of Windows in the Win10+ family, 2) have the motherboard BIOS support an SDEV ACPI table (this is a requirement by MS, but until recently it's one of the 'kinda enforced requirements, like TPM 2.0 chips) and 2) have VBS enabled in the OS (on by default with Win11+ installs, off by default on Win10 installs). If any of those three things is not true then the PCI space protection is NOT active
What may not be know by some/ most/ all readers (based on my perusals of the threads here) is that the BSOD that MS will throw for this access violation is NOT catchable by a try/ except block; much like the DPC timeout BSOD, it's not there as an error to be handled, it's there to tell the developer for "fix your *&%#$ code"
This recently became an issue for me with some code that uses ECAM and virtual mapping methods to access more information about a target PCI device than what is found using BUS_INTERFACE_STANDARD, and which started throwing the BSOD mentioned. Investigation revealed that the customer had recently installed the product on machines which had SDEV turned "on". How can you tell if SDEV is enabled? Very simply, look for either "Enhanced Hello sign in support" or "Enhanced Sign in support" in the BIOS [gotta love these clear, descriptive labels] and see if it's enabled; if it is then SDEV is enabled
FYI, in case someone else in the future does a search for this BSOD and is losing sleep over it ...
|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|