Hi,Good day,thank you for the quick fix.After applying it successfully,may i ask if the following behavior normal? I am currently using 1809 version of Windows 10.Thank you...
Yes, that's normal for the "settings > update" window to just close on its own because usosvc is disabled. That's why I never disabled usosvc before today. I'll be working on a fix that doesn't make the update window close but to do that takes a lot of time, so for now I'm just adding the fix to disable usosvc. Windows 10 will still work normally otherwise.
Thank you so much for the hotfix, this forced update nonsense from MS is so greasy, I'm truly grateful for your hard work! For those of us who choose to use it, Is it now a good idea to also setup an instance of ServiceTray to keep an eye on usosvc since it's now a known vector for updates that needs to stay down? Thanks again for all your hard work and quick action!
For those of us to whom "coding" is not second nature . . . what is this "Service Tray" and how would it be implemented? And, a big "Thank You" to those responsible for this gem that keeps M$ at bay!
ServiceTray is a free program which is discussed in the readme contained in the root of the Sledgehammer zip. It's a great idea. Basically you set it up to monitor the Windows Update Service to make sure it's not up and running. All the details are in that readme, check it out. Since the usosvc service is now also a culprit and we also want to make sure it's always disabled, it's a nice little tool for a quick visual check and peace of mind.
Installed ServiceTray and am getting these types of notifications after a restart. Does this seem normal or is the update service somehow trying to gain control?
It's seemed pretty normal to me after several years usage to have Service Tray initially trigger several on-off notifications of the state of WUS. I think the important thing is what the stable end state of the service that Service Tray shows. You can always double check with a separate instance of WUB.
Yes it is, and I don't want to remove it, but it's caused more problems in the script than it solves.
Based on timing, the issue I noticed after installing ServiceTray almost appears to have something to do with Sledgehammer's check for WD definition updates at startup/login. I have been running Sledgehammer for many, many months and never had any issues with unwanted updates getting installed. Always been kept at bay. I think the last updates that got installed (using the script and WuMgr) was back in July, so I'm sure Sledgehammer is working perfectly. I'm posting the screenshots taken after the last restart, possible they may offer a clue as to what's happening.