1- Windows restart at a busy time to install updates. 2- Windows include unwanted updates (known bugs in CU which user can't tolerate, feature update and drivers) 3- Windows download the updates when internet quota is limited. For me, pause update + wushowhide.diagcab solves these problems. (works fine in Pro and higher editions)
Addendum to what @Windows_Addict said above: Microsoft forces updates on Windows 10 systems. Although you can set limited delays, MS doesn't let you stop or pick and choose which updates. However, older hardware -- and all hardware eventually will be "older" -- may be broken by a feature update. When you reach that point, you have to (a) have a computer that won't run Windows 10 anymore, (b) buy new hardware, which meets the goal of the Microsoft-Industrial Complex, or (c) control the updates with a third-party tool.
Umm . . . Congratulations, if you haven't experienced one of your computers being deadlined by a Windows 10 feature update. It's not "if" but "when." Just as there are computers that can run Windows XP but can't upgrade to Windows 7 (or Win 98/Me to XP, or Win 7 to 8/8.1, etc.) because the hardware doesn't meet the requirements, there are computers that can't upgrade to the next version of Windows 10 - and each "Feature Update" is an upgrade. But you were joking, right?
oh, sorry, wasn't aware of the Clover Trail CPU issue in 1703 update, but ms blocked the feature update and will provide the security update up to 2023 for those specific CPU's.it seems alright.
There are also many other chipset and driver issues that won't tolerate feature updates. And although MS may supposedly block a feature update for a specific hardware issue, it would only be for the issue that MS acknowledges exists. When it starts affecting you, you'll see all the problems that people are having while you're researching the solution to your own. For example, I personally have three AMD GeForce chipsets that will repeatedly be updated to 1803 when they topped off at 1709. They won't run 1803. So will 1809 work on them? Maybe I'll give it a try some time in case MS fixed the hardware incompatibility, which I doubt. But I need the control to stop FUs. On the other hand, I have an older Toshiba Satellite laptop that wouldn't upgrade from 7 to 8, but I was able to get 10 working on it -- go figure. Still, it won't run higher than 1709.
that's exactly why I use a very old Acer laptop as testing laptop for Windows 10 (installed 2016 LTSB on it as live OS) because no other version/ later build works on it
Well said. Microsoft wants to be Apple with 100% control and big profits with their huge user base. But how long this can go on? Eventually people - even Microsoft sharesholders - will notice (or they will be forced to acknowledge) that this is not sustainable in the long run. All that e-waste (that gets dumped to 3rd world countries without proper handling and recycling) for no real benefit.
Great instructions. You might want to put this into the package itself, to readme.txt or some other file. In the future, as this blocking gets even more dangerous thanks to Microsoft, there could even be some kind of 'offline fix' batch file that could be ready and available in case of BSOD problems?
Good idea. I could make an "emergency recovery" cmd file in the wrapper script folder. Then you'd just have to get to a command prompt in the recovery environment and run it, then it would undo the script changes and reboot into windows. I've never written scripts for the recovery environment so right off hand I'm not sure the easiest way to find what drive your windows installation is on. Maybe someone more knowledgeable in this area could point me in the right direction. But otherwise, I could figure it out, and yes, I'll make this happen.
Not sure if automatic detection of Windows is the best way here, even more in cases a user has installed more than one. Easiest way to run such a script would be to place it in the root of the Windows drive, enter WinPE CMD prompt and find the drive that contains the script. With the knowlegde of the drive letter it would be easiest to start the recovery script with that info as a switch. I.e.: Code: recovery.cmd "d" where 'd' is the drive letter which is then used by the script using %~1 to remove any quotes . EDIT: OK, this doesn't assume a non running Windows where it needs to deliver the recovery script to the machine as first step.
That was my biggest concern. Knowing there can be more than one install, the script wouldn't know which one is the right one. But anyone knowledgeable enough to do multiple installs would know which install is the correct one. That's all I needed to know. Thank you @s1ave77.
isn't that just a matter of a quick edit done by the user when needed? As long as people now what to edit everyone should be able to do that with a little explanation in a txt file
No need to edit when as @s1ave77 said, I could make the recovery script read the user inputted drive letter after the command. So after you find what drive your install is on, then run "recovery.cmd "install drive letter"". So if your borked install is on drive e, then you'd just type Code: recovery.cmd "e" Or I could make the script ask you to enter the drive letter in a menu to automate it. Then when you run the recovery.cmd it asks you for a drive letter, you enter the drive letter and it "edits" the drive letter in the script immediately by using variables.
How about something like that: Assuming the machine isn't booting properly the easiest way would be to use a USB pen with Win setup and the recovery script in root. User only needs to find and start the script. Script checks for Windows folders containing the altered files and offers the drive letters of those asking the user which to repair . When the scripts only resets permissions, no harm should be done if the choice was wrong (in case of multi-boot).
Yes, I could check for the existence of \windows\sytem32 with altered update hijacker file permissions on every drive from c to z and show a list of found installs, then give the user the option to make a selection, that sounds like the best way to go. Possibly even make a second "create_recovery.cmd" script to create a recovery flash drive using windows built-in "create a recovery drive" that auto-copies the "recovery.cmd" to it.