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

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!

On 3/21/2018 7:42 PM, 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!


Following this thread it seems like it would take less time to let
Windows automatically update, than the time spent trying to get around
the updating system. Since MS seems to block every attempt to get
around the updating system it will be a constant battle to keep the
update from happening.

Most of the updates are done in less than a half an hour, How much time
are you spending per update to by pass the system?




--
2018: The year we learn to play the great game of Euchre

In article news
Following this thread it seems like it would take less time to let
Windows automatically update, than the time spent trying to get around
the updating system. Since MS seems to block every attempt to get
around the updating system it will be a constant battle to keep the
update from happening.

Most of the updates are done in less than a half an hour, How much time
are you spending per update to by pass the system?

Hi Keith,

All your objections are valid, I agree.

However, the question is really WHAT is going on.

The question is for someone who wants to UNDERSTAND what Windows is doing.

It matters not whether we wish to actually DO what Paul suggested, which is
to rename a certain file which reputedly disables Windows update.

The underlying question is borne from the fact that I don't UNDERSTAND what
on earth is different about this "thing" (I can't even call it a "file"):
C:\Windows\System32\wuaueng.dll === this is not a file, per se

What is this "thing"?
Is it a file?
Is it a symbolic link?
Is it a strangely compressed file?
Is it a virtual file?
Is it an assemblage of Microsoft magic

This is really just a question for someone who understands Windows, and not
a question about disabling Windows update.

What is this thing which acts so differently with respect to permissions
and ability to rename it than all the other files on Windows?
C:\Windows\System32\wuaueng.dll

"Ragnusen Ultred" wrote in message news

In article news
Following this thread it seems like it would take less time to let
Windows automatically update, than the time spent trying to get around
the updating system. Since MS seems to block every attempt to get
around the updating system it will be a constant battle to keep the
update from happening.

Most of the updates are done in less than a half an hour, How much time
are you spending per update to by pass the system?

Hi Keith,

All your objections are valid, I agree.

However, the question is really WHAT is going on.

The question is for someone who wants to UNDERSTAND what Windows is doing.

It matters not whether we wish to actually DO what Paul suggested, which is
to rename a certain file which reputedly disables Windows update.

The underlying question is borne from the fact that I don't UNDERSTAND what
on earth is different about this "thing" (I can't even call it a "file"):
C:\Windows\System32\wuaueng.dll === this is not a file, per se

What is this "thing"?
Is it a file?
Is it a symbolic link?
Is it a strangely compressed file?
Is it a virtual file?
Is it an assemblage of Microsoft magic

This is really just a question for someone who understands Windows, and not
a question about disabling Windows update.

What is this thing which acts so differently with respect to permissions
and ability to rename it than all the other files on Windows?
C:\Windows\System32\wuaueng.dll

https://support.microsoft.com/en-us/.../what-is-a-dll

--


Bob S.

In article news
https://support.microsoft.com/en-us/.../what-is-a-dll

Hi Bob_S,

It's fair enough that you initially thought that this thing is a "dll"
because, in name only, it "looks" to the human eye like a DLL.

If you've never interacted with it, you'd "think" it was simply a dll.
But it's not.

The fact is that it doesn't act like a DLL on Windows, nor when Linux
mounts it, when you simply try to move it, as Paul had suggested.

The moment you try to rename it, then you realize it's a "thing", much more
so than just a mere dll.

In fact, on Linux, we're making progress in figuring out what this "thing"
is, where it seems to be a secretly performed de-duping (which is the word
used in the descriptions), or in some instances it's a "junction point",
where in others it's a "reparse point".

But, whatever it is, it's not merely a dll.

Here are some references from the Linux question on the matter:
Have you ever seen "unsupported reparse point" warnings in ls output?
https://groups.google.com/forum/#!topic/alt.os.linux/3XyLpV-Za9o

=== cut here for linux snippet on the matter of the strange "thing" ===
https://bugzilla.redhat.com/show_bug.cgi?id=1377049
"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".

Also...
"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".

These hits indicate I'm not the only one who is getting this warning,
where, for example, nobody really knows what's going on since these issues
are all unresolved:

https://unix.stackexchange.com/quest...-reparse-point

https://superuser.com/questions/1270...-partition-und
https://ubuntuforums.org/archive/ind...t-1583075.html

https://www.linuxquestions.org/quest...-rsync-834760/

This hazarded a guess what these strange things a

https://serverfault.com/questions/74...-reparse-point
"These are probably de-duped files.
They are implemented with junctions on disk and the file system driver
handles reassembly. I doubt you will find a Linux tool that can deal
with them. And other Windows utilities for junctions won't understand
them because they were designed for regular junctions, not de-dupe
junctions."

This one isn't exactly the same warning, but is similar:

https://kb.datto.com/hc/en-us/articl...Restore-a-File
"These error messages can be caused when the volume you are
restoring has data deduplication enabled. The volume will
back up correctly, but you will be unable to use File Restore
to restore deduplicated data."

In summary, I guess I found a "bug" or maybe, more charitably, a lack of
functionality on Ubuntu 17.10 which doesn't seem to "completely" understand
a mounted Windows file system.

Is that your take also?
=== cut here for linux snippet on the matter of the strange "thing" ===

Can someone explain what went on in Linux when I followed Paul's advice?
http://i.cubeupload.com/1ji0MX.jpg

Here's a post from Paul in the Windows thread, so that Paul doesn't have to
reproduce his information here...

https://postimg.org/image/9hhiawabh/
https://postimg.org/image/71fowjkdp/
https://postimg.org/image/u2wa2cwwt/

From Paul...

A reparse point, is a file system customization point.

It would be pretty hard for any Linux developer to "keep up" with that.
While one flavor of reparse point, a "Junction point", is a standard
construct (enough for Sysinternals.com to write a program for it), others
can be created at the drop of a hat.

For example, one flavor seemed to be created as part of a virtual file
system. Someone on the Linux side, would need to make a full time job of
this. (I did observe a thread in Fedora, where someone created a patch for
an issue like this, without so much as a wince or flinching. It doesn't
even look like they consulted a Linux environment NTFS wizard to make the
fix either. Which is fun. They actually fixed the $MFTMIRR error coming
from Win10-created NTFS partitions, by effectively just commenting out the
check. Just... like... that. They cannot do this for reparse points, no
matter how tempting.)

A Junction Point is just a link, a link that "allows moving
your home directory to D: ".

But other reparse points, really are quite custom, and that means we can't
use Linux to take care of them. Slapping a reparse point on a file, rather
than a directory, seems like a purposeful trick to keep Linux out.

I'm almost afraid to open my mouth, make a suggestion to defeat it, and
have them cut off another favorite way of doing things.

*******

Here are my test results.

https://s14.postimg.org/462lq6o8x/Kubuntu_14_04_1.gif

https://s14.postimg.org/wk819k3xt/Ubuntu_16_04_3.gif

https://s14.postimg.org/83pvf5g2p/Ubuntu_17_10.gif

The results are consistent. All three Linux distros think

16299.15 OK
16299.125 OK
16299.309 wuaueng.dll is using a "reparse point"
which is alternately shown as an "I/O error" when it
cannot be stat()ed. It looks to me like "system files"
received this protection. Some files aren't
using it in the System32 directory.

Some change after .125 did this.

My suspicion is, the reparse point in this case, is a "null" one, with no
actual structure. I'll need to consult (some tool) to figure out if this is
the case.

So congrats to Microsoft, on another successful mission.
It's pretty obvious why this change was made.

This isn't an accident. Or a "rogue software designer".

You can check this out, to some extent, by using

dir /a

And a good place to test, is C:\users , as you'll get to see a couple of
the more benign examples. That will demonstrate what some of the attributes
look like.

But if you use Windows to check wuau* files

dir /a C:\Windows\System32\wuau*

then it doesn't show any attribute assigned to it.
Even though Linux has been convinced it's a reparse point.

Either they're using a trick which convinces Linux it's a reparse point, or
the reparse point has zero size (stored in the $REPARSE metadata or the
like).

*******s (for wasting my time).

Bob_S wrote:
"Ragnusen Ultred" wrote in message news

In article news
Following this thread it seems like it would take less time to let
Windows automatically update, than the time spent trying to get around
the updating system. Since MS seems to block every attempt to get
around the updating system it will be a constant battle to keep the
update from happening.

Most of the updates are done in less than a half an hour, How much time
are you spending per update to by pass the system?

Hi Keith,

All your objections are valid, I agree.

However, the question is really WHAT is going on.

The question is for someone who wants to UNDERSTAND what Windows is
doing.

It matters not whether we wish to actually DO what Paul suggested,
which is
to rename a certain file which reputedly disables Windows update.

The underlying question is borne from the fact that I don't UNDERSTAND
what
on earth is different about this "thing" (I can't even call it a "file"):
C:\Windows\System32\wuaueng.dll === this is not a file, per se

What is this "thing"?
Is it a file?
Is it a symbolic link?
Is it a strangely compressed file?
Is it a virtual file?
Is it an assemblage of Microsoft magic

This is really just a question for someone who understands Windows,
and not
a question about disabling Windows update.

What is this thing which acts so differently with respect to permissions
and ability to rename it than all the other files on Windows?
C:\Windows\System32\wuaueng.dll

https://support.microsoft.com/en-us/.../what-is-a-dll

Microsoft appears to have added an additional nuisance
defense mechanism, against Linux edits.

It's well known (and expected in fact), that file system customization
done by slapping reparse points on stuff (adjunct metadata), cannot be
handled by a third-party file system mounter that doesn't know the
details. In the example here, Ubuntu cannot touch a subset
of the files in System32. There are still some non-essential
files in System32, that haven't been abused like that.

https://s14.postimg.org/wk819k3xt/Ubuntu_16_04_3.gif

Since a "dir /a C:\Windows\System32\wuau*" shows
no attribute whatsoever, what they've done is not
visible on the Windows side. It's some kind of
invisible feature, making it harder to tinker with
from Windows.

Paul

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

Paul wrote:

Microsoft appears to have added an additional nuisance
defense mechanism, against Linux edits.

Hi Paul,
I thank you very much for getting to the bottom of this strangeness with
this particular "dll thing", whether it's a dedup (whatever that means) or
a "reparse point" or just a "junction" or whatever ...

For my part, I'll leave it renamed, and I'm leaving the Windows system on
pause, so, when it next updates, I'll let you know if Microsoft bricks me
as a result.

Someone has to try it for the team, so, I'll be the guinnea pig for the
newsgroup on renaming that file to wuaueng.dll.bak

It's well known (and expected in fact), that file system customization
done by slapping reparse points on stuff (adjunct metadata), cannot be
handled by a third-party file system mounter that doesn't know the
details.'

That makes sense in the hits I found on the net which were all unresolved
where people were starting to run into this problem. I ran into it with
Ubuntu 17.10, and you also ran through a bunch of versions where you found
out it's a relatively new trick by Microsoft .... perhaps in the past year
or so???

In the example here, Ubuntu cannot touch a subset
of the files in System32. There are still some non-essential
files in System32, that haven't been abused like that.

I agree that more than one file was affected. Dunno the significance of the
file set that is affected though, as I don't know Windows all that well.

https://s14.postimg.org/wk819k3xt/Ubuntu_16_04_3.gif

That screenshot says it all quite nicely!
Thank you for assembling it, since it clears up the version differences.

Since a "dir /a C:\Windows\System32\wuau*" shows
no attribute whatsoever, what they've done is not
visible on the Windows side.

OK. That's the magic then. I was wondering why, as admin, I couldn't figure
out WHY I couldn't just "move" the file.

Do you think theoretically (without doing it), that Windows "can"
move/rename the file? Or can the file only be moved/renamed when the file
system is mounted on another OS?

It's some kind of
invisible feature, making it harder to tinker with
from Windows.

Thanks Paul for confirming that I'm not going crazy!

It seemed so odd that I couldn't rename it in Windows, and then, when I
renamed it in Linux, it gave those strange "unsupported reparse point"
warnings.

And yet, it moved.

So, as I promised, I'll leave it as it is, renamed, so when Microsoft
updates me, I'll come back if I'm bricked again!

Paul wrote:

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

Hi Paul,

You caused all this trouble! [Please note the smiley!]

Actually, you made the best catch, which was to prove in your screenshot
that it's a new "thing" that Microsoft did, only recently, perhaps in the
past year or so. https://postimg.org/image/71fowjkdp/

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.

Ah, I'm not familiar with that terminology. Googling, that must be
shorthand for "2018-02 Cumulative Update for Windows 10 Version 1709 for
x64-based Systems" which seems to have shipped December 17th 2017.
https://www.ghacks.net/2018/02/13/mi...-2018-release/

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

Ah. Good detective work on the creation date correspondence to 2018-02
Cumulative.

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.

Yikes. Why don't they tell people about this?
What if people had scripts working on these strange "things".

What should we call it anyway, since it's not, really, "just" a dll.
It's a strange beast.

What would you name it, Paul, since you know it best here.


*******

First hit in a search.

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


Wow. Good find Paul. It's the /only/ description on the net I've seen of
what the heck this "thing" is.

Should we refer to it as a "WofCompressedData" file?

If, as that article notes, no other system recognizes it, then what did I
actually do when I "moved" the WofCompressed file to "wuaueng.dll.bak"?

Did I accomplish anything when I /thought/ I moved the file?

Uultred ragnusen wrote:
Paul wrote:

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

Hi Paul,

You caused all this trouble! [Please note the smiley!]

Actually, you made the best catch, which was to prove in your screenshot
that it's a new "thing" that Microsoft did, only recently, perhaps in the
past year or so. https://postimg.org/image/71fowjkdp/

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.

Ah, I'm not familiar with that terminology. Googling, that must be
shorthand for "2018-02 Cumulative Update for Windows 10 Version 1709 for
x64-based Systems" which seems to have shipped December 17th 2017.
https://www.ghacks.net/2018/02/13/mi...-2018-release/

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

Ah. Good detective work on the creation date correspondence to 2018-02
Cumulative.

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.

Yikes. Why don't they tell people about this?
What if people had scripts working on these strange "things".

What should we call it anyway, since it's not, really, "just" a dll.
It's a strange beast.

What would you name it, Paul, since you know it best here.

*******

First hit in a search.

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


Wow. Good find Paul. It's the /only/ description on the net I've seen of
what the heck this "thing" is.

Should we refer to it as a "WofCompressedData" file?

If, as that article notes, no other system recognizes it, then what did I
actually do when I "moved" the WofCompressed file to "wuaueng.dll.bak"?

Did I accomplish anything when I /thought/ I moved the file?

Did you succeed in changing the name of the file or not ?

That's how you'd know.

As well, the "balls" on the Windows Update screen, will
spin forever if you renamed it. That screen tries to call
on Windows Update, but it won't work if the service
can no longer start.

Paul

Am Thu, 22 Mar 2018 14:33:42 -0400, schrieb Paul:

Did you succeed in changing the name of the file or not ?]

Yes.

I failed at changing the file name on Windows.
But I succeeded, with warnings, on Linux.

Given the warnings, who knows what actually happened.
For example, what would happen in this case?

1. move wuaueng.dll wuaueng.dll.bak
2. move wuaueng.dll.bak wuaueng.dll

What would happen?
Would the resulting file be "whole".

I have no idea.
Do you?

That's how you'd know.

OK. It worked.
Now I only need to wait to see if I get bricked on the next Windows update!


Give me credit for taking the risk, as I give you plenty of credit for
finding the trick, and for finding why the trick revealed a change in how
Microsoft does business.

As well, the "balls" on the Windows Update screen, will
spin forever if you renamed it. That screen tries to call
on Windows Update, but it won't work if the service
can no longer start.

Hmmmmm... as long as I can "get out of it", I'll be fine.
Right now I have updates paused.
I will set them back to not being paused.

Even though I've had Win10 for years, I am not familiar with how updates
work (because I had them turned off for years).

Do you have any other suggestions for me other than:
A. Rename wuaueng.dll (done)
B. Turn pause off (i.e., turn updates back on)
C. Wait

Ragnusen Ultred wrote:
Am Thu, 22 Mar 2018 14:33:42 -0400, schrieb Paul:

Did you succeed in changing the name of the file or not ?]

Yes.
I failed at changing the file name on Windows.
But I succeeded, with warnings, on Linux.

Given the warnings, who knows what actually happened.
For example, what would happen in this case?

1. move wuaueng.dll wuaueng.dll.bak
2. move wuaueng.dll.bak wuaueng.dll

What would happen?
Would the resulting file be "whole".

I have no idea.
Do you?

That's how you'd know.

OK. It worked.
Now I only need to wait to see if I get bricked on the next Windows
update!

Give me credit for taking the risk, as I give you plenty of credit for
finding the trick, and for finding why the trick revealed a change in how
Microsoft does business.

As well, the "balls" on the Windows Update screen, will
spin forever if you renamed it. That screen tries to call
on Windows Update, but it won't work if the service
can no longer start.

Hmmmmm... as long as I can "get out of it", I'll be fine.
Right now I have updates paused.
I will set them back to not being paused.

Even though I've had Win10 for years, I am not familiar with how updates
work (because I had them turned off for years).

Do you have any other suggestions for me other than:
A. Rename wuaueng.dll (done)
B. Turn pause off (i.e., turn updates back on)
C. Wait

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.

Paul

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

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.
--


Bob S.