This Is now Mostly “Old Hat.”
A quick addition regarding my biggest complaints regarding Windows 10 has been added to the top of the article starts on the next page.
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.
Another Quick Rant Regarding Windows 10 – September 2018
Windows 10 has now been firmly cemented into our computer culture, especially as earlier versions of Windows are becoming “unsupported,” and some version of Win 10 has become the accepted norm on most of the remaining and dwindling user base of desktop computers. To its credit, Microsoft has been adding “features” and squashing bugs at a frenetic pace, and for the most part, has kept the releases functional and feature rich. But, with the added features weighing down an already heavily bloated Operating System the problem of CPU usage at startup has resurfaced and is much worse than ever before.
I understand that there are a slew of “housekeeping” tasks that need to be run on boot or wake from sleep, but some of them are unnecessary and burdensome, especially if one is just interested in waking the computer to accomplish a quick task. For many minutes after start, the machine churns the processor at 100% performing functions that could very well be delayed until the machine has had the opportunity to fully boot and settle in to its normal routine. Then, the tasks should be programmed to run on a staggered start, in order of importance, rather than flooding the CPU and memory, en masse.
Also, and easily accessible detailed list of these resource hogs should be created for user review, so that those that the user regards as less important can be sorted out or at least prioritized. As it stands, things like the “User Experience” program, all of the background “Telemetry” (corporate spying) and “Program Compatibility” functions that eat resources, thrash the hard disk and send endless streams of your data back to the Mother Ship (MS), are very difficult to tease out of the background noise, and need to be made easily “optional.” Of course, MS doesn’t want you to be able to turn these off, so that they can monetize your data, but at the cost of kidnapping my CPU cycles, slowing MY machine, and sharing MY data, I find all of this unacceptable.
If you diligently research the necessary switches, settings, and registry modifications that are required to reduce or eliminate these nefarious loads on your system, you will fin that he next major update will reset all of them back to MS “normal” and require hours of finicky tweaking to eliminate once again. MS figures that eventually, you will just skim the user agreement (EULA), click the “Accept” box and let them have their way with you, because it just gets to be too much trouble to keep fixing the problem every time there’s and update.
I urge you to get yourself some quick and easily downloadable tools like “Autoruns” from System Internals, research this problem on Google and take back control of your CPU cycles on startup. Meanwhile, use the User Feedback function of Windows 10 to tell MS that it’s YOUR computer and YOU should have at least some control over what it does on startup.
January 2017 Update
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.