Re: M$
At this point, it's not clear whether the hold is a fault in the driver or a fault in the OS. If it were a fault in the OS, I expect that the update would be withdrawn, rather than held.
Irrespective of this particular case, I believe that there have been many cases in the past where a Windows update has exposed an error in a driver. Often that seems to have been where the driver was created to the OS implementation and not the OS interface. Is that the fault of Micros~1? You suggest that it is.
If a 3rd party solves a problem by working to the implementation, rather than the interface, how do Micros~1 change anything? If they fix a bug, the implementation changes. That change might be used by the 3rd party. Who's fault is that one? If they change the implementation to improve speed, the implementation changes. If that change borks the 3rd party, who's fault is that? I don't doubt that there'd be plenty complaints if Micros~1 didn't try to fix bugs or improve performance.
Another class of issue is where the 3rd party doesn't use the interface correctly? Are errors properly checked? Are threading issues correctly handled? Given the speed of processors and the scale of deployment, a one-in-a-million problem could be a very frequent event.
There are many ways that a 3rd party driver might fail that it might be unreasonable to consider a failure of Micros~1.
You've also suggested that Micros~1 doesn't test anything. I don't know what processes they have in place but I expect they have a substantial investment in testing. I doubt that the testing is perfect and I would expect that the testing focuses on confirming the behaviour of the published interface and not the implementation. There's certainly no way they can test every application on every combination of hardware. I expect there's also a balance between the speed that changes need to be released (e.g. for security issues) and the volume of testing.
Previously, I worked beside a team that used to constantly complain that Windows updates broke their software. The code was filled with hacks and workarounds they'd found on the interweb, where there was often an interface that'd been ignored. The code seldom checked error codes and gave little (if any) thought to concurrency. UI layouts were ... errr ... unconventional. Custom colours were used everywhere and standard colours and typefaces (i.e. user system settings) were ignored. When things went wrong following a Windows update, my first thought was not that it was the fault of Micros~1. Of course, you might disagree.
For context, I'm a Windows user at work (not my decision). Currently I target embedded systems, often with no OS or other layers. I've previously developed Windows applications. At home, I run a GNU/Linux system, so I'm not tied to Micros~1.
I get frustrated with Micros~1 too but not everything is their fault.