by For months, the team here at OSR has been actively working with folks at Microsoft to find a solution to allow drivers on Windows 7, Windows 8, and Windows 8.1 systems, including Server 2012 R2, to be updated. This issue was first reported by us back in October 2020. Several MSFT Program Managers (PMs) have generously agreed to talk with us, and even to to look-into the problem at our behest. But the answer that has repeatedly come back is, in effect, the following:
We are discontinuing cross-singing. We will not provide an alternative. If you want to install drivers on down-level Windows systems, your alternative will be to pass the WHQL tests.
They only need to add “Have a nice day!” to make the answer complete. I suppose that’s implied.
And this is fine, except for all those drivers that can’t pass — or legitimately can’t even run — the tests required by the (now ancient) Hardware Certification Kit. And before you ask: No. Results from the newer, much improved, HLK cannot be used in place of the HCK.
A Work-Around for Some
Working with one of the more clever MSFT Program Managers, we have been able to identify a work-around for some types of drivers: You can Attestation Sign your driver package (using the Dashboard option for Windows 10 Attestation Signing), and in some cases this will allow your driver to be installed on down-level systems. The trick to making this work is that you must not sign the driver or CAT before submission. Yes, you will obviously have to sign the CAB file so your submission will be accepted.
How well the install process works depends on the type of driver you’re installing and the system on which you’re trying to install it.
For Windows 7 SP1, with a driver package that is Attestation Signed for Win 10:
- The package can be successfully installed on Windows 7 SP1, even with ONLY KB4474419 (the update for SHA-256 and to add the updated Root CAs).
- Non-PnP drivers (such a File System Minifilters) install without any pop-ups or warnings.
- PnP drivers that are installed via an INF will install successfully. However, during the install process the user will be treated to a pop-up saying “This driver is not digitally signed!” — However, it let us click “Next” and then we got a scary red popup saying “Windows can’t verify the publisher of this driver software” — We selected “Install this driver software anyway” and the driver was successfully installed.
For Windows 8.1, with a driver package that is Attestation Signed for Win 10:
- Non-PnP drivers (such as File System Minifilters) can be installed without any warnings or errors.
- We were not able to successfully complete an INF-based install of a PnP driver via Device manager that had only been Win10 Attestation signed.
So, Win 10 Attestation Signing is a work around: (a) For those who need to install a non-PnP driver, and (b) For those who need to install a PnP driver on Win 7 only, and who additionally don’t mind subjecting their users to the scary dialog boxes.
I should probably also add (because somebody on NTDEV asked me about this) that installing non-PnP drivers (like File System Minifilters) that have been Attestation Signed using an INF, via right-click “Install” works perfectly both on Win 7 and Win 8.1.
Microsoft Slams The Door on Extending Cross-Signing
Recall that what started this whole debacle was Microsoft declaring that cross-signing will no longer be a supported way of installing drivers on down-level versions of Windows after 1 July 2021. They have sought to enforce this through their agreements with Certification Authorities (CAs) under the Microsoft Trust Root Program. Accordingly, most CAs have issued cross certificates (which you would used to cross-sign your driver) that expire on or before 1 July 2021.
However… as we were working with the community and with Microsoft to find a solution to the overall problem, it came to our attention that there were CAs that had issued cross certificates that expired as late as 2025… well beyond the deadline of 1 July 2021! Technically speaking, that would allow anyone who holds a cert from one of these CAs to continue to cross-sign their drivers until the cross certificate expires.
So… being the “good citizens” that we are, we asked Microsoft for a ruling on this. Their answer was to update the documentation about this whole mess, threatening to revoke the certificate of anybody who used it to cross-sign a driver for installation on down-level versions of Windows after 1 July 2021.
So, that work-around is obviously blocked.
WHY? Why Won’t Microsoft Fix This?
We’ve been wresting with this problem now for months. As I said at the beginning of this blog post, we’ve spoken to multiple PMs… some of whom have been generous with their time and seemed to really want to find a solution to this problem.
But, after it all, I’ve come to the sad conclusion that Microsoft is just not going to fix this. Why? Well, of course, it’s complicated.
The primary reason is that the folks at Microsoft think they understand the ecosystem, it’s options, and the impact of this decision… but in fact they do not.
The secondary reason is that there’s no one person that’s senior enough and in whose area of responsibility this problem clearly belongs. There’s no “Director of Not Fucking Up The Installed Base That Uses Down-Level Versions of Windows.”
And the final reason is that nobody at Microsoft has any visibility into the size or import of the ecosystem that this problem is affecting. Flight control systems in the DoD? Systems in the oil and gas industry that run refineries? Tens of thousands of corporate “terminals” for capturing transactions? Yes, those things do exist. Really. And there are a lot of them. But nobody at Microsoft seems to recognize that.
I’ve come to the sad conclusion that, regardless of what individual PMs themselves might think, the overall institution’s position is that driver devs in the community are all either stupid or lazy, because we could just pass the WHQL tests if we really wanted to. ‘Either update the OS you’re using or pass WHQL… if you’re writing a decent driver you should have no trouble passing WHQL’ is basically what they’re thinking.
Of course, the people making these decisions have never written a driver, have never tried to setup the HLKs/HCKs, don’t understand what the WHQL tests actually test, and don’t really know why we’d be using Win7 anyhow. So, when some well-meaning PM raises this issue, they just get a whole pile other Microsoft PMs (and perhaps even devs) telling them “there’s no reason these people can’t just have their drivers pass WHQL if those drivers are correctly written.” And, understandably, they believe it. Or, at least, they’d can’t actively refute it. Multiple real, actual, practical, examples of devices that could never be WHQL’ed have been lost on them.
The ordinary feedback mechanisms that can be used to awaken Microsoft to a massively bad decision are also not at work here. The OEMs (our primary feedback mechanism) don’t care, because they’re not shipping new systems with Win7. The big IHVs don’t care because the hardware was sold long ago, and they don’t “see” the problem through their lens of unit sales. The big ISVs are antivirus, security, and encryption vendors… and they have an “out” (just Attestation Sign the drivers for Win 10 and they’ll load, as we describe above).
So… in short: The problem is just too small and too esoteric. Nobody understands its impact, and nobody is personally responsible for fixing it. We, as a community, lose.
What’s the Long Term Effect?
I was planning to write a few paragraphs here about how this Microsoft policy significantly encourages the already-existing stampede of developers to move their solutions from Windows to some other platform. But every time I raise this issue, especially to Microsoft, people just roll their eyes. I can hear them thinking sardonically: “Right. Like people are going to move their shit from Windows to Linux just because we won’t let them update their Win 7 drivers. Right. Sure. You’re nuts.”
Well, maybe you are lucky. Maybe your drivers are written using KMDF, and the dev who wrote it never used ULONG where they meant PVOID. Maybe your apps can be easily updated to the latest SDK and runtimes. Maybe you don’t rely on any legacy hardware. Maybe you can afford to put double the memory on the systems running your applications. If so… bingo! Move to Win 10 and be happy. Well, “happier”, perhaps.
However, it’s much more likely that in moving your system from Win 7 to Win 10 you have a lot of redesign and reimplementation to do. Are you really going to just take your giant cardiology app, written in C# and built with .NET 3.5 and recompile it and have it run on Windows 10? I don’t think so. Maybe the dev who wrote the driver for your custom data board didn’t trust “the new driver model” (KMDF was only 4 years old at the time of Win 7’s release) and used “tried and true” WDM instead. If so… you probably have a lot of work to do.
And if you do happen to have a lot of work to do, why not just redesign your stuff so it uses Linux? Or VxWorks? OK, probably not VxWorks (this being 2021), but you get the idea. If you have a lot of work to do, why not at least plan to have that work get you to someplace you’d rather be in the end? The devs in your office probably have used Linux. They probably prefer Linux. Maybe they wrote a driver for Linux at some point while in school. That experience would be good for your project, right?
Hmmmm… I guess I wound-up writing those paragraphs after all.
So, We’re Done?
Yes. It certainly seems like we’re done. That’s the end of the story when it comes to updating drivers on versions of Windows other than Windows 10. Even supported versions of WIndows.
I have no hope of MSFT reversing their decision, or giving us any relief.
If you’ve got a non-PnP driver, you’re pretty much all set using the Win 10 Attestation Signing work-around. If you have a PnP driver for actual hardware, and you need to run Windows 8 or Windows 8.1 — You’re screwed. If you have a PnP driver and you need to run on Win 7… MAYBE you’re OK.
OSR Open Systems Resources, Inc.