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

Am Fri, 23 Mar 2018 19:39:09 -0700, schrieb Ragnusen Ultred:

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

Well, it didn't do what I expected, in that it didn't take all that long (a
few minutes only), and yet, it didn't save any size either...
http://i.cubeupload.com/GiwfSF.jpg

Ragnusen Ultred wrote:
Am Fri, 23 Mar 2018 19:39:09 -0700, schrieb Ragnusen Ultred:

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

Well, it didn't do what I expected, in that it didn't take all that long (a
few minutes only), and yet, it didn't save any size either...
http://i.cubeupload.com/GiwfSF.jpg

OK, do Properties on wuaueng.dll.

In the CompactOS Yes state, the size_on_disk was smaller than the size.
Because it actually does compress when CompactOS is being used.

Now that you've run it, the size_on_disk and the size should match,
because the compact command has removed the compression. Or at least,
the disparity between size_on_disk and size should be a lot smaller
difference (less than a 4096 byte difference?).

If you use "nfi.exe" utility, your change should have removed the
"WOFCompression" alternate stream or item in the nfi information.
That label should be gone for the wuaueng.dll entry.

If you use the Linux utility, there should be no more "I/O error"
or "I cannot do anything because of a Reparse point" type errors
for wuaueng.dll and neighbors.

Items like the VFS reparse point, one I have been unable to remove
or work with, will continue to be a problem. This just fixes up
the System32 issue for us.

My backup is still running. You've spoiled at least half the surprise :-)

Thanks for the feedback.

Paul

"Ragnusen Ultred" wrote in message news

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?


Check if you are on the Semi-Annual or Semi-Annual (Targeted) update scheme.
The Targeted channel is the typical user channel and the other is for
release to businesses. The Test system I was using is set to Semi-Annual
Channel (Targeted).

But to verify, I just turned on another workstation that has Semi-Annual
Channel (business) and it was at 16299.309. I just forced a manual update
and it's rebooting.....

It is now on build 16229.334 same as my other test system. It was last
updated (automatically) on 3/16 prior to just doing it now on 3/23.

This may shed some light on the subject:

https://docs.microsoft.com/en-us/win...icing-channels

But why yours is behind since your build 16299.248 was KB4074588 (Falls
Creators Update) released on Feb 13. Why - I can't tell you. Did you have
updates turned off, on pause or simply didn't go online and allow an update
or have restricted the update feature with dial-up settings?

--
Bob S.

Ragnusen Ultred wrote:
Am Fri, 23 Mar 2018 19:39:09 -0700, schrieb Ragnusen Ultred:

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

Well, it didn't do what I expected, in that it didn't take all that long (a
few minutes only), and yet, it didn't save any size either...
http://i.cubeupload.com/GiwfSF.jpg

Hmmmm.

You may have been in too much of a rush.

*******

As a refresher, this is the before.

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)

Now, because I've made my backup, I run the command.

F:\compact /CompactOS:never
Completed uncompressing OS binaries.

22354 files within 19484 directories were uncompressed.

OK, first of all, the file handle has changed. It's gone
to a lower filenum# value, because the filenum# allocation
is supposed to grab the first free one.

However, I wasn't really expecting the filenum entry to move.
This was supposed to be an in-place change.

Now the bad news. It seems to have unlinked the WinSXS copy from
the System32 file.

File 28032
\Windows\System32\wuaueng.dll
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 375765952-375771391 (0x1665bbc0-0x1665d0ff)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

File 1338418
\Windows\WinSxS\amd64_microsoft-windows-w..wsupdateclient-core_31bf3856ad364e35_10.0.16299.248_none_bc721a14 145ef109\wuaueng.dll
$STANDARD_INFORMATION (resident)
$ATTRIBUTE_LIST (resident)
$FILE_NAME (resident)

You'll notice the second file, doesn't have any data clusters.
I'm going to have to "decode" what this means tomorrow.
Too tired to continue. The "Properties" of the second file,
don't indicate that it's empty, so I'm not in a panic.
I just don't understand why the files seemingly got unlinked.
I'll have to find out what STANDARD_INFORMATION means, and whether
it's some sort of extension mechanism. And whether WinSXS is still
"maintainable" this way.

Paul

Am Sat, 24 Mar 2018 00:12:26 -0400, schrieb Bob_S:

Check if you are on the Semi-Annual or Semi-Annual (Targeted) update scheme.
The Targeted channel is the typical user channel and the other is for
release to businesses. The Test system I was using is set to Semi-Annual
Channel (Targeted).

Ah. That's what it is. I have Semi-Annual and not the "targeted" (I think
because I figured it would update less frequently that way. Also the time
period is as long as it would let me, for the same reason. Pause is turned
off, because of what Paul and I were doing, otherwise it would also be on.
http://i.cubeupload.com/YRj2QJ.jpg


But to verify, I just turned on another workstation that has Semi-Annual
Channel (business) and it was at 16299.309. I just forced a manual update
and it's rebooting.....

It is now on build 16229.334 same as my other test system. It was last
updated (automatically) on 3/16 prior to just doing it now on 3/23.

This may shed some light on the subject:

https://docs.microsoft.com/en-us/win...icing-channels

But why yours is behind since your build 16299.248 was KB4074588 (Falls
Creators Update) released on Feb 13. Why - I can't tell you. Did you have
updates turned off, on pause or simply didn't go online and allow an update
or have restricted the update feature with dial-up settings?

I've been online the whole time as this is connected to Ethernet.
I do have the updates restricted as much as possible as explained above, so
that must be the reason as you explained. Thanks.

Paul wrote:
Ragnusen Ultred wrote:
Am Fri, 23 Mar 2018 19:39:09 -0700, schrieb Ragnusen Ultred:

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

Well, it didn't do what I expected, in that it didn't take all that
long (a
few minutes only), and yet, it didn't save any size either...
http://i.cubeupload.com/GiwfSF.jpg

Hmmmm.

You may have been in too much of a rush.

*******

As a refresher, this is the before.

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)

Now, because I've made my backup, I run the command.

F:\compact /CompactOS:never
Completed uncompressing OS binaries.

22354 files within 19484 directories were uncompressed.

OK, first of all, the file handle has changed. It's gone
to a lower filenum# value, because the filenum# allocation
is supposed to grab the first free one.

However, I wasn't really expecting the filenum entry to move.
This was supposed to be an in-place change.

Now the bad news. It seems to have unlinked the WinSXS copy from
the System32 file.

File 28032
\Windows\System32\wuaueng.dll
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 375765952-375771391 (0x1665bbc0-0x1665d0ff)
$EA_INFORMATION (resident)
$EA (resident)
Attribute Type 0x100 $TXF_DATA (resident)

File 1338418
\Windows\WinSxS\amd64_microsoft-windows-w..wsupdateclient-core_31bf3856ad364e35_10.0.16299.248_none_bc721a14 145ef109\wuaueng.dll

$STANDARD_INFORMATION (resident)
$ATTRIBUTE_LIST (resident)
$FILE_NAME (resident)

You'll notice the second file, doesn't have any data clusters.
I'm going to have to "decode" what this means tomorrow.
Too tired to continue. The "Properties" of the second file,
don't indicate that it's empty, so I'm not in a panic.
I just don't understand why the files seemingly got unlinked.
I'll have to find out what STANDARD_INFORMATION means, and whether
it's some sort of extension mechanism. And whether WinSXS is still
"maintainable" this way.

Paul

OK, did some more checking, and it looks like that structure is
"equivalent" to the first, minus of course the WofCompressedData things.

I ran SFC on the disk, and it didn't change the entries.

From Linux, the inode number (which equals the filenum# of Windows and
is stuffed with that number for keeping stat() happy), is 1338418. That
means, in fact, the NTFS file structure still considers 1338418 to be
the "boss" file entry, and 28032 to be the "caboose". SFC is happy, since
it wants to link 1338418 (as master), into System32 folder. That's what
the Windows servicing model is all about.

There's no point of me running DISM, to refill WinSXS and potentially
blow away 1338418. I'm convinced at this point, "nothing has changed"
except the CompactOS being changed back to not using reparse points.

Here is a picture of Ubuntu 16.03.3 and what it thinks of my
fixed up 16299.309 OS. Now I can rename wuaueng.dll if and when I want,
to wuaueng.dll.bak :-)

https://s14.postimg.org/6k05ruxep/Co...afe_To_Use.gif

Paul

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

OK, do Properties on wuaueng.dll.

In the CompactOS Yes state, the size_on_disk was smaller than the size.
Because it actually does compress when CompactOS is being used.

Now that you've run it, the size_on_disk and the size should match,
because the compact command has removed the compression. Or at least,
the disparity between size_on_disk and size should be a lot smaller
difference (less than a 4096 byte difference?).

They do seem to match, although I didn't check it beforehand, but I believe
you that beforehand they probably wouldn't have matched in size.
http://i.cubeupload.com/9i3kK6.jpg

If you use "nfi.exe" utility, your change should have removed the
"WOFCompression" alternate stream or item in the nfi information.
That label should be gone for the wuaueng.dll entry.

If you use the Linux utility, there should be no more "I/O error"
or "I cannot do anything because of a Reparse point" type errors
for wuaueng.dll and neighbors.

Items like the VFS reparse point, one I have been unable to remove
or work with, will continue to be a problem. This just fixes up
the System32 issue for us.

My backup is still running. You've spoiled at least half the surprise :-)

Thanks for the feedback.

Paul

Hi Paul,
I didn't get out of nfi.exe what you got out of it, since even at a command
prompt, nfi.exe wouldn't even recognize the wuaueng.dll file that the sfc
scannnow created.

So, I'm officially confused.

Here's my ad-hoc nfi installation log, which may help explain exactly what
I did....
================================================== ==========================
https://web.archive.org/web/20150329...us/oem3sr2.zip

That saves:
---------------------------
Checksum information
---------------------------
Name: oem3sr2.zip
Size: 3772278 bytes (3 MB)

SHA256: C2A9B81F251AC66870707663CCB681E1A966DE81D6C488EECA B1C40270DFB417

---------------------------
OK
---------------------------

Moved oem3sr2 into C:\apps\os\sysinternals\oem3sr2\

Noted that the "nfi.exe" is located at:
C:\apps\os\sysinternals\oem3sr2\nfi\nfi.exe

================================================== ==========================
nfi.exe
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.

Dumps information about an NTFS volume, and optionally determines
which volume and file contains a particular sector.

Usage: nfi.exe drive-letter [logical-sector-number]

Drive-letter can be a single character or a character followed
by a colon (i.e., C or C: are acceptable).

Logical-sector-number is a decimal or 0x-prefixed hex
number, specifying a sector number relative to the volume
whose drive letter is given by drive-letter. If not
specified, then information about every file on the volume
is dumped.

nfi.exe NT-device-path physical-sector-number

Determines which volume a given physical sector on a drive is
within, and then which file on the volume it is in.

NT-device-path is the NT-style path to a physical device.
It must not include a partition specification.

Physical-sector-number is a decimal or 0x-prefixed hex
number, specifying a sector number relative to the physical
drive whose device path is given by NT-device-path.

nfi.exe full-win32-path

Dumps information about a particular file. full-win32-path
must start with a drive letter and a colon.
================================================== ==========================
I forgot to be admin, so this is to be expected...
nfi C:\Windows\System32\wuaueng.dll
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.

Unable to open drive C.
Access is denied.
================================================== ==========================
Did it as in an admin command window...
C:\Windows\System32\wuaueng.dll
The system cannot execute the specified program.

Hmmm.... why?
C:\Windows\System32\wuaueng.dll.bak
Results in a Windows pop up of "how do you want to open this file?"
================================================== ==========================
I'm officially confused why nfi, as admin, can't access "wuaueng.dll" for
me, but where Paul got results from nfi.exe when running the same command.

Am Sat, 24 Mar 2018 11:55:30 -0700, schrieb Ragnusen Ultred:

I'm officially confused why nfi, as admin, can't access "wuaueng.dll" for
me, but where Paul got results from nfi.exe when running the same command.

Here is a screenshot, which showed that both the wuaueng.dll and
wuaueng.dll.bak actually gave the same error in nfi.exe for whatever
reasons unknown to me...

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

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

OK, do Properties on wuaueng.dll.

In the CompactOS Yes state, the size_on_disk was smaller than the size.
Because it actually does compress when CompactOS is being used.

Now that you've run it, the size_on_disk and the size should match,
because the compact command has removed the compression. Or at least,
the disparity between size_on_disk and size should be a lot smaller
difference (less than a 4096 byte difference?).

They do seem to match, although I didn't check it beforehand, but I believe
you that beforehand they probably wouldn't have matched in size.
http://i.cubeupload.com/9i3kK6.jpg

If you use "nfi.exe" utility, your change should have removed the
"WOFCompression" alternate stream or item in the nfi information.
That label should be gone for the wuaueng.dll entry.

If you use the Linux utility, there should be no more "I/O error"
or "I cannot do anything because of a Reparse point" type errors
for wuaueng.dll and neighbors.

Items like the VFS reparse point, one I have been unable to remove
or work with, will continue to be a problem. This just fixes up
the System32 issue for us.

My backup is still running. You've spoiled at least half the surprise :-)

Thanks for the feedback.

Paul

Hi Paul,
I didn't get out of nfi.exe what you got out of it, since even at a command
prompt, nfi.exe wouldn't even recognize the wuaueng.dll file that the sfc
scannnow created.

So, I'm officially confused.

Here's my ad-hoc nfi installation log, which may help explain exactly what
I did....
================================================== ==========================

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


That saves:
---------------------------
Checksum information
---------------------------
Name: oem3sr2.zip
Size: 3772278 bytes (3 MB)

SHA256: C2A9B81F251AC66870707663CCB681E1A966DE81D6C488EECA B1C40270DFB417

---------------------------
OK ---------------------------

Moved oem3sr2 into C:\apps\os\sysinternals\oem3sr2\

Noted that the "nfi.exe" is located at:
C:\apps\os\sysinternals\oem3sr2\nfi\nfi.exe

================================================== ==========================

nfi.exe
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.

Dumps information about an NTFS volume, and optionally determines
which volume and file contains a particular sector.

Usage: nfi.exe drive-letter [logical-sector-number]

Drive-letter can be a single character or a character followed
by a colon (i.e., C or C: are acceptable).

Logical-sector-number is a decimal or 0x-prefixed hex
number, specifying a sector number relative to the volume
whose drive letter is given by drive-letter. If not
specified, then information about every file on the volume
is dumped.

nfi.exe NT-device-path physical-sector-number

Determines which volume a given physical sector on a drive is
within, and then which file on the volume it is in.

NT-device-path is the NT-style path to a physical device.
It must not include a partition specification.

Physical-sector-number is a decimal or 0x-prefixed hex
number, specifying a sector number relative to the physical
drive whose device path is given by NT-device-path.

nfi.exe full-win32-path

Dumps information about a particular file. full-win32-path
must start with a drive letter and a colon.
================================================== ==========================

I forgot to be admin, so this is to be expected...
nfi C:\Windows\System32\wuaueng.dll
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.

Unable to open drive C.
Access is denied.
================================================== ==========================

Did it as in an admin command window...
C:\Windows\System32\wuaueng.dll
The system cannot execute the specified program.

Hmmm.... why?
C:\Windows\System32\wuaueng.dll.bak
Results in a Windows pop up of "how do you want to open this file?"
================================================== ==========================

I'm officially confused why nfi, as admin, can't access "wuaueng.dll" for
me, but where Paul got results from nfi.exe when running the same command.

nfi.exe C:\Windows\System32\wuaueng.dll

You forgot to put the utility name at the beginning
of the command.

*******

I sometimes just dump the whole OS drive and walk away
until it is done. On my Win10 machine this is 350MB in size.
It takes notepad a while to open that file for me (there are other
better editors).

nfi.exe C: out.txt
notepad out.txt

You would modify the current working directory, to ensure that
the location you write "out.txt" to, is write-able. There are
the "usual small details" to making that set of commands work.

Just don't forget the nfi.exe in front, OK ?

Paul

Am Sat, 24 Mar 2018 16:00:41 -0400, schrieb Paul:

Just don't forget the nfi.exe in front, OK ?

I may have made a typo, or even a thinko, but I certainly know to do the
command first.

Here's what I did:
https://i.cubeupload.com/YbBfhk.jpg

I'm sure there's a dumb mistake on my part somewhere there, but it's
reproducible.

Ragnusen Ultred wrote:
Am Sat, 24 Mar 2018 16:00:41 -0400, schrieb Paul:

Just don't forget the nfi.exe in front, OK ?

I may have made a typo, or even a thinko, but I certainly know to do the
command first.

Here's what I did:
https://i.cubeupload.com/YbBfhk.jpg

I'm sure there's a dumb mistake on my part somewhere there, but it's
reproducible.

Try the "whoami" command, as that can tell you if you're
a member of the administrator group.

whoami
whoami /user
whoami /user /priv

# Examples using various accounts
http://s18.postimg.org/wowci9o95/whoami_user_priv.png

While you are at it, navigate to the folder in question
with File Explorer, do Properties on the file, check
the Security tab and see if something odd has happened there.
To block you.

*******

If you want more "horsepower", run as SYSTEM.

The PsTools suite has the "psexec" program.

https://docs.microsoft.com/en-us/sys...nloads/pstools

Here is a little demo I did a while back, with psexec and whoami.

https://s9.postimg.org/vwioz43f3/WIN10_delete_ENUM.gif

There is a psexec.exe and a psexec64.exe and you should
select the one that matches the bitness of your OS.

You can't get much higher than SYSTEM.

There is a technique to become "TrustedInstaller", but the
code for it is not trustworthy, and it seems to modify the
Administrator account. SYSTEM is plenty good for most
of the "problem" situations.

Paul

"Ragnusen Ultred" wrote in message news

Am Sat, 24 Mar 2018 00:12:26 -0400, schrieb Bob_S:

Check if you are on the Semi-Annual or Semi-Annual (Targeted) update
scheme. The Targeted channel is the typical user channel and the other is
for release to businesses. The Test system I was using is set to
Semi-Annual Channel (Targeted).

Ah. That's what it is. I have Semi-Annual and not the "targeted" (I think
because I figured it would update less frequently that way. Also the time
period is as long as it would let me, for the same reason. Pause is turned
off, because of what Paul and I were doing, otherwise it would also be on.
http://i.cubeupload.com/YRj2QJ.jpg


But to verify, I just turned on another workstation that has Semi-Annual
Channel (business) and it was at 16299.309. I just forced a manual
update and it's rebooting.....

It is now on build 16229.334 same as my other test system. It was last
updated (automatically) on 3/16 prior to just doing it now on 3/23.

This may shed some light on the subject:

https://docs.microsoft.com/en-us/win...icing-channels

But why yours is behind since your build 16299.248 was KB4074588 (Falls
Creators Update) released on Feb 13. Why - I can't tell you. Did you
have updates turned off, on pause or simply didn't go online and allow an
update or have restricted the update feature with dial-up settings?

I've been online the whole time as this is connected to Ethernet.
I do have the updates restricted as much as possible as explained above, so
that must be the reason as you explained. Thanks.


And now you can go back and continue with the maligning of protected files
to simply turn off updates....;-)


--


Bob S.

Am Sat, 24 Mar 2018 18:46:11 -0400, schrieb Paul:

Try the "whoami" command, as that can tell you if you're
a member of the administrator group.

whoami
whoami /user
whoami /user /priv

# Examples using various accounts
http://s18.postimg.org/wowci9o95/whoami_user_priv.png

Here are the results from that command, where I'm not sure the answer.
http://i.cubeupload.com/tE9ugs.jpg

C:\WINDOWS\system32whoami
desktop\ultred

C:\WINDOWS\system32whoami /user

USER INFORMATION
----------------

User Name SID
========= ==========================================
desktop\ultred S-1-5-21-{bunch of numbers}-1001

C:\WINDOWS\system32whoami /user /priv

USER INFORMATION
----------------

User Name SID
========= ==========================================
desktop\ultred S-1-5-21-{bunch of numbers}-1001


PRIVILEGES INFORMATION
----------------------

Privilege Name Description State
========================================= ================================================== ================ ========
SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled
SeSecurityPrivilege Manage auditing and security log Disabled
SeTakeOwnershipPrivilege Take ownership of files or other objects Disabled
SeLoadDriverPrivilege Load and unload device drivers Disabled
SeSystemProfilePrivilege Profile system performance Disabled
SeSystemtimePrivilege Change the system time Disabled
SeProfileSingleProcessPrivilege Profile single process Disabled
SeIncreaseBasePriorityPrivilege Increase scheduling priority Disabled
SeCreatePagefilePrivilege Create a pagefile Disabled
SeBackupPrivilege Back up files and directories Disabled
SeRestorePrivilege Restore files and directories Disabled
SeShutdownPrivilege Shut down the system Disabled
SeDebugPrivilege Debug programs Disabled
SeSystemEnvironmentPrivilege Modify firmware environment values Disabled
SeChangeNotifyPrivilege Bypass traverse checking Enabled
SeRemoteShutdownPrivilege Force shutdown from a remote system Disabled
SeUndockPrivilege Remove computer from docking station Disabled
SeManageVolumePrivilege Perform volume maintenance tasks Disabled
SeImpersonatePrivilege Impersonate a client after authentication Enabled
SeCreateGlobalPrivilege Create global objects Enabled
SeIncreaseWorkingSetPrivilege Increase a process working set Disabled
SeTimeZonePrivilege Change the time zone Disabled
SeCreateSymbolicLinkPrivilege Create symbolic links Disabled
SeDelegateSessionUserImpersonatePrivilege Obtain an impersonation token for another user in the same session Disabled

C:\WINDOWS\system32

One thing I should try to figure out is if I made an admin user a month ago
when I installed the OS since I don't remember if I did, nor what the
password would be since I took mostly the defaults.

While you are at it, navigate to the folder in question
with File Explorer, do Properties on the file, check
the Security tab and see if something odd has happened there.
To block you.

I'm not sure what to look for, but here are the results:
http://i.cubeupload.com/pxKgNh.jpg

If you want more "horsepower", run as SYSTEM.

The PsTools suite has the "psexec" program.

https://docs.microsoft.com/en-us/sys...nloads/pstools

Here is a little demo I did a while back, with psexec and whoami.

https://s9.postimg.org/vwioz43f3/WIN10_delete_ENUM.gif

There is a psexec.exe and a psexec64.exe and you should
select the one that matches the bitness of your OS.

You can't get much higher than SYSTEM.

There is a technique to become "TrustedInstaller", but the
code for it is not trustworthy, and it seems to modify the
Administrator account. SYSTEM is plenty good for most
of the "problem" situations.

Paul

Wow. Reminds me of Cygwin, in a way, when I installed that years ago.
It will take a while of experimenting with these pstools...

here's my install log...
https://docs.microsoft.com/en-us/sys...nloads/pstools

---------------------------
Checksum information
---------------------------
Name: PSTools.zip
Size: 2823905 bytes (2 MB)

SHA256: 91C36D9794F031F9756C4B2C2DBFD315C83E05BE13FD3932CB A878794B4E828E

---------------------------
OK
---------------------------

================================================== ==========================
https://docs.microsoft.com/en-us/sys...nloads/pstools

PsExec - execute processes remotely
PsFile - shows files opened remotely
PsGetSid - display the SID of a computer or a user
PsInfo - list information about a system
PsPing - measure network performance
PsKill - kill processes by name or process ID
PsList - list detailed information about processes
PsLoggedOn - see who's logged on locally and via resource sharing (full
source is included)
PsLogList - dump event log records
PsPasswd - changes account passwords
PsService - view and control services
PsShutdown - shuts down and optionally reboots a computer
PsSuspend - suspends processes
PsUptime - shows you how long a system has been running since its last
reboot (PsUptime's functionality has been incorporated into PsInfo

Am Sat, 24 Mar 2018 18:51:38 -0400, schrieb Bob_S:

And now you can go back and continue with the maligning of protected files
to simply turn off updates....;-)

When there are two completely different paths to the same destination, you
can only take one.

To go back after traveling one path, and start all over, isn't always the
best way to get to the destination.

So, while I understand your suggestion, I also saw Paul's response that the
path you're suggesting may not actually get to the final destination
either.

So either path is a risk, but you can't take both paths. Since I'm
embarking on this path, with Paul's help, it's the safer path for me, given
that I can trust that you'll help or I can trust that he'll help if I get
mired in the mud.

Anyway, I'll take the path Paul chose simply because he is doing it at the
same time, and he's done a lot of work, and his was the first suggestion.

But if that fails, then we can backtrack and try your path. OK?

Ragnusen Ultred wrote:
Am Sat, 24 Mar 2018 18:46:11 -0400, schrieb Paul:

Try the "whoami" command, as that can tell you if you're
a member of the administrator group.

whoami
whoami /user
whoami /user /priv

# Examples using various accounts
http://s18.postimg.org/wowci9o95/whoami_user_priv.png

Here are the results from that command, where I'm not sure the answer.
http://i.cubeupload.com/tE9ugs.jpg

C:\WINDOWS\system32whoami
desktop\ultred

C:\WINDOWS\system32whoami /user

USER INFORMATION
----------------

User Name SID
========= ==========================================
desktop\ultred S-1-5-21-{bunch of numbers}-1001

C:\WINDOWS\system32whoami /user /priv

USER INFORMATION
----------------

User Name SID
========= ==========================================
desktop\ultred S-1-5-21-{bunch of numbers}-1001


PRIVILEGES INFORMATION
----------------------

Privilege Name
Description State
=========================================
================================================== ================ ========
SeImpersonatePrivilege Impersonate a client after authentication Enabled

C:\WINDOWS\system32

One thing I should try to figure out is if I made an admin user a month ago
when I installed the OS since I don't remember if I did, nor what the
password would be since I took mostly the defaults.

The long list of Privileges is similar to an Administrator Group
user, so it looks like you are such a user. You opened an Administrator
Command Prompt window, and the current working directory when opened
was C:\Windows\System32. These are all signs you're an administrator.

The permissions system allows inheritance, and something set above
System32 could cause a change to the computed permissions for that file.
Looking at the Security tab alone might not be enough. I'm no good
with this Security tab stuff, and I frequently cannot tell you why this
stuff isn't working!

Paul