Microsoft: No More Updates Allowed for Drivers on Win 7, Win 8, Win 8.1

NTDEV
1

This is bad news… and it’s serious.

In short: As of July 2021, Microsoft will no longer allow new releases of drivers to be cross-signed and loaded on Windows 7, Windows 8.1, or Windows Server 2012 R2 (including Windows Embedded 8 and Windows Embedded 8.1). You can read the policy here.

Folks have raised this issue several times here in this forum in the past. One of the most recent was Mr. Roddy in this thread. I have always urged posters not to worry, because I assumed that this policy would be “corrected” – Apparently, I have been overly optimistic.

For more than a year, folks here at OSR have been been engaged with Microsoft over this issue. Our understanding (or, perhaps, it was simply our hope) was that this policy was going to be “fixed.” Surely, we reasoned, Microsoft is not going to prevent us from releasing updated drivers for versions of Windows that are still supported by Microsoft. We heard rumors that Attestation Signing would be extended to cover versions of Windows prior to Windows 10.

Apparently we were mistaken. Despite all our efforts, we have been unable to identify ANY plan that’ll allow folks to release updated drivers for versions of Windows prior to Windows 10.

So, as of July 2021, if you want to update a driver that runs on a Windows version other than Windows 10… forget it. You’re screwed. And, worst of all, your customers are screwed.

According to Microsoft’s published plans, the only way to update a driver for a version of Windows other than Windows 10 is to have that driver pass the HLK/WHQL tests. That is, assuming that your driver falls into a category where there are HLK tests. And your driver can pass those tests. There are many, many, drivers – especially drivers for special-purpose systems – that will never be able to pass the HLKs and have no reason or need to pass the HLKs.

I’ve written more about this here.

If we work together, we can get Microsoft to change this plan. This community has done it before.

Work your technical contacts. Get the message clearly presented to the folks you work with at MSFT.

Even more important, you must explain the problem to the managers at your company who regularly engage with MSFT. You must get your execs and your managers to raise this issue with their MSFT contacts.

Because if we don’t change this policy, lots of Windows users are going to be put in very difficult positions.

The time to act is now, folks. Microsoft needs to hear from you and from your management team.

The clock is ticking…

2 Likes
2

They’ve recently added a table to the policy page.

How do production signing options differ by Windows version?

Driver runs on Drivers signed before July 1 2021 by Driver signed on or after July 1 2021 by
Windows Server 2008 and later, Windows 7, Windows 8 WHQL or cross-signed drivers WHQL or drivers cross-signed before July 1 2021
Windows 10 WHQL or attested WHQL or attested

I hope “Windows Server 2008 and later” means “Windows Server 2008 and Windows Server 2012” and “Windows 10” means “Windows 10-based OSes including Windows Server 2016 and Windows Server 2019.”

3

I hope “Windows Server 2008 and later” means…

It does… but how does that help?

After 1 July 2021, you pass WHQL or you can’t install your drivers on any OS other than Windows 10. Full stop.

Even though some of these versions of Windows will be supported well into 2023.

Peter

4

@“Peter_Viscarola_(OSR)” said:

I hope “Windows Server 2008 and later” means…

It does… but how does that help?

It helps if you only care about future development for Windows 10-based OSes. For new drivers that will only support Windows, but would like to also support Windows Server, I would have appreciated clarity here that newer Windows Server versions will continue to support Attested Signing. You’d think that they would have been careful to get this right after the years of waffling on and poor communication about the the threatened WHQL requirement for Server OSes.

I wholeheartedly agree that for maintenance purposes or for continuing driver development on Win7/8.1 this is a complete disaster.

5

Yes, agreed, on all points. And I agree that the article isn’t written with anything remotely resembling sterling clarity.

In fact, I’ve been trying to explain that page via email over the past two hours to a well known journalist who covers issues related to Microsoft.

Peter

1 Like
6

In the present environment it seems unlikely that an issue like this one will get much traction. Think about it from the opposite point of view. We’re going to shutdown the ability to develop new drivers, or deploy corrected drivers in the last 1-2 years of a 10 year support period and the community wants to have the ability to make a new build on the second to last day; and then we then have to field a support call on on the very last day. All in a way of viewing OS versions that we now consider obsolete while we push all of our ‘progressive’ clients towards Microsoft 365.

Whatever I think about the policy, that seems a tough road to get this done

7

In order to solve a problem one must first define what the problem is. Someone needs to ask Microsoft the key question: “What problem are you trying to solve?” Maybe there is a better, more elegant solution for Microsoft and us.

1 Like
8

What irks me most is that this is totally unnecessary. What is the net recurring cost to Microsoft of maintaining this capability? Zero. It just seems mean-spirited. I’ve come to expect this from Apple, but not from Microsoft.

2 Likes
9

I recently discovered that drivers signed with a trusted cross-certificate (even if they are signed now) can still be installed in Windows 10 if secure boot is disabled in BIOS. Does the new policy also affects this? Starting July 2021, can we still sign and install a driver signed with a trusted cross-certificate on a Windows 10 machine that is not running in testsigning mode but has secure boot disabled? This is the only workaround I found on how independent-developers can sign and launch a windows 10 driver.

10

I literally do not understand, and I have not been able to get anyone at Microsoft to give me an explanation, of what they’re hoping to accomplish with this policy.

It feels to me like some middle manager not understanding the vastness of the ecosystem. If the goal is to push people to upgrade to Win10, this is a very wrong headed idea.

You can’t just run Windows Update on a carefully configured system running Windows Embedded in a medical device, or on an aircraft, or on a system that does continuous process control in a refinery. These systems have all been specifically qualified with specific versions of Windows and updating to a different version of Windows accomplishes exactly NOTHING except destabilizing these systems.

You can’t just upgrade 85,000 corporate desktops running dozens of LOB applications.

This is why we were convinced this policy would be changed. But, without the community pushing back, it looks like it IS going to happen.

Note that the computer system OEMs don’t care about this policy, because all the drivers on their systems have to pass WHQL out of the box. So, it’s up to the IHVs and ISVs.

Peter

11

Starting July 2021, can we still sign and install a driver signed with a trusted cross-certificate on a Windows 10 machine…?

No. They are shutting down the whole cross-signing ecosystem. The cross certificates will all expire and no more will be created.

1 Like
12

I was going to start pushing this upward inside the giant tech company I
work for, but I stepped back from that: they aren’t going to have a problem
with the policy. Officially all of our drivers are required to be WHQL
signed,so there is nothing to officially complain about. The impact will be
on test and support, and that impact is invisible above a certain level.

I was going to point out that this kills the use of windows embedded as an
RTOS in the DIY/hobbyist world, but that ship sailed a long time ago.

1 Like
13

Testing is definitely going to be harder, no matter the kind of driver.

14

Sitting here in 2020 and complaining about policies that don’t make any sense. This one is well down that list.

15

@Mark_Roddy said:
I was going to point out that this kills the use of windows embedded as an
RTOS in the DIY/hobbyist world, but that ship sailed a long time ago.

+1. No one is going to put Windows into embedded systems anymore, so yep… it looks like farewell salute of MS to embedded makers.

16

No one is going to put Windows into embedded systems anymore,

Hmmm… I don’t know what you mean by this.

If you’re saying that this policy might cause folks to rethink their use of Windows Embedded… maybe. In many cases, moving to a new version of Windows in an embedded system is a Big Deal. If they view this policy as a violation of trust, then they might say “If we have to consider another version of the OS, we might as well consider a different OS and avoid getting screwed over like this in the future.”

I see that, for sure.

Peter

1 Like
17

Officially all of our drivers are required to be WHQL signed

You’re lucky that you write the types of drivers than can be WHQL signed.

Here at OSR… about half the drivers we write can never possibly pass WHQL.

Peter

18

@“Peter_Viscarola_(OSR)” said:

No one is going to put Windows into embedded systems anymore,

Hmmm… I don’t know what you mean by this.

Yes, violation of trust - but even much earlier Windows embedded become too encumbered and hard to deal with, when other options have developed.
At least, where I live, popularity of Windows embeddedhas dropped to zero.
I haven’t heard anything related to Windows embedded, IoT and WinCE from my network since years ago.
– pa

19

Actually, I make a good living helping clients put Windows Embedded Compact into their systems.  Also helping to keep their older systems running.  No driving signing needed at all there!

Greg

On Sat, 17 Oct 2020 22:38:12 +0000 (UTC), Pavel_A wrote:

OSR https://community.osr.com/

Pavel_A commented on Microsoft: No More Updates Allowed for Drivers on Win 7, Win 8, Win 8.1

> @Mark_Roddy said:
>
> I was going to point out that this kills the use of windows embedded as an
>
> RTOS in the DIY/hobbyist world, but that ship sailed a long time ago.

+1. No one is going to put Windows into embedded systems anymore, so yep… it looks like farewell salute of MS to embedded makers.

20

While I wish for Microsoft’s policies to drive users to Linux, I doubt it will happen.  This latest driver signing change is just one more step in their plan to force everyone off Windows 7 and onto lock-in Windows 10.

First, Windows is too entrenched in the Enterprise desktop.  It gives the “Gatekeeper” IT groups too much power to control and lock the desktops.  Even though viable alternatives exist for almost every general desktop application, IT groups, CIOs, etc won’t take the risk to jump ship.

Secondly, Linux is a second-class OS to most game manufacturers.  Let’s be honest, gaming drives almost the entire non-enterprise desktop.

Supercomputers are already exclusively the domain of Linux and derivatives now.  Corporate servers are a mixed bag.

I make a living doing embedded on both.  I’ve been doing Windows Embedded for over 20 years now.  It WEC7/WEC2013 consulting still drive a large portion of my income.  Increasingly Linux is becoming my majority income producer.  As long as WEC pays enough to make it worthwhile, I’ll continue.  The day it doesn’t, all of my Windows systems will be entirely Linux.

Windows 10 update policy has had me cussing on more than one occasion.  It’s infuriating to find a 3-day test was interrupted in the middle of the night for an unannounced “update” that Microsoft has decided was more important.  Or when it take 5 hours to reboot because of a major “upgrade” that could not be postponed.  How I wish I could have billed Microsoft for the $700 in lost billing time.

OK, done ranting,
Greg