FYI ... PCI device space configuration accesses

craig_howard

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 ...

Tim_Roberts

For what it's worth, blue screen bugchecks have NEVER been catchable by a try/except. They are intended for unrecoverable situations.