"Paul" wrote in message news
Bob_S wrote:


"Paul" wrote in message news
Evgenii Sputnik wrote:
Hello.

How do you *completely* disable Windows Update in Windows 10? I have only
32 GB SSD, so my options are limited.


Evgenii



How about

rename wuaueng.dll wuaueng.dll.bak

By doing that, you're not deleting the hard link between
WinSXS and System32 file names.

Later, if you want to turn it back on, it would be

rename wuaueng.dll.bak wuaueng.dll

I think I tested that in a VM at some point, and the
Windows Update "spinning balls" just spin forever.

The wuaueng.dll, may be the code file for the wuauserv
service which is one of fifteen services in a certain SVCHOST.
Thanks to Microsoft picking different names at every level
for stuff, it's pretty hard to trace which file does what.
You can try Sysinternals Process Explorer, run that as
Administrator, and probe the svchost for details. That's if you
want to satisfy your curiosity as to whether that's
the right target to attack or not. The definition of the
service in Services panel, may also hold some clues.

I just rename these things from Linux. As there are
less permissions to worry about there. What Linux lacks,
is handling of reparse points, so some things now cannot
be touched from there. The other thing Linux doesn't like,
is if the C: drive is "hibernated" at the time you try to
access that partition. Ideally you want Fast Boot turned
off, before using Linux on it. Fast Boot can be interpreted
as Hibernation.

mv wuaueng.dll wuaueng.dll.bak

You can try using the Win10 installer DVD or a
Win10 emergency boot CD, and using Command Prompt
from there, to do the rename if you want. That's another
path to doing it. Permissions still work in such an
environment. It's quite possible you're administrator
when doing it that way...

I don't recommend *deleting* files. Rename them for this
sort of work. If you delete that file, you're going to need
to learn how to make hard links, or you'll need to use
sfc /scannow to repair it.

Turning off "Windows Update" service does not stop it.
USOSVC will use a scheduled task to turn it back on.
If the file is renamed, there is less chance of that happening.

Microsoft some day *could* auto-repair the whole freaking
OS, so it's not a given that we will have this option in the
future. If they wanted to, they could harden the OS to the
point that only disconnecting the network cable would work.

You don't want to damage any more than that, as things like
BITS could be used for updating Apps from the App Store, or
supporting some Powershell calls. You only want to try
for the actual Windows Update service, for least damage.
I don't even know if .msu files (downloaded from
catalog.update.microsoft.com() will work, once you
stick a fork in that file. It's pretty hard to come up
with a file level operation that is side-effect free.

Paul

Paul,

Curious as to why you recommend renaming wuaueng.dll and not just go into
services.msc and Disable WindowsUpdate service. This works for Win10 Home
and Win10 Pro versions.

We had a real sh*t storm over the weekend at a clients location and 13 out
of 20 systems got borked because of the recent updates. Those that
weren't were ones I already gotten to and Paused/Delayed updates until mid
Feb (Win10 Pro systems). I was able to recover each of the affected
systems with a quick restore point recovery and then I've *temporarily*
disabled windows update service. I've rebooted the systems to see if
Win10 would somehow magically turn the service back on and so far it
hasn't.

Tried updating and I get a spinning arrow, then it times out saying there
was an error, try later. So the disabling appears to be working fine.

Note that Windows Defender will still get definition updates even though
WindowsUpdate service is disabled. There is some disagreement on that
point and even MS says ii gets updates via the update service. But.... I
disabled windows update service two days ago and just verified the
definition updates on several systems are current as of Jan 30 and Windows
Defender shows it happy with everything being up to date.

Bob S.


How do we know what capabilities the USOSVC has ? It's
possible for a scheduled task to go around switching stuff
on if it wants, on the next reboot.

As I indicated, even my method isn't foolproof, when the
day comes that Microsoft makes a "self-repairing OS". And they
could do that quite easily. They have all the tools to put-back
things that users remove or rename.

One thing Windows is missing, is an "immutable" bit, which is
used on other OSes for laying a trap for OS stuff. For example,
storing a file where a folder of the same name normally goes,
then setting the immutable bit on it. That has been used to
foil the installation of unwanted things.

Renaming files takes away the starting material. Like removing
kindling from a fireplace, leaving firebugs with only clinkers
to use to start a fire.

But the trick with removing starting materials, is to not
remove anything which is shared by more than one process.
Which is why I didn't give instructions to bludgeon qmgr
(BITS etc). As there may be more than one thing you value,
which relies on BITS for downloads.
Paul

Paul,

This link may help: http://servicedefaults.com/10/usosvc/
Yes, it says it can can but doesn't appear to be the case on the systems
I've disabled the update service.
Also, look under Computer Management Task Scheduler Library Microsoft
Windows UpdateOrchestrator

This is the task that starts the Windows Update scan. After doing some
trial and error testing in the past, it looks as though this is what allows
Windows Defender definitions to be updated even though the
WindowsUpdateService is disabled.

Look under Computer Management Task Scheduler Library Microsoft
Windows Windows Update and look at the sih (server-initiated healing)
task. The following is the description copied from that window: "This daily
task launches the SIH client (server-initiated healing) to detect and fix
system components that are vital to automatic updating of Windows and
Microsoft software installed on the machine. This task can go online,
evaluate applicability of healing actions, download necessary payloads to
execute the actions, and execute healing actions."

So if the WindowsUpdateService is Disabled, the "sih" task doesn't run. I'm
reading "healing actions" as being patches and updates and to restart
services required if needed as long as they are not disabled - and that is
what I'm seeing.

If the update service is Stopped and you reboot, the service will be
restarted. Update service can be set to Manual (default for Win10) or Auto
or AutoDelayed and the update service will be running when you next boot the
system. Not when it's set to disabled though. So far on all the systems I
have disabled the "WindowsUpdateService" on both Win10 Pro and Home systems,
I have not had an OS update and that’s after rebooting over several days and
rechecking, the service remained disabled.

Trying to trace thru what depends on what is difficult and can be confusing
as to what actually happens when Win10 encounters an error - such as when a
file is missing and stops a process from running. Looking in the various
logs in the Event Viewer offers some insight. For instance, no errors are
logged with the update service disabled and I manually trigger Win10 to do
an update status.

But... I haven't tested what the results would be by renaming the
(mutable...;-) wuaueng.dll and then looking thru the Event logs. Not saying
doing that is bad method to stop updates, just what else does it affect or
not allow to happen? I haven't tested it whereas I feel confident from my
somewhat limited testing that disabling the update service provides the
desired outcome but still allows for definition updates. For my situation
where the delay and pause feature in the Win10 update is not always
available (depends on version and build), this was the cleanest method I've
found.

Your point on having an immutable bit is a good one but if malware can
change the attributes of even hidden, system files - would having that "bit"
really do any good? My Linux knowledge is minimal but I'm comparing the
immutable bit attribute in Linux with taking ownership of a file or folder
in windows. They seem to be the same thing.

Bob S.