Last time, we speculated on how the buggy control panel extension truncated a value that it had right in front of it. When we sent our analysis to the vendor, they wrote back, “Can you check the driver version numbers on these crashes?”
When we checked the driver version numbers on all the crashing systems, they were something like “build 314”, when the current driver build number is something like “build 2718”. These users are running drivers that are ridiculously old! The vendor fixed that bug ages ago, but the user hasn’t gotten the fix. What’s going on?
My theory was that these users have turned off Windows Update or are otherwise declining to upgrade their video drivers. But I learned that my theory was probably wrong.
The deal here is that these are video drivers, which are a category of drivers where computer manufacturers have a lot of control. The manufacturer certifies the drivers for use on their PCs after performing their own acceptance testing on their specific hardware configurations. (Which are probably not hardware configurations that the video card vendors themselves are aware of.)
This responsibility carries forward post-sale. The computer manufacturer remains responsible for certifying driver updates, presumably by testing them against reference PCs that they maintain in their labs. Sometimes, manufacturers get customized versions of the video cards (all the better to differentiate your product with, my dear), which is why the video card vendor “driver downloads” sites often warn you to check with your computer manufacturer before installing a driver.
In practice, computer manufacturers are diligent about certifying drivers for a year, year and a half, two years tops.¹ After that, it’s not uncommon for them to abandon that model and not bother certifying drivers for it any more. All customers with that model of PC are just stuck with whatever video drivers were current as of the time the manufacturer stopped certifying drivers.
Microsoft maintains generic drivers for many classes of hardware, but intentionally sets them as low priority so that the PC manufacturer-provided drivers take precedence. The video drivers received directly from video card manufacturers are similarly deprioritized by the video card vendors. The computer manufacturer-certified drivers take precedence, even if that certification is horribly out of date.
¹ I wouldn’t be surprised if the length of time they certify drivers is somehow correlated with the length of the computer warranty.
I had a wildly different bug with a very similar symptom.
In the start of an x64 function ported from x86 to x64:
sub esp, 28h
The code worked just fine on Windows Vista and Windows 7 and went splat on Windows 8.1 (Windows 8 had an accessibility bug so bad we were never able to port to it; and this function was far enough in we never got far enough to run it).
What happened that broke it was of course High Entropy VA and Large Address Aware are now on by default.
So ... it's pretty clear to me...