Disable Win10 updates - Has anything really worked?

Still trying to struggle with disabling the WuAuServ service and keep it
disabled to prevent Microsoft from pushing updates onto *my* hardware
running their OS.

What I've tried so far (yeah, this is long as I've tried a lot of
counterattacks) ...

- Disable WuAuServ service. Back in Windows 7, this was sufficient to
lockout any updating (and, no, setting the WU client to "never update"
is a lie as Microsoft has been caught pushing covert updates). In the
service's properties, I set auto-recovery to none (take no action).
In Windows 10, this services gets reenabled by the scheduled tasks
mentioned below, so to keep it disabled means figuring out how
Microsoft is reenabling it.

- Disable the WAASMEDIC (Windows Update Medic Service) service. This
service will reenable the WuAuServ service along with reenabling the
scheduled tasks that you disabled in Task Scheduler (which requires
Trusted Installer privilege to change). This service's auto-recovery
was also set to none (take no action).

- Disable the Scheduled Start event in the
Microsoft\Windows\WindowsUpdate folder in Task Scheduler. The only
job of this scheduled event is to reenable the WuAuServ service.
* Likely you won't be able to disable this event using Task
Scheduler ran under your Windows account. Many "system" events
require Trusted Installer privileges to alter, so I use the ExecTI
tool to load Task Scheduler with the TI security token.

- Disable all events listed under the
\Microsoft\Windows\UpdateOrchestrator folder in Task Scheduler.
Again, I needed ExecTI to give me TI privileges to alter this events
settings.

- Some services have triggers to start them (separate of their startup
config), like when Windows starts or when you login. To see if a
service has a trigger, run:

sc qtriggerinfo serviceName


The service must be enabled to get the info; else, you get an "87"
config error. So, enable the service, query for triggers, disable
them, and then disable the service again. For the WuAuServ service:

sc qtriggerinfo wuauserv

which listed a machine policy and user policy. I have the Home
edition, so no policy editor, plus I'd have to figure out where to
look in the policy editor assuming it is even listed. From what I saw
from "sc triggerinfo" help, seems those policies have to do with
starting the service when Windows starts. I ran the following to
delete those policies:

sc triggerinfo wuauserv delete start/machinepolicy
(config success)
sc triggerinfo wuauserv delete start/userpolicy
(config failed)

The 2nd had an error saying incorrect parameter. Well, "sc
triggerinfo" says "start/userpolicy" is a correct argument. In any
case, a following "sc qtriggerinfo wuauserv" says "not registered for
any start or stop triggers", so hopefully that service won't auto-load
due to any trigger event.

For giggles, I also ran "sc qtriggerinfo waasmedicsvc", but it isn't
configured for any start/stop triggers.

The point of removing these triggers is users noticed that on a
Windows start or after a Defender update that the WuAuServ service got
reenabled. I got rid of the startup trigger, but will have to check
if I need to disable Defender to keep WuAuServ from getting reenabled
(or even if disabling Defender's on-demand scanning is sufficient).

I've noticed the the Backup Scan event under the UpdateOrchestrator
folder got reenabled, so I disabled it again. Today I noticed the
WuAuServ service got reenabled again. That was because the Scheduled
Start event in Task Scheduler got reenabled whose sole purpose is to
reenable the WuAuServ service. Because I there was some lag in
noticing Microsoft had reenabled some scheduled events and reenable
WuAuServ, I also noticed a new "AC Power Download" event under the
UpdateOrchestrator folder in Task Scheduler. This wasn't there a day,
or two, ago. One of the others is new, too, but I didn't memorize the
names of all the events that I saw before. Microsoft is adding more
events trying to keep their auto-updater enabled. The new one that I
noticed has a custom trigger which means it triggers on some
condition, like Windows starting or stopping.

- Something I just tried but haven't had enough elapsed time to know if
it works is a registry edit to disable automated updates. The result
is to query to download (and install) new updates instead of them
downloading in the background and then catching me offguard when they
get installed. Supposedly I can:

* Go to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Win dows.
* Create a new subkey named WindowsUpdate if it doesn't already
exist. Select that key.
* Create another new subkey named AU. Select that key.
* Under the new WindowsUpdate\AU key, create a data item named
AUOptions (DWORD32).
* Set its value to 2 (which means notify for download and notify for
install).
* Restart Windows to effect the registry change.

See: https://github.com/vFense/vFenseAgen...Updates-&-WSUS.

I suspect this is the equivalent to the policy setting available in
gpedit.msc that is available in the Pro edition. I have the Home
edition, so no gpedit.msc. Since all policies are registry entries
(the editor just provides an easier or safer GUI than regedit), most
can be manually entered in the registry. Some are hashed, like
Software Restriction Policies (SRPs), so those you cannot create
manually via registry edits.

One old trick (don't know if it still works) is to claim that my
computer uses a metered connection (whether it does or not).

- However, that also means the BITS service won't work. A background
download would obviate the point of restricting network traffic over
a metered connection. Windows Defender uses BITS to do background
downloads of its updates. There was something else (that I've
forgotten now what it is) that also used BITS. I thought I had just
heard about some anti-virus software that was dropping their
background updater and going to BITS. There are several programs
that use BITS; see:

https://en.wikipedia.org/wiki/Backgr..._that_use_BITS

Yet BITS has been vulnerable and can be used to reintroduce malware
that was supposedly eradicated; see:

https://www.zdnet.com/article/attack...serve-malware/
(dated 2016)
https://www.forbes.com/sites/daveywi.../#5f551b2e6a72
(dated 2019)

Leaving Windows Defender for a 3rd party anti-virus/malware program
would mean I could disable the BITS service since it wouldn't be
needed by Defender anymore and I don't use any other program that
uses BITS ... except for Firefox which I use as a backup web
browser.

Update: I uninstalled the Mozilla Maintenance Service (since I do
want a UAC prompt to verify I want Firefox updated), disabled
BITS, and did an update to Firefox (since there was one
available). The update completed okay (and was definitely not
backgrounded via BITS), so I could disable BITS and not have a
problem with Firefox updates (but have to reenable BITS when I do
a manual update check for Windows).

While I could schedule '"C:\Program files\Windows
defender\MpCmdRun.exe" -SignatureUpdate' to force an update of
Defender rather than rely on it using BITS, that seems by the name
of the argument to be just for signature updates and not when there
are feature or behavior updates (aka program updates) to Defender
itself.

Oops, just realized a metered connection only applies if you are NOT
using a wired Ethernet connection. I'm not going to a slower less
reliable wi-fi connection for the desktop PC by changing from wired to
wireless. So, metered won't help me, anyway. BITS survives, for now.

Another trick I might use is to steal the Task Scheduler folder where
these events are defined (%windir%\System32\Tasks). I already took
ownership and changed permissions (disable inheriting permissions and
apply changes to children) to grant full access to my admin-level
account. I noticed that if I moved those folders elsewhere (instead of
just deleting them) that the events couldn't run. Task Scheduler would
puke out some error about not finding the event. However, I've already
seen Microsoft add more events into these folders in Task Scheduler
which means the folder will get recreated (but unknown if just the new
event gets saved there or if all events get recreated, too).

A last trick I might try is to change the WuAuServ service to run under
the Guest account which won't have the privileges needed to perform the
updating. However, that means that I would have to change the WuAuServ
service's account (to mine) to do a manual update check. I can use a
batch file for that, where sc.exe changes the account for the service.
At that point, I'll also probably have to change permissions on the
USOclient and SIHclient to prevent them from doing any updating. Might
be fruitless if Microsoft somehow creates anew the service definition
and steps on the usoclient.exe and sihclient.exe to ensure it has its
permissions.

In Windows 7, all I had to do was disable the WuAuServ service and it
stayed disabled until I choose to reenable it when I was prepared to do
a manual update check. Geez, Microsoft has gotten really nasty in
Windows 10.

On Sat, 27 Jul 2019 04:24:17 -0500, VanguardLH wrote:

Still trying to struggle with disabling the WuAuServ service and keep it
disabled to prevent Microsoft from pushing updates onto *my* hardware
running their OS.

Personally, I tried _everything_ Paul suggested, even down to booting to
Linux to get at the files which Microsoft specifically made very strange.

In the end, I had to have my machine reimaged twice (even _after_ bringing
it to the local Microsoft store and leaving it there for a few days for the
OS repair).

At this point ... I've given up - unless - something works - for sure.

On 7/27/2019 5:28 AM, Arlen G. Holder wrote:
On Sat, 27 Jul 2019 04:24:17 -0500, VanguardLH wrote:

Still trying to struggle with disabling the WuAuServ service and keep it
disabled to prevent Microsoft from pushing updates onto *my* hardware
running their OS.

Personally, I tried _everything_ Paul suggested, even down to booting to
Linux to get at the files which Microsoft specifically made very strange.

In the end, I had to have my machine reimaged twice (even _after_ bringing
it to the local Microsoft store and leaving it there for a few days for the
OS repair).

At this point ... I've given up - unless - something works - for sure.


Does the Winaero Tweaker work anymore?

I thought it was able to disable WU along with alot of other tweakie stuff.

On Sat, 27 Jul 2019 05:44:47 -0400, DMP wrote:


Does the Winaero Tweaker work anymore?


Yes


I thought it was able to disable WU along with alot of other tweakie stuff.


Yes, it can

On Sat, 27 Jul 2019 07:52:04 -0700, Ken Blake wrote:

I thought it was able to disable WU along with alot of other tweakie stuff.


Yes, it can

I used the WinAero Tweaker - and many other methods - many of which worked
- for a while ...

We could dig up the threads from the past - where I was able to prevent the
Win10 update process for over a year (maybe even two years, as my memory
fails me) - but - eventually - a Microsoft update bricked the boot process
- which is why I brought it to the Microsoft repair center.

Was the bricking the result of tweaking the system - or just some Microsoft
update faux pas? I don't know. It happened twice.

Could be either the update process - or the many tweaks I did to the
system; but, once I stopped extensive tweaks (like trying to eliminate
Cortana instead of just hiding it), the bricking stopped ... we hope.

An update has not bricked my boot process since about January - which is
the longest I've gone after that first bricking by a Micrsosoft update.

What's different?
o I only tweak things manually - I don't use Linux or WinAero anymore.
o Nor do I use Classic Shell anymore - I just tweak manually now.

In summary, the "tweakers" are NOT TESTED by Microsoft, as far as I can
tell, and an update _will_ eventually brick your OS ... if my experience is
any guide - although it could have just been bad luck on my part.

If WinAero still works - that's great - but I - for one - have been burned
too many times - so when I tweak - it's a registry change done manually.

DMP wrote:
On 7/27/2019 5:28 AM, Arlen G. Holder wrote:
On Sat, 27 Jul 2019 04:24:17 -0500, VanguardLH wrote:

Still trying to struggle with disabling the WuAuServ service and keep it
disabled to prevent Microsoft from pushing updates onto *my* hardware
running their OS.

Personally, I tried _everything_ Paul suggested, even down to booting to
Linux to get at the files which Microsoft specifically made very strange.

In the end, I had to have my machine reimaged twice (even _after_
bringing
it to the local Microsoft store and leaving it there for a few days
for the
OS repair).

At this point ... I've given up - unless - something works - for sure.


Does the Winaero Tweaker work anymore?

I thought it was able to disable WU along with alot of other tweakie stuff.

Windows Update service, uses Update Orchestrator (an Enterprise feature?)
as a backup system for Windows Update. In addition to running a service,
it also includes a set of Update Orchestrator scheduled tasks.

They're like tag-team wrestlers - when the refs back is turned,
one of the wrestlers is jumping off the top rope.

In fact, depending on how lucky you are, you will see multiple Command Prompt
windows open soon after boot. They can "flash" if they launch rapidly, but
the command prompt window can stay on the screen for 5-10 seconds in some
cases, and you can see what command they're running.

The purpose of the tag team approach, is if the executables
are still on the machine, to run them "for you".

And this is why Windows Update isn't as simple as it looks any more.
Stopping the service manually in services.msc, achieves nothing.
The service will restart itself.

*******

In the old days, there was a registry entry with values 0..4 .
And one of those values said "disable Windows Update, I will
check for updates manually".

That control no longer works.

The following isn't particularly clever. I did it mainly
to see if the OS had "back doors" for repair. And it does
not try to DISM or SFC for its own gain.

When I fiddled with this on Jan.18,2018, it looked like this.

It's not as easy to do this any more.

https://s13.postimg.cc/jxvwua6c7/pesky_wuaueng.gif

At the time, the Windows Update in Settings wheel, would
present the flat-line juggling balls animation, forever...
The Settings dialog knows it wants to talk to wuauserv,
but wuauserv cannot run.

https://s13.postimg.cc/5rg5z2y1z/wheel_spin_forever.gif

You can see the service launcher is a bit perturbed.
The service didn't terminate... because it never
started in the first place. It's depending on
wuaueng.dll.bak to somehow magically launch
and that's not going to happen.

https://s13.postimg.cc/ggtuqwuav/event_viewer.gif

But doing things this way, leaves the OS "cranky", so
this is hardly a win. You'll have to hammer a few things,
if you want peace and quiet, and that's hardly a good
way to run the OS. (There is a GPEdit policy to shut
off Windows Defender.) But, in lieu of having good
controls, for some, this is the way it has to be.

I have a 16299.125 VM which is frozen that way.
Frozen in time. And being frozen, means there's
actually enough bandwidth in there, that Paul
can do stuff. Amazing... That I would somehow
squeeze some performance out of a VM. Who would
have thought that possible ?

*******

To access a partition from Linux, there are several
things to do.

0) Disable Fast Boot

powercfg /h off

is my favorite way, but isn't really surgical enough
for the job. That's just a setting I use for multiboot,
so there is never "friction" between my OS choices. I
am always in control this way...

1) Administrator Command Prompt

compact /compactOS:Never

This decompresses a lot of System32/WinSXS type stuff.
It removes Reparse Points that Linux does not understand.

If you fail to do this, an attempt to modify files from
Linux gives a bleak "I/O Error" since Linux doesn't know
what a Compression Reparse Point is. Some users will freak
out, thinking their disk is "busted". Well, no, it isn't.
Just a badly chosen error message in Linux, is all.

2) Once in Linux, when it complains it cannot mount the
volume because "$MFTMIRR is corrupt", you can use
ntfsfix to fix it.

3) Now, the partition should mount. Get out your sledge
hammer, and enjoy yourself.

Paul

On 27/07/2019 10:44, DMP wrote:

Does the Winaero Tweaker work anymore?

Don't use any crap to block Windows 10 update. My method works 100% of
the time but idiots here have not been able to implement it because they
are too dense. there is no need to destroy anything on the machine just
to block updates.



I thought it was able to disable WU along with alot of other tweakie
stuff.

No you weren't. It is just in your dead brain.

My new toilet cleaner, who was a pig farmer in California, will be
around very soon to impersonate my posts. Just watch out for them.






--
With over 999 million devices now running Windows 10, customer
satisfaction is higher than any previous version of windows.

On Sat, 27 Jul 2019 12:16:32 -0400, Paul wrote:

To access a partition from Linux, there are several
things to do.

Hi Paul,

You wrote that summary well such that, if I ever try to disable Windows update
again, I'll refer back to this post in the future (which unfortunately is
very poorly archived in the two known archival search-engine locations)
o http://tinyurl.com/alt-comp-os-windows-10
o http://alt.comp.os.windows-10.narkive.com

There's a "trick" (which sucks but it works sometimes) to search the archives:
o http://google.com = wuaueng.dll -site http://alt.comp.os.windows-10.narkive.com

Which results in these URLs of relative import for reference purposes:
o What is this strange new Windows file-system beast (C:\Windows\System32\wuaueng.dll)?
https://alt.comp.os.windows-10.narkive.com/HiXlOMwk/what-is-this-strange-new-windows-file-system-beast-c-windows-system32-wuaueng-dll
o Windows Update in Windows 10: how to disable?
https://alt.comp.os.windows-10.narkive.com/fTykvHa5/windows-update-in-windows-10-how-to-disable
o Disable Win10 updates - Has anything really worked?
https://alt.comp.os.windows-10.narkive.com/5Ew7H7MA/disable-win10-updates-has-anything-really-worked
etc.

I looked up what version "wuauserv" came from, & was surprised it's XP:
https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_components
But I couldn't find in that list anything about the "wuaueng" introduction.

The redundant wuaueng naming convention stands for, apparently:
o Windows Update AutoUpdate Engine (dynamically linked library)
https://www.symantec.com/connect/blogs/cwindowssystem32-files-explained

Here is a list from that site citing other related wuau components:
o wuapi.dll.mui (Windows Update Client API) - Needed by Microsoft Update.
o wuauclt.exe (Windows Update). An auto-update client - Needed by Microsoft Update.
o wuauclt1.exe (Windows Update AutoUpdate Client) - Needed by Microsoft Update.
o wuaucpl.cpl (Automatic Updates Control Panel applet) - Needed by Microsoft Update.
o wuaucpl.cpl (Automatic Updates Control Panel). Automatic Updates Control Panel applet - Needed by Microsoft Update.
o wuaucpl.cpl.mui (Automatic Updates Control Panel) - Needed by Microsoft Update.
o *wuaueng.dll* (Windows Update AutoUpdate Engine) - Needed by Microsoft Update.
o wuaueng.dll.mui (Windows Update Agent) - Needed by Microsoft Update.
o wuaueng1.dll (Windows Update AutoUpdate Engine) - Needed by Microsoft Update.
o wuauserv.dll (Windows Update AutoUpdate Service) - Needed by Microsoft Update. Main Service file for Automatic Updates.
o wucltui.dll (Windows Update Client UI Plugin) - Needed by Microsoft Update.
o wucltui.dll.mui (Windows Update Client UI Plugin) - Needed by Microsoft Update.
o wupdmgr.exe (Windows Update Manager for NT) - Needed by Microsoft Update.
o wups.dll (Windows Update client proxy stub) - Needed by Microsoft Update.
o wups2.dll (Windows Update client proxy stub 2) - Needed by Microsoft Update.
o wuweb.dll (Windows Update Web Control) - Needed by Microsoft Update.

Re-reading the threads from the Win10 ng archives, this stands out:
https://narkive.com/HiXlOMwk.62

These are the known methods (about a year ago) from Paul mostly:
1. Rename wuaueng.dll using a linux boot dvd (or dual boot)
2. Disable Windows Update Service & related Task Scheduler Services
3. Disable Windows Update Service & change the LOA for wuauserv to Guest
4. WUB https://www.sordum.org/9470/windows-update-blocker-v1-0/
5. WIM http://www.majorgeeks.com/files/details/windows_update_minitool.html

Where I'd summarize Paul's comments as:
#1, #2, and #3 methods should work on all Windows 10.
(But #2 might no longer work, based on something I remember Bob_S wrote.)
#4 & #5 may work if they don't do Win10Pro-special stuff in the registry.

Has anything changed from that summary of about a year ago?