What is this strange new Windows file-system beast (C:\Windows\System32\wuaueng.dll)?

Ragnusen Ultred wrote:
Am Thu, 22 Mar 2018 19:23:59 -0400, schrieb Paul:

But that's the whole purpose of doing this as a move
or a rename in the first place.

If you restore the correct file name, the service
will start properly and it will start doing updates.

The file is hard linked to a file in WinSXS. Renaming
the file is a "safe" way to neuter it. Restoring the
original name, makes it work again.

Thanks Paul.
I have turned off the update pause.
Settings Windows Update Advanced Options Pause = off

I see the following when I go to the Windows update setting.
http://i.cubeupload.com/ee3ykG.jpg

It's Windows update error (0x80080005)
https://answers.microsoft.com/en-us/...d-83fcb80e8f2f


The natural question will be how I know if it works, where I'll just
wait a few days to see if the current system updates. I just went to
check the version, but it won't let me see the version in that page.

When I press on "View installed update history", it hangs forever.
Hmmmmm...... in fact, almost nothing works on that screen anymore.
Oh well. I can't tell you what update I'm on, but it's very recent as my
pause period had previously expired a few days ago, so, time will tell.

Oh, I found another way.
Settings System About Windows Specifications
Edition = WIndows 10 Pro
Version = 1709
OS Build = 16299.248
http://i.cubeupload.com/FDy2Bg.jpg

I have a system frozen at 16299.125 and it hasn't complained.

Yeah, the Windows Update history doesn't work. But the "winver"
should still work.

The reason I tried that method, is I got tired of all the "whack
a mole" methods, that don't duplicate the ease of control offered
in Windows 7. I realize that everything in Windows, is interconnected
with other stuff, for the express purpose of making changes like
that "impractical". Just think of the "horror" if the OS was modular.
Or if you could actually change something... permanently.

Paul

Bob_S wrote:
Here's something you should read:

https://answers.microsoft.com/en-us/...3-4fd04ef9db84


Not that this could ever happen to you but before you do what is not
exactly considered a good practice, be prepared for the results.

And then read this:

https://support.microsoft.com/en-us/...ection-feature


Changing a protected file isn't really a good idea. You could have
disabled the Windows Update service in Services.msc as a simpler method.

You could use a search tool like Everything (http://voidtools.com) as an
example and search for wuaueng.dll and see how many versions there are
on your system and you will find they most likely have different size
and dates.

Disabling services doesn't work, when other services have
been designed to turn them back on. USOSVC and the associated
entries in Task Scheduler have been designed to keep Windows Update
running, and frustrate users. USOSVC was originally created for
Enterprise applications, and is only being "tested" on home users.

*******

Grab your copy of 16299.309, and try stopping SearchIndexer (Windows search).
Try disabling the three recovery stages, by setting them to Do Nothing.
What do you notice ? You can't stop Search Indexer because
something keeps restarting it! This is why we use "big hammers"
for **** in Windows 10. Because they work. This behavior has gotten
worse with time. With a bit of work, I used to be able to stop
the Search Indexer. The last time I tried, I couldn't get it to
stay stopped.

WFP doesn't work, if you make changes to the system from Linux.
WFP works fine for the intended purpose of preventing
changes while the OS runs.

To find the doppelganger of wuaueng.dll in WinSXS, use hashdeep
to hash the entire C: partition. Find the line in the output
file for System32\wuaueng.dll and note the hash. Then, do a
Find in Notepad, and spot the second instance of that hash value.
That will be the matching hard-linked file. You can then do
Properties on it, and compare version numbers and so on if
you like. If you delete both of those files from the file
system, then it (and its data clusters) would be... gone.

The NFI utility from the Win2K era, shows the two filenames
for the same set of clusters. But the designers of NFI never
suspected that anyone would ever use hard-linking as a feature,
and that's why they don't display the actual filenames of a
hard-linked file.

File 1338418
\Windows\System32\wuaueng.dll
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident) === An entry for the System32 name
$FILE_NAME (resident) === An entry for the WinSXS name
$DATA (nonresident)
$DATA WofCompressedData (nonresident)
logical sectors 3119232-3122463 (0x2f9880-0x2fa51f)
$REPARSE_POINT (resident)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

Paul

Am Fri, 23 Mar 2018 00:11:18 -0400, schrieb Paul:

I have a system frozen at 16299.125 and it hasn't complained.

Yeah, the Windows Update history doesn't work. But the "winver"
should still work.

The reason I tried that method, is I got tired of all the "whack
a mole" methods, that don't duplicate the ease of control offered
in Windows 7. I realize that everything in Windows, is interconnected
with other stuff, for the express purpose of making changes like
that "impractical". Just think of the "horror" if the OS was modular.
Or if you could actually change something... permanently.

Hi Paul,

Thanks for letting me know you're frozen at 16299.125 where I'll presume
you used the same method I did (given your screenshots) of dual booting to
Linux and then just renaming the system32 wuaueng.dll file.

Thanks for letting us all know that, while one of the three update checks
doesn't work, the other two work fine:
1. Windows Settings Update and Security Windows Update (fails)
http://i.cubeupload.com/m0kZT1.jpg
2. Windows Settings System About Windows Specifications (works)
http://i.cubeupload.com/vRpgbL.jpg
3. command prompt winver (works)
http://i.cubeupload.com/y7SQNO.jpg

In effect, we're both doing a "smoke test" for the team, which is good as
experiments always differ, even if a little bit accidental, and where
others will benefit from our efforts when searching for how to disable
Windows update in a future tribal-knowledge record search:
http://tinyurl.com/alt-comp-os-windows-10

How long do you think we have to wait to prove Windows no longer updates?

BTW, my "plan", such as it is, is to update when I feel like it, so I'd
like to ask you how you plan on updating. I can see two basic ways of
updating when I feel like it.
A. Download & burn future Win10 ISO & update from /that/ ISO file, or,
B. Simply move wuaueng.dll.bak back & let Windows do the update

What method do you plan on using when you feel like updating Windows 10?

Ragnusen Ultred wrote:

In effect, we're both doing a "smoke test" for the team

What I'm noticing, is the willingness of Microsoft to
change NTFS, without changing the version number on it.

That's why I investigated your observation, because it's
another example of "bad practice".

It's OK to modify a "defacto standard", if you tell
people you're doing it! Not telling people is a bad idea.

*******

"Fixing" your problem is easy. If you succeeded in using
the rename method and the file is actually renamed, use

sfc /scannow

If, on the other hand, you deleted both the System32 file
and the WinSXS file, you would need to find the

dism ... /restorehealth ...

command and fix WinSXS first, then run the sfc /scannow
right after that.

Those are perfectly acceptable ways of repairing
damage of that sort.

Paul

Am Fri, 23 Mar 2018 13:06:24 -0400, schrieb Paul:

What I'm noticing, is the willingness of Microsoft to
change NTFS, without changing the version number on it.

I'm glad you're on this, because you, alone, found out more than the rest
of us did, on both the Linux and Windows newsgroups.

So on behalf of the entire two sets of tribes, I thank you for your
diligent effort.

That's why I investigated your observation, because it's
another example of "bad practice".

I appreciate that you investigated my observation because I had expected
more answers of the sort ("it's just a dll silly").

Luckily, most people took the question seriously, which is how it was made.
I noticed the anomoly - but I didn't have the skills you have to bear it to
fruition.

Lord help us, you don't know how refreshing it is to deal with the adults
here on this Windows (and Linux) newsgroup, when you realize what I have to
deal with on interfacing with the Apple newsgroups.

Example here - but don't read it unless you want to cry once you realize
how /different/ the average Apple poster is from the average Windows or
Linux poser on Usenet:
http://tinyurl.com/comp-sys-mac-system
http://tinyurl.com/comp-sys-mac-apps

comp.sys.mac.apps & comp.sys.mac.system
Can a Mac edit an iOS file over WiFi without iTunes existing on the Mac?
https://groups.google.com/d/msg/comp.sys.mac.apps/meGWUcgR8Gs/E5xHMW4PAwAJ

It's OK to modify a "defacto standard", if you tell
people you're doing it! Not telling people is a bad idea.

I don't know how such things are communicated, but I will agree with your
observation since it seems all the Linux variants are also blindsided by
this change, which seems to have occurred as recently as February 2018.

Given that the Linux variants of NTFS drivers are almost all blindsided by
this change in NTFS, I would agree with your observation that it's a
unilateral change by Microsoft.

At least the evidence seems to point in that direction.

"Fixing" your problem is easy. If you succeeded in using
the rename method and the file is actually renamed, use

sfc /scannow

First, I may have to be clear that I never used the "rename" function of
either Windows or Linux. I used the "move". So just to be clear, when I say
in this thread I 'renamed' the file, I actually ran the "move/mv" command.

Following your advice, on Windows, just now, I opened an admin command
window and went into the C:\Windows\System32 directory to run that command.

If, on the other hand, you deleted both the System32 file
and the WinSXS file, you would need to find the

dism ... /restorehealth ...

command and fix WinSXS first, then run the sfc /scannow
right after that.

Those are perfectly acceptable ways of repairing
damage of that sort.

Thanks for that repair technique which I will archive in my apnote logs so
that I have it available for future use (and which is archived here for all
to benefit from):
http://tinyurl.com/alt-comp-os-windows-10

Am Fri, 23 Mar 2018 12:45:20 -0700, schrieb Ragnusen Ultred:

"Fixing" your problem is easy. If you succeeded in using
the rename method and the file is actually renamed, use

sfc /scannow

First, I may have to be clear that I never used the "rename" function of
either Windows or Linux. I used the "move". So just to be clear, when I say
in this thread I 'renamed' the file, I actually ran the "move/mv" command.

Following your advice, on Windows, just now, I opened an admin command
window and went into the C:\Windows\System32 directory to run that command.

Ooops. As I always test all feasible suggestions, I forgot to post the
results from the suggested sfc /scannow.

http://i.cubeupload.com/pPEOsA.jpg

Yikes! Look at what happened!

How the heck did that happen?

Did the "scannow" do that?

Paul wrote:

What I'm noticing, is the willingness of Microsoft to
change NTFS, without changing the version number on it.

That is a little worrying, because I have often used a bootable USB
stick with gparted linux, e.g. to resize boot partitions.

Now if they're monkeying around with the on-disk filesystem metadata,
especially without giving 3rd party tools a version flag to check,
there's a worry about ending up with a knackered install, potentially
only discovered long after the resizing was done ...

Ragnusen Ultred wrote:

http://i.cubeupload.com/pPEOsA.jpg

Yikes! Look at what happened!
How the heck did that happen?
Did the "scannow" do that?

You do know the whole purpose of sfc is to replace missing/corrupted files?

Andy Burns wrote:
Ragnusen Ultred wrote:

http://i.cubeupload.com/pPEOsA.jpg

Yikes! Look at what happened!
How the heck did that happen?
Did the "scannow" do that?

You do know the whole purpose of sfc is to replace missing/corrupted files?

If you think Ragnusen is surprised now, wait until he
runs nfi.exe and finds the file entry now has three filenames
in it :-)

It's going to be like this. Three things hard-linked together.

File 1338418
\Windows\System32\wuaueng.dll
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident) === An entry for the System32 name wuaueng.dll
$FILE_NAME (resident) === An entry for the System32 name wuaueng.dll.bak
$FILE_NAME (resident) === An entry for the WinSXS name
$DATA (nonresident)
$DATA WofCompressedData (nonresident)
logical sectors 3119232-3122463 (0x2f9880-0x2fa51f)
$REPARSE_POINT (resident)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

There may be two files in the directory, but their clusters
of data will be one and the same. By using sfc /scannow, the side effect
result is that wuaueng.dll and wuaueng.dll.bak are all part of the
same file. You can delete either of those depending on desired result
(as long as Linux will let you).

Just a guess,
Paul

Am Fri, 23 Mar 2018 17:16:15 -0400, schrieb Paul:

You do know the whole purpose of sfc is to replace missing/corrupted files?

If you think Ragnusen is surprised now, wait until he
runs nfi.exe and finds the file entry now has three filenames
in it :-)

I admit, both Paul and Andy, that I /am/ thoroughly confused.

Somehow, my Windows update is working again besides.
http://i.cubeupload.com/bAECFs.jpg

Paul ... before I go through the Linux dual-boot move again, can you just
suggest to me exactly what you think I should do to turn it off again now
that there are multiple "things" (I still don't know exactly what they
really are)?
http://i.cubeupload.com/gzjdra.jpg

Thanks!

Ragnusen Ultred wrote:
Am Fri, 23 Mar 2018 17:16:15 -0400, schrieb Paul:

You do know the whole purpose of sfc is to replace missing/corrupted
files?

If you think Ragnusen is surprised now, wait until he
runs nfi.exe and finds the file entry now has three filenames
in it :-)

I admit, both Paul and Andy, that I /am/ thoroughly confused.

Somehow, my Windows update is working again besides.
http://i.cubeupload.com/bAECFs.jpg

Paul ... before I go through the Linux dual-boot move again, can you just
suggest to me exactly what you think I should do to turn it off again now
that there are multiple "things" (I still don't know exactly what they
really are)?
http://i.cubeupload.com/gzjdra.jpg

Thanks!

You haven't had enough "fun" yet ?

You could delete the wuaueng.dll entry, and the
..bak will remain for some later time.

$FILE_NAME (resident) === An entry for the System32 name wuaueng.dll
$FILE_NAME (resident) === An entry for the System32 name wuaueng.dll.bak
$FILE_NAME (resident) === An entry for the WinSXS name

You can get nfi.exe and review the entry for that file.

https://web.archive.org/web/20150329...us/oem3sr2.zip

The nfi.exe should be run from an Administrator Command Prompt.

You can give it the exact file name to check.

nfi C:\Windows\System32\wuaueng.dll

And then you'll probably see the three filename entries in the
one $MFT entry. Deleting C:\Windows\System32\wuaueng.dll would
leave the same kind of file entry, only with two remaining entries.

$FILE_NAME (resident) === An entry for the System32 name wuaueng.dll.bak
$FILE_NAME (resident) === An entry for the WinSXS name

(The nfi.exe utility doesn't display the alternate names, so we can
only use indirect means to figure out which files are the same ones.)

The "sfc /scannow" command handles the hard-linking of the WinSXS file
that never got deleted or modified, back into the System32 folder. If you don't
want to use, or keep around, the wuaueng.dll.bak, you don't have to,
as "sfc /scannow" takes

$FILE_NAME (resident) === An entry for the WinSXS name

and added the wuaueng.dll to the same entry in the $MFT.

$FILE_NAME (resident) === An entry for the System32 name wuaueng.dll
$FILE_NAME (resident) === An entry for the WinSXS name

The .bak file was an attempt to use Linux and file renaming, to achieve the same
ends without needing the time taken by "sfc /scannow".

Paul

"Paul" wrote in message news

Bob_S wrote:
Here's something you should read:

https://answers.microsoft.com/en-us/...3-4fd04ef9db84
Not that this could ever happen to you but before you do what is not
exactly considered a good practice, be prepared for the results.

And then read this:

https://support.microsoft.com/en-us/...ection-feature
Changing a protected file isn't really a good idea. You could have
disabled the Windows Update service in Services.msc as a simpler method.

You could use a search tool like Everything (http://voidtools.com) as an
example and search for wuaueng.dll and see how many versions there are on
your system and you will find they most likely have different size and
dates.

Disabling services doesn't work, when other services have
been designed to turn them back on. USOSVC and the associated
entries in Task Scheduler have been designed to keep Windows Update
running, and frustrate users. USOSVC was originally created for
Enterprise applications, and is only being "tested" on home users.

*******

Grab your copy of 16299.309, and try stopping SearchIndexer (Windows
search).
Try disabling the three recovery stages, by setting them to Do Nothing.
What do you notice ? You can't stop Search Indexer because
something keeps restarting it! This is why we use "big hammers"
for **** in Windows 10. Because they work. This behavior has gotten
worse with time. With a bit of work, I used to be able to stop
the Search Indexer. The last time I tried, I couldn't get it to
stay stopped.

WFP doesn't work, if you make changes to the system from Linux.
WFP works fine for the intended purpose of preventing
changes while the OS runs.

To find the doppelganger of wuaueng.dll in WinSXS, use hashdeep
to hash the entire C: partition. Find the line in the output
file for System32\wuaueng.dll and note the hash. Then, do a
Find in Notepad, and spot the second instance of that hash value.
That will be the matching hard-linked file. You can then do
Properties on it, and compare version numbers and so on if
you like. If you delete both of those files from the file
system, then it (and its data clusters) would be... gone.

The NFI utility from the Win2K era, shows the two filenames
for the same set of clusters. But the designers of NFI never
suspected that anyone would ever use hard-linking as a feature,
and that's why they don't display the actual filenames of a
hard-linked file.

File 1338418
\Windows\System32\wuaueng.dll
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident) === An entry for the System32 name
$FILE_NAME (resident) === An entry for the WinSXS name
$DATA (nonresident)
$DATA WofCompressedData (nonresident)
logical sectors 3119232-3122463 (0x2f9880-0x2fa51f)
$REPARSE_POINT (resident)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

Paul


Paul,

Turning off the service is still a better way. As you may recall about a
month or two ago I made a post about turning off the service and disabling
the scheduled task. That has been circumvented fairly recently.

Another method I found in the tech forums is that turning off the service
*and* changing the Log On account for wuauserv works. I didn't mention that
fact in my original post above (my bad) but I was just trying to let others
know, there's a simpler way and it works.

I have this method installed on a test bed here and I just turned the
service back on so I can test the build you mentioned 16299.309 and then
I'll reapply the "fix" below and retest. The method of disabling the
service and changing the Log On account for the service has been working.

Here's the way to do it:

1. Stop the Windows Update service
2. Set it to Disabled
3. Select the Log On tab on that same window and click the button for "This
account:" and then enter .\Guest (period backslash Guest) and make
sure the password is blank. Apply.
4. Acknowledge the message that .\Gust has been assigned to the logon
credentials.

That stops the service from starting because the account to start it has
been changed. Now when you try to manually force an update you will get a
message in the Windows Update status window that "There were some problems
installing updates, ....etc.." When it also tries to Auto Update, an error
message will be logged in the system logs and that lets you know it's
working if you want to look in the logs.

To reset this so windows updates again, change the Startup type back to
Auto, go to the Log On tab and select the button for Local System account,
Apply and then start the service. The update service is back to normal.

Try it - you'll like it and it's a way safer and easier way then applying
some Linux tricks to circumvent a protected file.

Update: My test system just finished updating and it's rebooting and
installing. As soon as it's done I'll apply the above to turn off the
update and see what happens. We know it stopped the latest update from
downloading because I had to re-enable the service to get it. Waiting......

Okay my test system is up and running and I'm manually checking for updates
and it says I'm up to date as of 8:26pm.
Performed the steps above to disable the service and rebooted. Tried to
force a manual update and get the error message noted above.
Did a cold start and tried another manual update - same error message.
Another warm start, again tried to do a manual update, same error message.

My OS build is 16299.334, Win10 Pro x64 ver 1709

So its working and only 4 steps.
--
Bob S.

Paul wrote:
Ragnusen Ultred wrote:
Are any of the Windows experts here aware of what strange new things
Microsoft did to either symbolic links, junctions, or compression with
respect to this file on Windows 10?
C:\Windows\System32\wuaueng.dll --- this is a strange beast indeed!

In a recent thread, Paul kindly suggested renaming a certain file to
prevent Windows update, where Windows won't let you rename the file so
Paul's suggestion was to rename it in Linux, which seems to have worked,
but with the strangest errors I've seen in such a simple task:
http://i.cubeupload.com/1ji0MX.jpg

Note the "input/output error" & "unsupported reparse point" warnings.

The Linux newsgroup and the net seems to think these are /new/ errors,
due
to Microsoft changing something secretly in NTFS, such that Microsoft
either made the file compressed in a strange new way...
"On some computers (those which are powerful enough) Windows 10
compresses the system files, and a new type of reparse point has
been defined for triggering the decompression (see
http://jp-andre.pagesperso-orange.fr...ns.html#other). Since
ntfs-3g-2016.2.22AR.1, reparse points trigger plugins, and a
plugin for decompressing Windows 10 system files has been
developed". https://bugzilla.redhat.com/show_bug.cgi?id=1377049

Or, that Microsoft made some strange new symbolic link type...
"Reparse points are a way of triggering some specific processing for
accessing files, and the most usual ones are for redirecting to
another file (which ntfs-3g emulates as a symbolic link).
"Reparse point types which are not supported by ntfs-3g are shown
as "unsupported reparse point".
https://bugzilla.redhat.com/show_bug.cgi?id=1377049

There's not much more detail on this, other than what's in the
alt.os.linux
thread on what these new errors mean:
Have you ever seen "unsupported reparse point" warnings in ls output?
https://groups.google.com/forum/#!to...ux/3XyLpV-Za9o
So, I'm just asking if any of you Windows experts are aware of what
strange
new things Microsoft did to either symbolic links, junctions, or
compression with respect to this file on Windows 10?
C:\Windows\System32\wuaueng.dll --- this is a strange beast indeed!

That was a good catch on the Linux-side theory.

Here's the dump for the 16299.309 file system. It shows
how they're abusing a compression declaration.

It was done in the 2018-02 Cumulative.

wuaueng.dll
Size 2,784,256 bytes
Size on disk 1,654,784 bytes

Created Feb.17,2018 === corresponds to 2018-02 Cumulative.
Modified Feb. 9,2018
Accessed Feb.17,2018

File 1338418
\Windows\System32\wuaueng.dll
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
$DATA WofCompressedData (nonresident) ===
logical sectors 3119232-3122463 (0x2f9880-0x2fa51f)
$REPARSE_POINT (resident) ===
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

And here is an example file from a 16299.125 install before the changes.

\Windows\System32\wuauclt.exe
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 2305160-2305239 (0x232c88-0x232cd7)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

So that's what was done.

*******

First hit in a search.

https://www.swiftforensics.com/2016/...indows-10.html


Enjoy,
Paul

I decided to look into WOFCompression, and what I learned is:

1) The WOF stands for Windows Overlay Filesystem.
It's how they can implement this flavor of new compression,
without adding to the NTFS standard. Basically, yet another
abuse of reparse points for fun and profit. The overlay is like
a filter layer added to the file system, that notices the Reparse point,
and uncompresses the "fake" file underneath to recover the "real" data.

This stuff was apparently used in Windows 8.1 and some
people were seeing it while debugging AV malware scan problems.

2) There's a tool that applies the policy.
The purpose of the tool, was probably intended for 32GB tablets,
not for my desktop system. My guess is, the .309 update applied
this policy, before the 5000+ files in the Cumulative got installed.

From an Administrator Command Prompt

compact.exe /compactos:query === find the current setting.
Is my OS compacted ???

compact.exe /compactos:never === change the policy to Never

What I don't know at this point, is whether this
actually "reverts" all the damage done. It will likely,
gradually, one Cumulative or System Upgrade after
another, put the files back in the original (unbuggered)
state.

Once in the unbuggered state, we'll be allowed to do a few things
from Linux again.

If you're going to use this setting of "Never", you'd want to
apply this and test it, before the next OS upgrade comes in.
So all the files in your System folder will get repaired.

To test this on my .309 system, I'm going to need to do a
a backup first. That will take time...

A person who owns a tablet, might not want to change this
policy. Or maybe they're even blocked from changing this
policy. Someone with a desktop using a hard drive, there's
not really a good excuse for Microsoft to be turning this
on. If you own an SSD, will saving 500MB of file space make
a difference to that 256GB SSD you bought ? Probably not.

Anyway, I'm off to test...

Paul

Am Fri, 23 Mar 2018 21:45:58 -0400, schrieb Paul:

What I don't know at this point, is whether this
actually "reverts" all the damage done.

Taking one for the team, I ran a smoke test when I saw this.
http://i.cubeupload.com/8iksPa.jpg
*****
Microsoft Windows [Version 10.0.16299.248]
(c) 2017 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32compact.exe /compactos:query
The system is in the Compact state. It will remain in this state unless an
administrator changes it.

C:\WINDOWS\system32compact.exe /compactos:never
Uncompressing OS binaries -
*****

It is currently chugging away ... with 507GB free on the primary HDD...
http://i.cubeupload.com/wUQzaV.jpg

Am Fri, 23 Mar 2018 20:38:32 -0400, schrieb Bob_S:

My OS build is 16299.334, Win10 Pro x64 ver 1709

I just want to ask Bob_S one question about that version, which is
unrelated to turning off Windows update methods.

My Windows X64 1709 version, via the "automatic" update mechanism, is
16299.248 while yours is, apparently, 16299.334

What I don't understand is why mine isn't yours since it auto updated
today?

Are you using a beta version?
Or am I behind the times?