Legacy API Shutdown

Mayayana wrote:

"VanguardLH" wrote

| See my reply where HRESULT is mentioned. 0x8007000 is a prefix upon
| which the return status of the program gets appended. However, that
| appended status isn't shown, so the user only see the incomplete error
| code prefix string. Without the return status from the program added to
| the generic error string, the list of causes is vast as the generic
| string really doesn't point at anything particular.

https://blogs.technet.microsoft.com/...more-friendly/

How does converting from hex to decimal change that the return status
issued by the process was not appened onto the 0x8007000 error prefix
string? Converting 0x8007000 from hex to decimal does not address the
issue that 4 bits are still missing. If the program returned a zero
status (it executed okay) then the error code would've been 0x80070000.
If the program returned 5 then the error code would've been 0x80070005.
If the return code was 11 (in hex), the error would've been 0x80007011.
Without the return code from the program included in the error code, the
error code doesn't identify anything specific about what happened with
that program.

"VanguardLH" wrote

| How does converting from hex to decimal change that the return status
| issued by the process was not appened onto the 0x8007000 error prefix
| string? Converting 0x8007000 from hex to decimal does not address the
| issue that 4 bits are still missing. If the program returned a zero
| status (it executed okay) then the error code would've been 0x80070000.
| If the program returned 5 then the error code would've been 0x80070005.
| If the return code was 11 (in hex), the error would've been 0x80007011.
| Without the return code from the program included in the error code, the
| error code doesn't identify anything specific about what happened with
| that program.

It doesn't work that way. It's not a error
prefix string. It's a 32-bit integer expressed
as hex. The 1st half (big endian low word)
is the category. The 2nd half (big endian
high word) is the error number. It's always
8 places.
For instance, error 100 would be 80070064.
To get the error string you'd do: net helpmsg 100.
If the error were 1000 the value would be
800703E8. And so on.

Why you don't see 8 places, I don't know.
The code probably should be 80070000,
indicating no error.

"Mayayana" wrote:
Why you don't see 8 places, I don't know.
The code probably should be 80070000,
indicating no error.

I suspect the OP made a typo.

The code is strange in that the 8 (high bit set) indicates failure
while the low order zeros indicate success. The 7 is a facility code,
in this case FACILITY_WIN32.

It's as if the routine used is set up to report errors but wasn't
given a number for this one, or an error didn't really occur.

On 22/08/2018 23:25, Mayayana wrote:
"VanguardLH" wrote

| See my reply where HRESULT is mentioned. 0x8007000 is a prefix upon
| which the return status of the program gets appended. However, that
| appended status isn't shown, so the user only see the incomplete error
| code prefix string. Without the return status from the program added to
| the generic error string, the list of causes is vast as the generic
| string really doesn't point at anything particular.

https://blogs.technet.microsoft.com/...more-friendly/



Interesting to know.
But under the General tab was no hex error code. This is what it said:

The process C:\Windows10Upgrade\Windows10UpgraderApp.exe (SERVER) has
initiated the restart of computer SERVER on behalf of user SERVER\"my
name" for the following reason: Legacy API shutdown
Reason Code: 0x80070000
Shut-down Type: restart
Comment: Windows 10 Update Assistant will reboot your device to
complete the update.

Fokke

"Fokke Nauta" wrote

| But under the General tab was no hex error code. This is what it said:
|
| The process C:\Windows10Upgrade\Windows10UpgraderApp.exe (SERVER) has
| initiated the restart of computer SERVER on behalf of user SERVER\"my
| name" for the following reason: Legacy API shutdown
| Reason Code: 0x80070000
| Shut-down Type: restart
| Comment: Windows 10 Update Assistant will reboot your device to
| complete the update.
|

So it was 8 digits. That means no error. As others
have said, it looks like Win10 upgrade was doing it's
thing and something happened to interfere with the
reboot.

On 23/08/2018 13:48, Fokke Nauta wrote:
On 22/08/2018 23:25, Mayayana wrote:
"VanguardLH" wrote

| See my reply where HRESULT is mentioned. 0x8007000 is a prefix upon
| which the return status of the program gets appended. However, that
| appended status isn't shown, so the user only see the incomplete error
| code prefix string. Without the return status from the program
added to
| the generic error string, the list of causes is vast as the generic
| string really doesn't point at anything particular.

https://blogs.technet.microsoft.com/...more-friendly/




Interesting to know.
But under the General tab was no hex error code. This is what it said:

The process C:\Windows10Upgrade\Windows10UpgraderApp.exe (SERVER) has
initiated the restart of computer SERVER on behalf of user SERVER\"my
name" for the following reason: Legacy API shutdown
Reason Code: 0x80070000
Shut-down Type: restart
Comment: Windows 10 Update Assistant will reboot your device to
complete the update.

Fokke


Under the Details tab:

- System
- Provider
[ Name] User32
[ Guid] {b0aa8734-56f7-41cc-b2f4-de228e98b946}
[ EventSourceName] User32

- EventID 1074
[ Qualifiers] 32768

Version 0

Level 4

Task 0

Opcode 0

Keywords 0x8080000000000000

- TimeCreated
[ SystemTime] 2018-08-22T11:28:59.246639400Z

EventRecordID 22853

Correlation

- Execution
[ ProcessID] 736
[ ThreadID] 2564

Channel System

Computer Server

- Security
[ UserID] S-1-5-21-3845614013-1503572683-1216961256-1001

- EventData
param1 C:\Windows10Upgrade\Windows10UpgraderApp.exe (SERVER)
param2 SERVER
param3 Legacy API shutdown
param4 0x80070000
param5 restart
param6 Windows 10 Update Assistant will reboot your device to complete
the update.
param7 SERVER\"my name"

Fokke

On 23/08/2018 12:04, Apd wrote:
"Mayayana" wrote:
Why you don't see 8 places, I don't know.
The code probably should be 80070000,
indicating no error.

I suspect the OP made a typo.

No, I didn't.

The code is strange in that the 8 (high bit set) indicates failure
while the low order zeros indicate success. The 7 is a facility code,
in this case FACILITY_WIN32.

It's as if the routine used is set up to report errors but wasn't
given a number for this one, or an error didn't really occur.

On 22/08/2018 22:33, Paul wrote:
Fokke Nauta wrote:

OK, but it did not restart. It just hung.
Well, Windows... I thought 10 would be OK.

Considering Linux ...

Fokke

I'm recommending you review, in your mind, what
was done in the 24 hours leading up to the event.
*Someone* was playing with icons on the desktop
of that server.

That could only be me. In the weekend I did an upgrade. It ended succesfull.

This event sequence didn't initiate
all on its own. A "human" helped.

Thanks for the compliment :-)

That's what your
event log is telling me.

Were you "futzing" with the server, playing
with the controls ?

No

Did you double click
Windows10UpgraderApp.exe ? It's an icon Microsoft
left on your desktop, on one of the releases.

There's no icon like that.
But as I said, I control the updates manually, and Saturday I let the
system upgrade itself. There were two update files.

If someone clicks that icon, the OS will then
check for any pending OS Upgrades (16299 to 17134).
That's like a "loose cannon", in that a visitor
to your server area, could click that for fun
if they wanted.

On a "server role", normally you do *not* load
desktop components. Since you were using a desktop
OS as a server, that subsystem was already present.
(On servers, there's an option to install a desktop
support package.)

Desktop Support Package?

Microsoft OSes have a limit on
the number of connections a desktop OS will support,
making them sufficient as a SOHO server, but not
enough for anything bigger.

Our server works as a file server and a http webserver, both for the
local LAN only. So it's all going very easy.

On Linux, you can have a server role, and can have
it for free. It gives you an OS installation without
a GUI, and with just a 24x80 "Command Prompt" window
to do all of your operations. If you choose to install
a DE on top of it (because you're "not a real IT guy"),
then in effect you've made a desktop OS out of it again.

Servers are stripped down, to keep them simple, and
prevent complicated situations from arising.

Linux still has auto-update capability, and there will
be times when you cannot get into the package manager,
because Software Updates is running in the background.
This is different than Windows, where you can "race"
the OS on a Windows Update - you can download the
update from catalog.update.microsoft.com and double-click
to install, and if yours finished first, the one that
Windows Update is trying to do will be suspended.
Linux doesn't work quite the same way.

To my knowledge there are hardly any regular updates for Linux systems,
and close to zero for Linux servers.

Normally, maintenance intervals on servers are restricted
to hours where the maintenance will not affect anyone. If the
server needed an upgrade, you might move the storage over
to a second box, while the first box is upgraded. Then
move the stuff back later. In some cases, people do all
of this via virtualization.

Paul

I control the server by RDP. In case there are any updates, it will take
place in the weekend.

Fokke

On 22/08/2018 22:41, VanguardLH wrote:
Fokke Nauta wrote:

OK, but it did not restart. It just hung.
Well, Windows... I thought 10 would be OK.

How long did you wait after the shutdown event?

Hardly a minute.
After it crashed, and its shares were gone, I pushed the power button in
order to switch it off. It didn't, but rebooted. But the server did not
come back. Then I decided to pull the power cord out, waited 10 seconds
and plugged it back in again. Then I started the server.
And this haappened two days.
The update itself took place last Saturday.

A noted in my prior 2nd
reply, some updates seem to take a very long time, like over an hour to
allow the shutdown and then a long time upon the subsequent boot to
finish the updating.


Fokke

On 22/08/2018 22:39, VanguardLH wrote:
Fokke Nauta wrote:

VanguardLH wrote:

Fokke Nauta wrote:

We have a file server, running W10 Pro 64b.
Yesterday and today afternoon the server went offline and didn't come
back. I had to pull the power cord out and in again and boot it up.
Today I checked the event viewer and saw "Legacy API Shutdown", with the
error code 0x8007000. This code brings me nowhere, and searching for
this event brought me to information about Windows servers (2003 etc)
from more than 10 years ago.
Apart from this, updates shouldn't take place between 9.00 and 22.00.
So - what's going on here?

What type of event in Event Viewer? Informational, Warning, or
Critical?

Windows logs - System

That's the category (into which events get grouped). Applications can
even add their own category (so events get recorded under that group).
In the event list itself, there is a column that says what TYPE of event
it was and to which I gave a clue: Information, Warning, or Critical.

Level = Information
Source = User32
Event ID = 1074
Task Category = none

This is a different event ID then the one I mentioned earlier. Perhaps I
didn't check it well enough.

My guess is the shutdown was required, got performed (started), so it is
just an Information[al] event. The event type is one of the columns in
the same list of events where you got the following event ID.

What was the event ID?

98

Well, now I see 1074. Or am I looking to a different event?
Approximately same time, same kind of event ...

http://www.eventid.net/

This is a useful site! Thanks!

cut

Event ID: 1074 Source: User32
SourceUSER32
LevelInformation
Description The process process has initiated the restart of computer
name for the following reason: No title for this reason could be found.
Minor Reason: reason
Shutdown Type: type


When you look back at eventvwr.msc to see the record for the shutdown
event, what source was listed for that event?

Select the event in Event Viewer. Right-click on it. Select Copy -
Details as Text. Then paste in your reply.

cut

Log Name: System
Source: User32
Date: 22/08/2018 13:28:59
Event ID: 1074
Task Category: None
Level: Information
Keywords: Classic
User: SERVER\"my name"
Computer: Server
Description:
The process C:\Windows10Upgrade\Windows10UpgraderApp.exe (SERVER) has
initiated the restart of computer SERVER on behalf of user SERVER\"my
name" for the following reason: Legacy API shutdown
Reason Code: 0x80070000
Shut-down Type: restart
Comment: Windows 10 Update Assistant will reboot your device to
complete the update.
Event Xml:
Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"
System
Provider Name="User32"
Guid="{b0aa8734-56f7-41cc-b2f4-de228e98b946}" EventSourceName="User32" /
EventID Qualifiers="32768"1074/EventID
Version0/Version
Level4/Level
Task0/Task
Opcode0/Opcode
Keywords0x8080000000000000/Keywords
TimeCreated SystemTime="2018-08-22T11:28:59.246639400Z" /
EventRecordID22853/EventRecordID
Correlation /
Execution ProcessID="736" ThreadID="2564" /
ChannelSystem/Channel
ComputerServer/Computer
Security UserID="S-1-5-21-3845614013-1503572683-1216961256-1001" /
/System
EventData
Data Name="param1"C:\Windows10Upgrade\Windows10Upgrade rApp.exe
(SERVER)/Data
Data Name="param2"SERVER/Data
Data Name="param3"Legacy API shutdown/Data
Data Name="param4"0x80070000/Data
Data Name="param5"restart/Data
Data Name="param6"Windows 10 Update Assistant will reboot your
device to complete the update./Data
Data Name="param7"SERVER\Fokke Nauta/Data
/EventData
/Event

Looking more like a backup problem. To get at inuse files, VSC is used
to create a shadow copy of files to put those into a backup.

Every evening at 18.00 a backup takes place by Backup4all.

The only thing I can find is:
The process C:\Windows10Upgrade\Windows10UpgraderApp.exe (SERVER) has
initiated the restart of computer SERVER on behalf of user SERVER\Fokke
Nauta for the following reason: Legacy API shutdown
Reason Code: 0x80070000
Shut-down Type: restart
Comment: Windows 10 Update Assistant will reboot your device to
complete the update.

You claimed there were no Windows updates during the time of the event.

Correct

Well, you actually said no WU from 0900 to 2200.

Correct

Does the Windows
Update history confirm there were no updates during that time? How
about sooner? Maybe an update occured off-hours but was pending a power
cycle (shutdown and then startup).

Could be, but there was no power cycle before windows hung.

Seems the shutdown event was just informational. As to why the computer
hung, that's either because some updates take damn long to complete, a
driver won't disengage, or some running software prevents the shutdown.

The update took place on Saturday afternoon and was succesfull. The
server was then rebooted.

I've seen Windows updates that tell me they are working when I shutdown
the computer myself. In older Windows, I had WU set to "never check"
which also means to never download to cache locally. Yet occasionally I
would see a WU message when shutting down tell me to wait. It could be
over an hour before the shutdown completed. Then, on startup, I'd get
another message saying there was more updating and I'd have to wait
another long interval. I'd have to sometimes give up using my computer
for an hour, or two, just to let the updates complete - that I did not
want! These covert updates occur no matter how you set the WU client in
any version of Windows, often to update the WU client itself. To avoid
the covert updates, and because Microsoft wouldn't honor the "never
check" setting, I disable both the WU (Windows Updates) and BITS
(Background Intelligent Transfer Service) services. Cover updates with
"never check" has been a prolonged problem with Windows. Kill the
services (stop and disable them) to make sure Microsoft doesn't sneak
something in.

Background Intelligent Transfer Service = manual, and is currently not
running. Should I disable that?
Windows Update = automatic (trigger start). Currently not running. I
have set it to manual (trigger start). Or should I disable this one as well?

One hour befo
EventData

updateTitle GDR-DU: LanguageFeatureOnDemand - Windows 10 April 2018
Update for x64-based Systems - (KB4132443) [en-US]
updateGuid {284C63BB-AD07-461B-9C64-C4F9577B30AC}
updateRevisionNumber 203

So there was an update an hour before.

I haven't seen it. And it took place between 9.00 and 22.00, in which
interval updates should not take place.

Even when an update doesn't
mandate a reboot, I do it anyway. I've seen pending file changes cause
problems until they get replaced after a rebooting (the PendingRename
registry key is not empty until after a reboot). Have a mixture of
files can result in problems expecting behavior in a method that has
changed.

How do you know that Windows updates didn't occur between 0900 and 2200?

Because I set in Windows Update the Active Hours from 9.00 to 22.00.
Pretty default, I think.

Was the update event you noted above during active hours configured in
the WU client? If the update occurred outside active hours as
configured, did you run any software that upon its completion will
reboot Windows?

While you have active hours configured locally, and because you mention
this was a server edition,

Well, server edition? It's just W10 pro 64b. The pc actes as a local
file and web server.

did you make sure a policy wasn't getting
pushed (after you login and connect to the domain) to change the WU
active hours config? You can set your local policy but domain policies
get pushed that will override the local settings. All policies are
registry entries, and those can get overwritten by pushed domain
policies or by batch or .reg files used on Windows startup or login (via
login script, startup registry entries, Startup folder, etc).

https://docs.microsoft.com/en-us/win...e/waas-restart

Did you check your server host's time and date? Since active hours
specify a range, that triggers based on the OS clock (not the BIOS or
RTC clock). Make sure Windows has the correct time, even after power
off, power on, and boot.

When I see the time in the right lower corner, is that the BIOS or the
Windows time? But this time is synchronized every hour by the internet.

I haven't checked if there is a reported bug with active hours
configured for the WU client. I mentioned the wrong OS clock as a
possibility why the updates happened when the wall clock indicated a
time during a range that you expected to be active hours.

I don't use active hours. There are no inactive hours on my computer.
I might be using it at ANY time of the day: morning, afternoon, evening,
wee morning hours ... ANYTIME. As I recall, Microsoft extended the
range from 12 to 18 hours for the active hours range. There is no 18
hour range during a 24-hour day where I will never or even occasionally
be using my computer during the other 6 hours.

The only way I found to control when updates are allowed is by disabling
the BITS and WU services. I have a .bat file to enable and start both
the BITS and WU services (for after I prepare, like save a backup image,
and allow and check for updates to apply any) and another .bat file to
stop and disable the BITS and WU services (like after updates have been
applied and I want to prevent any interrupting or covert updates). At
the end of the batch files is a pause so the console window remains
loaded and I can check the status returned by the Service Controller
(sc.exe) command-line program. Hit a key and the window closes. Both
batch files use the sc.exe program to stop/start and disable/enable
services. I guess I could run the batch files with admin privileges in
Task Scheduler: one scheduled event to run WU-enable.bat during
non-active hours (or not bother defining active hours so all hours are
candidate update times), and another scheduled event to run
WU-disable.bat during active times. However, scheduling won't work for
me because I might be using my computer at ANY time. There are no
non-active hours.

I think this is a splendid idea.
Do the BITS and WU services need to be running for an update? And need
to be disabled for the rest of the time in order to prevent the
situation I had?
I'm getting curious to your batch files. Would you mind mailing them to
me? If so, you can use my e-mail address as mentioned
in my posts.

I just have 3 shortcuts in a "Windows Update" folder in my Start menu
that contains shortcuts named "1 - Enable WU", "2 - WU check", and "3 -
Disable WU" (the numerical prefix is just so they sort in that order in
the folder to make sure I run them in that order). I decide when
updates get applied by when I enable and start the services that the WU
client uses, and after applying any updates then I disable those
services to keep Microsoft away from my computer until *I* am ready.


Fokke

cut


The only way I found to control when updates are allowed is by disabling
the BITS and WU services. I have a .bat file to enable and start both
the BITS and WU services (for after I prepare, like save a backup image,
and allow and check for updates to apply any) and another .bat file to
stop and disable the BITS and WU services (like after updates have been
applied and I want to prevent any interrupting or covert updates). At
the end of the batch files is a pause so the console window remains
loaded and I can check the status returned by the Service Controller
(sc.exe) command-line program. Hit a key and the window closes. Both
batch files use the sc.exe program to stop/start and disable/enable
services. I guess I could run the batch files with admin privileges in
Task Scheduler: one scheduled event to run WU-enable.bat during
non-active hours (or not bother defining active hours so all hours are
candidate update times), and another scheduled event to run
WU-disable.bat during active times. However, scheduling won't work for
me because I might be using my computer at ANY time. There are no
non-active hours.

I think this is a splendid idea.
Do the BITS and WU services need to be running for an update? And need
to be disabled for the rest of the time in order to prevent the
situation I had?
I'm getting curious to your batch files. Would you mind mailing them to
me? If so, you can use my e-mail address as mentioned
in my posts.

I have just seen that it's pretty straight forward.
It's a good idea. I'm going to write such batch files as well.
On all our systems I have TCC/LE from JP Software installed, to run
batch files.

I just have 3 shortcuts in a "Windows Update" folder in my Start menu
that contains shortcuts named "1 - Enable WU", "2 - WU check", and "3 -
Disable WU" (the numerical prefix is just so they sort in that order in
the folder to make sure I run them in that order). I decide when
updates get applied by when I enable and start the services that the WU
client uses, and after applying any updates then I disable those
services to keep Microsoft away from my computer until *I* am ready.


Fokke

In article , Fokke Nauta
wrote:

The code probably should be 80070000,
indicating no error.

I suspect the OP made a typo.

No, I didn't.

yes you did. either that or you have *two* different error codes.


In article , Fokke Nauta
wrote:
Today I checked the event viewer and saw "Legacy API Shutdown", with the
error code 0x8007000. This code brings me nowhere, and searching for


In article , Fokke Nauta
wrote:
name" for the following reason: Legacy API shutdown
Reason Code: 0x80070000
Shut-down Type: restart

Fokke Nauta wrote:

The process C:\Windows10Upgrade\Windows10UpgraderApp.exe (SERVER) has
initiated the restart of computer SERVER on behalf of user SERVER\"my
name" for the following reason: Legacy API shutdown
Reason Code: 0x80070000
Shut-down Type: restart
Comment: Windows 10 Update Assistant will reboot your device to
complete the update.

0x8007000 now becomes 0x80070000
an added digit ----------------^

The return status was zero which means the function succeeded.
Something requested the OS to shutdown and the request succeeded. So
that event is not the cause of the problem. It's just an informational
event telling you when the shutdown got initiated due to a request that
the OS got to do the shutdown.

The Windows10UpgraderApp.exe process complete some action, like
installing updates that required a reboot to complete the updates. Then
it asked the OS for a restart and the OS complied.

That event isn't the cause of the problem of why your host wouldn't
complete the shutdown (you said it crashed or hung). Could be whatever
update(s) got installed (well, partially installed since more of the
install will get completed during the shutdown and likely some more on
the subsequent startup).

On 23/08/2018 18:48, VanguardLH wrote:
Fokke Nauta wrote:

The process C:\Windows10Upgrade\Windows10UpgraderApp.exe (SERVER) has
initiated the restart of computer SERVER on behalf of user SERVER\"my
name" for the following reason: Legacy API shutdown
Reason Code: 0x80070000
Shut-down Type: restart
Comment: Windows 10 Update Assistant will reboot your device to
complete the update.

0x8007000 now becomes 0x80070000
an added digit ----------------^

The return status was zero which means the function succeeded.
Something requested the OS to shutdown and the request succeeded. So
that event is not the cause of the problem. It's just an informational
event telling you when the shutdown got initiated due to a request that
the OS got to do the shutdown.

The event is the first one in a long range leading towards the hang of
the pc.

The Windows10UpgraderApp.exe process complete some action, like
installing updates that required a reboot to complete the updates. Then
it asked the OS for a restart and the OS complied.

That event isn't the cause of the problem of why your host wouldn't
complete the shutdown (you said it crashed or hung).

It hung

Could be whatever
update(s) got installed (well, partially installed since more of the
install will get completed during the shutdown and likely some more on
the subsequent startup).


I feel more towards your approach. I will write a batch script, which
will disable the BITS and WU services, and which will enable and start
them on each first Monday of the month, when I check for and perform
updates on all the systems here and when I make my monthly backups on
external hard disks. Afterwards they will be disabled again.

Fokke

Fokke Nauta wrote:

Log Name: System
Source: User32
Date: 22/08/2018 13:28:59
Event ID: 1074
Task Category: None
Level: Information
Keywords: Classic
User: SERVER\"my name"
Computer: Server
Description:
The process C:\Windows10Upgrade\Windows10UpgraderApp.exe (SERVER) has
initiated the restart of computer SERVER on behalf of user SERVER\"my
name" for the following reason: Legacy API shutdown
Reason Code: 0x80070000
Shut-down Type: restart
Comment: Windows 10 Update Assistant will reboot your device to
complete the update.

The other subthreads have adequately addressed that this event is
informational only to log that a process requested a shutdown of
Windows. The OS did what it was told to do - shutdown.

The WU client may reboot Windows to complete the installation of
updates, like to get new files to replace currently inuse (locked) files
or to make sure new drivers are the ones loaded in the current instance
of the OS. Drivers normally load on startup of Windows (so updating
them doesn't effect the one currently active) although there is such a
thing as dynamically loaded drivers; see:

https://docs.microsoft.com/en-us/win...iver-is-loaded

Background Intelligent Transfer Service = manual,

Manual startup mode means the service is callable. That is, a caller
process can request the service which will start the service. It
remains an idle process until called.

Any program can use BITS. For example, Windows Defender uses it to get
its signature updates. So far, I've only seen Microsoft using BITS
despite they offer it to any program that wants to use its API. Seems
everyone wants to use their own downloader.

I disable BITS because it is primarily used by the WU client to retrieve
the update downloads in the background without significantly impacting
the responsiveness of the OS or of network bandwidth. Disabling the WU
service might be all that is needed, but I don't need BITS for anything
else.

running. Should I disable that? Windows Update = automatic (trigger
start). Currently not running. I have set it to manual (trigger
start). Or should I disable this one as well?

Auto mode means it starts. Services can also be configured to start
upon a trigger rather than run continuously when not needed. I'm
enabling and starting wuauserv because I'll be using it immediately, so
I don't need wuauserv waiting for any specific event to trigger it to
start running.

https://www.coretechnologies.com/pro...Editor/sc.html

Back in earlier versions of Windows, I had set WU to "never update" and
yet several times I encountered the ghost updates also noted by other
users where upon shutdown I would see an "updating" message and then on
the subsequent boot another "updating" message. I was rebooting for my
own cause and these ghost updates interferred with using my computer.
Microsoft snuck in an update despite I configure the WU client to not
allow any. Since Microsoft has proven untrustworthy in completely
disabling all updating with the "never update" setting, I had to disable
any services involved in that process. With Microsoft's rude behavior
in Windows 10 regarding updates, it became even more imperative to my
uniterrupted usage of *my* computer to prevent Microsoft from changing
the state of my computer at their whim.

I keep WU services disabled. When I decide to get updates, and after
saving a backup image (system restore sucks and is not reliable), I
enable the WU services and check for updates. After the updates have
completed, I do a reboot even if not mandated and then disable the WU
services again. WU is off until I decide it is on.

When I see the time in the right lower corner, is that the BIOS or the
Windows time? But this time is synchronized every hour by the internet.

The clock shown by Windows is the OS clock, not the RTC (real-time
clock) in the hardware. The RTC is used to track time when the computer
is off hence the need for a CMOS battery to power the RTC. Actually the
RTC runs all the time either powered by the 3V standby when the computer
is on or off (the PSU still provides 5V standby to the power-on logic on
the mobo which is cut down to 3V to power the RTC chip). During boot,
the OS reads the RTC to get the time; however, thereafter the OS uses
its own clock to track time.

The RTC uses a crystal to keep time. The OS clock uses software. If
the OS gets heavily loaded, the time will drift hence the need to
periodically synchronize the OS clock with a time server using NTP
(which could be a server host in your network that gets its time from
another NTP server or your host connects to a 2nd-tier NTP server).
That's the point of the Windows Time service; however, some users prefer
a more easily configurable "atomic clock" utility (I use Socke****ch).
The OS clock has a GUI where you can, for example, define which NTP
server to use (if not pushed by domain policy) but you can add more or
different ones under the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Curr entVersion\DateTime\Servers

Microsoft's NTP server is, by default, the one configured for use by
Windows. That means it is the most heavily used NTP server (for that
OS). Servers can too busy to accept additional requests, so your host
might have to retry many times. Another choice is NIST's servers which
thankfully Microsoft already included. I decided to add my own from the
local university's NTP server. There are other registry settings on
when to poll the NTP server and other config options. Rather than delve
into the registry, I use Socke****ch to do the time sync.

As I recall, Windows Time will sync about once per week or upon Windows
startup. Microsoft figures users power down at the end of the day and
power up upon returning to the computer. I leave mine running and
logged in 24x7, so the time sync on startup won't happen. I don't want
to wait a week for the Windows Time service to sync the OS clock.

https://www.wikihow.com/Change-the-T...val-in-Windows
That user shows the registry under ControlSet001. That may NOT be the
current Control config! Rather than dig into the registry to see which
config is the current one, just always edit under the CurrentControlSet
tree in the registry.

The default is 604800 seconds (or 1 week). Since I use Socke****ch, I
didn't bother changing the SpecialPollInterval to something much less
than a week, like 3600 seconds (1 hour).

The OS clock won't drift much in just an hour, and that's what I set
Socke****ch for its sync interval. The OS clock is a software routine
and will drift over time, especially when the computer is heavily loaded
and why a time sync is needed. The OS only gets the RTC's value at boot
time. PCs are poor timekeepers hence the need to re-sync them. Even
the RTC's value will drift (but not nearly as much as the OS clock).
When the OS does a time sync, the OS writes the updated time back to the
RTC so it also stays synchronized. No point in having the OS keep
synchronizing if upon boot the OS reads an old and out of date value
from the RTC chip. There are online articles on real-time clock
programming but I've never bothered to learn out how to write to the RTC
chip. I suspect the CMOS table gets updated rather than directly
writing to the RTC chip but I'm not sure.

Users don't realize that tokens during SSL/TLS handshaking are
timestamped. If the token is too old (I've never found out how old is
too old but my guess is 5 minutes) then the token is considered as
expired and certificate validation fails. If the OS clock is too far
off, you may not be able to connect via SSL/TLS to another host.

I think this is a splendid idea. Do the BITS and WU services need to
be running for an update?

Yep. wuauserv (Windows Update) is obviously needed to retrieve the
updates. I suspect bits (Background Intelligent Transfer Service) is
used by wuauserv and would fail if bits wasn't usable to wuauserv. I
know both work together, so I disable and enable them together.

And need to be disabled for the rest of the time in order to prevent
the situation I had?

That's what I do to ensure Microsoft doesn't sneak in any ghost updates
and to let me decide when to do the updates.

I'm getting curious to your batch files.

I wish I could remember but there is a 3rd service involved in Windows
Updates. I would disable it if I could remember it just to be thorough
in killing off WU until I decide to enable it. For now, my batch files
contain the following. I might've added ERRORLEVEL check but that
doesn't work with service starts and stops. sc would return a status
code when it issues the request (to stop or start), not when the service
actually starts or stops. I could add loops to keep checking if the
service stopped or started as requested with a timeout but that's too
much work for something that has worked okay each time I use these batch
files. I just added a pause for me to see if the commands worked okay.

Batch file: WU-enable.bat (needed before checking for updates)

@echo off
cls

echo __________________________________________________ __________
echo.
echo Enable BITS (Background Intelligent Transfer Service) ...
sc.exe config BITS start= demand
echo.

echo __________________________________________________ __________
echo.
echo Enable Windows Update service to Manual startup mode ...
sc.exe config wuauserv start= delayed-auto
echo Start Windows Update service ...
sc.exe start wuauserv
echo.

echo __________________________________________________ __________
echo.
echo Hit any key to end ...
pause nul
.................................................. .....................

Batch file: WU-disable.bat (kill WU to prevent updates)

echo off
cls

echo __________________________________________________ __________
echo.
echo Stop BITS (Background Intelligent Transfer Service) ...
sc.exe stop BITS
echo Disable BITS ...
sc.exe config BITS start= disabled
echo.

echo __________________________________________________ __________
echo.
echo Stop Windows Update service ...
sc.exe stop wuauserv
echo Disable Windows Update service ...
sc.exe config wuauserv start= disabled
echo.

echo __________________________________________________ __________
echo.
echo Hit any key to end ...
pause nul

I run these batches manually using shortcuts to the .bat files. You
could add events in Task Scheduler (ran under admin privs) to allow the
services to be enabled only at those times you want auto updates to
occur. Since wuauserv is running only when I choose, I can leave it in
loaded (auto) waiting for a request from the WU client - because
wuauserv won't be running after the updates complete, so it doesn't
matter if it is disabled or set to auto (triggered). Actually I could
probably change from Automatic (Delayed) to just Automatic since delayed
is only to help boot-time performance of Windows, and I'm not running
these batch files during boot-time. Since the OS is already booted,
Automatic (Delayed) is effectively the same as Automatic. For when I
use the batch files, delayed-auto and auto would be the same.
Similarly, I haven't bothered to edit the registry setting for the delay
(HKLM\SYSTEM\CurrentControlSet\services\AutoStartD elay, doesn't exist
until you create it). I think the delay is 120 seconds after the last
Automatic service has been requested to start (not when all Automatic
services have actually started). I don't have sc.exe define triggers
because I do want wuauserv to run for whatever calls it (which is when I
run the WU client).

If Paul wants to comment on my batch files, I'll be happy to see what he
has to say for improvement. Maybe he'll remember what is that 3rd
service employed by Windows Update that I could add; however, since that
service is only under Windows 10, I'd be using the batch files on
Windows 7, too, with the result that sc would report an error of no such
service. I probably could just disable/enable the wuauserv service to
keep Microsoft from changing the state of my computer at their whim.