ubuysa
The BSOD Doctor
I think that is the fundamental disagreement between us. There should be nothing special about system upgrades i.e, going from 1709 to 1803. As far as Windows is concerned you'll be installing an update like any other, with changes to binary blobs, configuration files and other data. All of which must be reversible cleanly.
Ah, now I see where you're coming from.
If you think back to Windows XP, Vista, 7, and 8 going from one to the other was clearly an upgrade, for one thing you usually had to pay for it. I forget now when it first became possible to 'upgrade in place' and install a new version of Windows from the exiting version, keeping your installed third party programs (I think it was Vista), but it's never worked well for everyone and for decades the wise have been recommending a clean install for an upgrade to a new version.
With Windows 10 Microsoft changed the way Windows was delivered, introducing the concept of 'Windows as a service'. This, I believe, was the start of a process to make Windows effectively free, Microsoft would then make money from the apps and services that ran on it. This is why, once you have a Windows 10 license, future versions can be had for free. That the upgrades to Windows 10 are new versions is undeniable; they each have a different version number for example (1511, 1607, 1703, 1709, 1803) and even different names (Anniversary, Creator's, Fall Creator's, April 2018), they each bring new functionality to the OS, and each new version can be clean installed.
This is very different to the standard update process where fixes are being supplied to an existing version, but which don't change the version number. All updates should be installed, there is no good reason not to.
The main reason I suspect why upgrading in place is such a lottery is that so many people (and especially businesses) are running software developed for Windows XP (or Vista or 7) on the basis that it's still working so why change? However, over the intervening years there have been huge strides in the services the OS can offer and how it manages the applications and the hardware, in addition the hardware has grown in leaps and bounds. There are new hardware services; in memory management, in symmetric multiprocessing, in bus speeds (and type), in new CPU instructions, the change from 32-bit to 64-bit, and a host of others. Windows has changed to support and exploit these new hardware features and changes and to deliver faster and improved system and application performance and management, as well as new user interfaces and user functionality. This all has to be done with an eye to these 'legacy' (mostly 32-bit) applications to ensure (where possible) that they will continue to run unmodified - and that's a much bigger challenge than you might imagine.
On top of all that is the way in which many legacy applications were written. Those (possibly like the anti-virus you mention later) often use 'hooks' directly in to (possibly) undocumented (but fairly well known) components of the OS, the development of standard APIs for all user code is a relatively recent development. Where drivers are concerned it's an even bigger problem because drivers run in kernel mode so an incompatibility there can have catastrophic consequences. Older drivers may not have been quite as elegantly written as today's drivers must be, again potentially using undocumented features of the OS, and yet customers expect Windows to continue to support all legacy hardware as well as legacy software.
In this respect Windows has been a victim of its own phenomenal success, so much program code and legacy hardware is still out there, and Microsoft have no idea how much or of what type. I'm quite certain that an upgrade in place on a system running only modern hardware and modern software works very well, the problems come when the upgrade in place process meets software, drivers, or older hardware that it knows nothing about. Quite how the upgrade process deals with these I have no idea, but garbage in garbage out still holds true today. This is why a clean install of an upgrade is always a wise move.
The fact that Microsoft lets user upgrade to a new feature release but you chose not to do so indicates that you do not trust that Microsoft can provide updates to a system that won't break it. There is no technical guarantee that a normal Windows update will not break the system any less than a Windows upgrade. The risk increases exponentially typically by the amount of code changes i.e., the small updates have less, but not zero risk.
It is an unfortunate fact that Microsoft have continued with the (known to be problematic) upgrade in place process. The problem for them of course is that users don't want to have to manage their PC, they just want it to work, so a mechanism that lets them upgrade and keep everything they had is attractive. The trouble is that it runs into the legacy issues I mentioned above. On top of that, users who have used tune-up tools, registry cleaners and the like, or those who follow some of the bad advice on the Internet, or who mess when they don't really know what they're doing, may well have a 'damaged' OS even though it still appears to function - an upgrade in place on a system that is already in trouble is likely to result in problems.
It's an even bigger problem that they have chosen to use the Windows Update process to deliver upgrades as well, though I suspect this is all part of the 'Windows as a service' ethos, because it confuses the normal update process (which must be done) with the upgrade process (which is better done as a clean install).
I've already given you an example (devicecensus.exe) of how an update will break the system, even from a clean state. I do not use third-party tuning software or the likes, yet a clean Windows installation followed by installing the latest updates broke this.
And I've already given you several examples (right back to Windows XP) where my system has never been broken by a clean install. I did spend some time yesterday trying to remember how many Windows updates I've had issues with over all these years and it can't be more than three or four, and none of them was serious or unmanageable. I have never ever had an issue after clean installing any version of Windows (including all versions of Windows 10).
Another example, although I didn't directly experience this: one of the updates in January 2018 in an attempt to mitigate the Spectre/Meltdown issue rendered many systems unbootable. It was due to a 3rd-party antivirus software. Microsoft subsequently introduced a patch that will prevent the system from ever receiving this fix until you set a registry entry. This article might be relevant: https://www.zdnet.com/article/windo...check-if-your-av-is-blocking-microsoft-patch/.
You make my point for me here. The root cause was not Windows, Microsoft, nor the update process. The fault was in a third party anti-virus product - and yet you blame Microsoft!
Indeed, this was due to a third-party software but I want to *heavily* emphasise that it happens because Windows does not have a proper package/dependency management system. All changes to the system (whether they come from Windows update/upgrades, drivers or installing/running 3rd-party software) are permanent and some of them are irreversible. With a package manager you'll be informed of when/how an update might introduce incompatibilities e.g., due to a system file having been replaced with an unexpected version by more than 1 packages.
Wrong. It happens because legacy software developers were nowhere near as 'elegant' as they are today. OS 'hooks' were a regular feature of lots of legacy system-type software (like security packages) and even user mode code didn't always follow the guidelines. Today for example you cannot get a driver installed into Windows 10 unless it's digitally signed by Microsoft, and that's to help eliminate the earlier more cavalier approach to writing Windows software. You don't need a 'package manager' if all software uses only the published APIs.
The reason I keep bringing up Linux is because most Linux distros are package-managed and downgrading will bring the system back to the previous state cleanly. With Windows & Mac OS you cannot be certain that downgrading will do the same. I have moved back to Windows after 13 years of using Linux due to the lack of native software that I need so I'm fully aware of its limitations and am prepared to deal with other disadvantages of using Windows (namely security & stability).
I get it that you like Linux. Good for you. But talking about Linux here is like me asking you how to best peel an apple and you telling me to eat an orange instead.
I hope I've made myself clear that I choose to disallow interim Windows updates completely because I want to avoid both the hassle of the occasional breakages (hours of investigation) and the complete reinstallation of the system every 6-18 months (that typically takes me at least 1 week).
It takes me less than a day to clean install a new version of Windows 10 and have all my third party software and configurations installed and done. I simply don't recognise the hassle of which you talk. If you're doing an upgrade in place then that's probably unwise, a clean install each time there is a new version of Windows 10 is much more reliable. And you completely miss the point with your dangerous advice to disable updates, the way to avoid issues is to manage your PC/laptop properly, advising people to disable updates which (no matter what you think of the EULA) is illegal under the license terms, undocumented (in Home versions) and unwise, is not a solution it's a workaround - it addresses the symptoms and not the cause.
Last edited: