This Is now Mostly “Old Hat.”
I have removed all the really old comments about my transition to Windows 10 when it was first offered to a small group of Beta testers, as all that news has gone completely stale. This article will only contain occasional updates regarding new builds, and then only if I experience a major new feature, addition, or crash.
As of January 2017, I have now been a “Windows Insider” for almost 2 years and have installed and tested countless Beta Builds of Windows 10. I must say that I am impressed with the overall quality and usability of the builds, and especially the responsiveness of the MS Engineering team that reads all the Feedback and Forum posts and attempts to respond with fixes and improvements.
The last few builds had a major flaw that caused them to crash on installation on my machine, but now I have loaded Build 15014 and find it to be stable and very cooperative with my ancient (8 year old ) hardware on this spare “test” box.
Apparently, there has been a flurry of failures with NVidia storage drivers and maybe even their video drivers that caused many computers to hang and crash, but whatever bug it was has been squashed by the MS Engineers, and this build reinstalled my NVidia drivers and restored the former speed of my SSD. My opinion about handling the famed “Blue Screen of Death” that I expressed below hasn’t changed much despite the fact that new Insider builds of Windows 10 now show a GREEN Screen of Death instead.
It’s remarkable to me that, despite the well documented decrease of desktop computer users, Microsoft continues to make a good-faith effort to maintain comparability with this user base, and insure that the platform is still supported. They have, for the most part, upheld their promise that if a piece of hardware worked in Windows 7, it will continue to work in Windows 10. And, despite numerous additions and improvements since it came out, Windows 10 actually seems faster and more responsive on my computer now than Windows 7 or earlier builds of “10” were.
UPDATES – December 2016
Well, this update is more of a rant with some new developments regarding the latest “Insider” Edition of Windows 10; Build 14986. Apparently, some changes to the Kernal have reawakened incompatibilities with certain drivers, causing numerous sudden BSOD (Blue Screen Of Death) failures.
Now, I understand that maintaining an operating system with an estimated 50-60 MILLION lines of code is quite a challenge, especially since users want it to run on and with every piece of ancient hardware and maintain compatibility with every piece of software ever written, but it’s not the BSOD’s that disturb me as much as it is the way Windows 10 (and every older version of Windows) handles them.
In the early days of Windows, I forgave the developers for the drastic way Windows handled BSOD’s because I believe I understood the design intent of taking such an immediate, irreversible, and drastic action as to stop the system and display nothing but a big blue DOS screen with the bad news on it. “Your current work is lost, the document you were working on is shredded! We have luckily saved your microprocessor and memory from a complete meltdown, and you should consider yourself fortunate that you can just reboot and start over!”
The BSOD was (is) Windows’ way of preserving the integrity of the “system.” When an errant App, driver, or program starts stomping around in the carefully manicured garden of “reserved” memory, you have to do something drastic. You can’t just allow that to go on. The possibility that this is an attempt at hijacking the machine, or worse creating a thermal runaway exists, so it may just be a real life “Halt and Catch Fire” scenario, which if it actually exists, must, by drastic means, be prevented. (I know, that’s really poor sentence structure, but it’s my post, and I can murder the English language if I want to!)
But, I venture to guess, that 99% of BSOD’s are caused by “innocent” mistakes in the code, and that by now, after 31 years of development, Windows SHOULD be able to execute this damage prevention with a little more grace. I will even concede that, once memory spaces are trampled, continuing operation can only result in further damage, but the least I would like to see is a USER FRIENDLY diagnostic routine that can be run to monitor the inner workings of Windows and reliably report the offending villain to the user. Sure, there are MiniDump reports, and even stack trace apps, but neither are anywhere close to the level of the typical user to benefit from. It takes a separate program to just read a MiniDump and extract ANY usable information from it, and then, most of the time, the MiniDump blames the Kernal for the offense, when, in reality, it was the Kernal trying to run the offending driver that created the traffic jam to begin with.
So here’s my dream. When you have a machine that repeatedly and reliably fails with a BSOD and MiniDump analysis shows that the failure is ALWAYS in exactly the same memory stack and for exactly the same reason, allow a boot mode modification that runs a background trace function that records a realtime log and writes it to the storage media of every driver and function that the processor runs; a super but friendly stack trace, so to speak. Of course, I know that this would drastically slow down the machine, and use gobs of storage, but it could be written to only keep the last (pick a number) instructions, so that the log file isn’t overwhelming. Go ahead and crash with the BSOD, but on reboot, run in the safest of safe modes, and automatically review the log and identify the REAL offending App, Driver, or program that crashed the machine. Allow the user to do a “one click”uninstall if they choose, or set some kind of flag to temporarily block any of that App’s code from running, so the user can get the machine running again if only for test purposes.
I’d happily do without my dot-matrix printer driver for a while until someone sorts out the code and publishes an update.