Here’s an interesting situation: after installing Piriform’s Speccy hardware inspection tool on the new loaner Panasonic Toughbook FZ55-3, it crashes every time I run the program. Indeed, you can see the corresponding BSOD screen in the lead-in graphic. The stop code is SECURE_PCI_CONFIG_SPACE_ACCESS_VIOLATION. The culprit: the cpuz149_x64.sys driver. After some online research, my Speccy ToughBook BSOD analysis tells me that this driver is attempting PCI data access that Windows 11 disallows.
To be more specific I found an Open Systems Resources (OSR) community discussion that lays out exactly what’s going on. The datails are nicely covered in an MS Learn item. It’s named Accessing PCI Device Configuration Space, dated 3/13/2023. Essentially it constrains developers to use the BUS_INTERFACE_STANDARD bus interface, and specific read-config and write-config IO request packets to interact with said bus. Based on its BSOD error, the cpuz149_x64.sys driver apparently fails on one or more of those counts. That made me wonder: is there a workaround?
Speccy ToughBook BSOD Analysis Says: Don’t Use That Driver!
For grins, I found the offending item in my user account’s …\AppData\Local\Temp folder hierarchy. I renamed it with a sy1 extension. Then I tried Speccy again: it still crashed. Drat! The program is “smart” enough to see the file is missing and supplies a new one. Now that folder shows the old renamed .sy1 file and a .sys replacement (with today’s data and a recent timestamp).
When I rename to deny access to the current instance, Speccy supplies a new one.
That can’t work. Inevitably, the program promptly throws another BSOD. According to the Speccy forum, this happens with Memory Integrity enabled (as it is on the TB, and I want to keep it that way). This is what causes the BSOD. What to do?
If You Can’t Fight, Switch!
Fortunately, there are plenty of other freeware hardware profile and monitoring tools available. I happen to like HWiNFO64 myself. So I’ve removed Speccy and am using it instead. It is well behaved in its PCI bus access behavior and causes no BSODs.
Frankly, I’m surprised Piriform knows about this issue and hasn’t switched to a different driver (apparently, it comes from Franck Delattre over at CPU-Z, judging from its name). But boy howdy, is that ever the way things go sometimes, here on the wild frontier in Windows-World. Yee-haw!
