The latest is just these few changes done to 2.6.0v9. It only provides a little more info during the MS-DEFCON part.
is version 2.5.5 compatible with 1903 ? what's the CONS of this wrapper script if any ? and what will be new in the next version that doesn't exist in the current one ?? is current version of the wrapper script enough for blocking windows updates and preventing them from re-running without the user knowing ?? or is wub.exe alone enough for this mission ?
1) Yes 2) It causes a) sfc errors because of locked system files and folders, and b) event viewer spam because all the update hijackers are being blocked from running. This is reversible with the uninstall script. 3) Info about changes from 2.5.5 to 2.6.0 here. 4) Yes. 2.5.5 works fine, but 2.6.0 is more refined and better for a multi-user environment. 2.6.0 also has better Windows Update Assistant handling, among other things. 5) No. If wub.exe worked by itself, there would be no need for disabling system files with this script, and my life would be a lot easier. wub v1.1 attempted to make up for wub 1.0's shortcomings by disabling services, but that doesn't work either. So the only use I've found for wub.exe is in this script. Windows Update Assistant doesn't care if the update service is disabled or not. Microsoft has figured out how to force you to update, and I've figure out how to undo what they did and allow you to update only when you have time.
first I would like to thank you so much for all these answers and details, it really helps me understand better. so what you are saying is that windows will re-enable update service even if wub is protecting its settings, even if you make it check and disable the service on every windows startup, and even if you remove all related scheduled tasks and everything ?? this means it's a useless tool for windows 10 .? since this script of yours does affect system files, I think this is not encouraging but what is the situation now with v2.6, does it still cause sfc errors ? what are your recommendation of other tools regarding the same task of blocking windows updates ? I can't imagine no other tool is efficient at all !!
can you make like a mini script that do the minimum mandatory things to block updates without touching system files ?
Between protected system services (including windows update components) and some protected tasks, it can get a bit complex.
Windows can't re-enable wuauserv when you disable it with wub (well, it can sometimes after a CU, solved with Wub_task). But wub by itself isn't enough to stop forced updates, so yes, it's useless by itself. Update hijackers can install updates without wuauserv running. That's why the script exists, to disable all the b.s. update hijackers so you can update on your schedule. My script is the only manual update solution that disables system files, so if you don't like that, you can literally choose any other available update control solution. Yes, every version of this script will always cause sfc errors until you uninstall it, due to the nature of how it works. I only use this script, so I have no recommendations on other solutions. I never said other solutions weren't efficient. It's just that I know of no other method that I trust to block updates until I'm ready to update. If I could, I would. The completely useless and unecessary system files and folders disabled by the script (which is what causes sfc errors) are: EOSNotify.exe WaaSMedic.exe WaasMedicSvc.dll WaaSMedicPS.dll WaaSAssessment.dll UsoClient.exe SIHClient.exe MusNotificationUx.exe MusNotification.exe osrss.dll %ProgramFiles%\rempl %systemroot%\UpdateAssistant %systemroot%\UpdateAssistantV2 %systemdrive%\Windows10Upgrade All of that is what forces updates. This garbage is what all the update-forcing tasks try to run. Do you need any of that? I don't. Do I care about sfc errors? No I don't because I know what's causing them. No harm is done to the system and I don't see why it's a big deal. The sfc errors are caused because the system can't re-enable the unwanted system files and folders, which is exactly the behavior I want. And the event viewer spam is cause by Windows 10 having a fit trying to force updates but it can't. Again, exactly the behavior I want. I disable some update tasks too, but that's really unnecessary since what the tasks try to run is disabled. I just do it as a little extra helping hand that might come in handy someday. I understand your concern about the "sledgehammer" tactics this script uses. If you don't feel comfortable with it, there are plenty of other update control solutions around for you to try. Good luck.
of course I like the script, I don't care about any sfc errors either, but some previous version caused BSOD or something right ? I'm sure I will use this script, I like the sledgehammer concept, that't the only thing that actually works with microsoft manipulations but what do you mean by update hijackers ? and is this present in previous versions of windows like the seven ?
Version 2.5.6 that I pulled from the face of the planet disabled upfc.exe which caused bsod, gsod, whatever, on 1803, and I made a recovery script to fix that and to avoid any future problems that might possibly be caused by the script. That's never happened before, and hopefully it'll never happen again. The recovery script is included in v2.6.0. I don't know when update hijackers started, but they were in Windows 7 GWX at least (Click the X if you don't want to update to Windows 10, updates anyway). I skipped 8 and 8.1. All I know is that 10 is infested with overkill processes that force updates, and I killed all of it. What I mean by update hijackers, is anything that forces you to update without your permission. When that happens, I've been hijacked.
Hi, sorry for the late response. First, AFAIK, the BSOD problem with upfc.exe was in the 1803 (17134) build after a certain CU. About the things we talked about (locked vs. unlocked controls in WuMgr), I'm more then happy to wait for 2.6.0. No need to provide a patched 2.5.5, I can do that by myself. It's just not that comfortable like running the installer and done, anymore.
Thanks. 1803. I'll try to remember that. I'm working on the installer now. I'd like to include all language translations for Wumt and WuMgr if anyone has those. I'm going to have to pick a name, like, today. 2.6.0 will be released before Monday (April 29, 2019), because after Monday my free time may be more limited than it has been for a while. 2.6.0 won't have the new wub.exe open source replacement or the expert and other modes for WuMgr. Those changes will be in 2.6.1. I don't want to wait another month to release this.
@pf100 The replacement i proposed for wub.exe has an issue : after reboot it's not possible to reactivate the wuauserv service. I'm working on a correction.