Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


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/


FYI ... PCI device space configuration accesses

craig_howardcraig_howard Member Posts: 239

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

Comments

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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 30 January 2023 Live, Online
Developing Minifilters 20 March 2023 Live, Online
Writing WDF Drivers TBD 2023 Live, Online
Internals & Software Drivers 17 April 2023 Live, Online