Mayayana wrote:
"Paul" wrote

.... Secure boot seems to be at least part of the problem.
With that turned off I'm getting either a login to reset
or error c000021a. Ophcrack can't find a password
needed for the reset. But it's progress. Thanks. I never
would have thought of secure boot acting like the hard
disk is loose!



http://aumha.org/a/stop.htm

"0xC000021A: STATUS_SYSTEM_PROCESS_TERMINATED

This occurs when Windows switches into kernel mode and
a user-mode subsystem, such as Winlogon or the
Client Server Runtime Subsystem (CSRSS), is compromised.
"

If you're getting that far along, then maybe it's a
malware problem ? Or perhaps, an AV program has
quarantined a file (false positive), trashing
the machine. If you know an AV is present,
see if you can figure out where the quarantines go.

Alternately, if you know the AV used, check the news
and see if a recent update caused mayhem amongst
the user population. A false positive usually makes
a big stink when a critical system file is moved.

*******

You can use DISM and SFC, both in offline mode,
to try and shore up system files.

Normally, on a modern OS, DISM can chech on the Internet.
If your Win10 booted, these can verify the content of
WinSXS (for system stuff). The first checks a flag.
The second does a read only scan. The third is read/write.
You're supposed to try them in sequence for some reason.

Dism /Online /Cleanup-Image /CheckHealth

Dism /Online /Cleanup-Image /ScanHealth

Dism /Online /Cleanup-Image /RestoreHealth

Life is tougher of you're running DISM from a WinPE
boot disk and a Command Prompt window.

https://answers.microsoft.com/en-us/...0a77fc1?auth=1

Bleckfield replied on November 11, 2015

mkdir c:\mount

DISM.exe /mount-Image /ImageFile:d:\sources\install.wim /index:1 /mountdir:C:\mount\ /readonly

# That would mount the WIM as a file system, within C:\mount
# as the mount point. The mount point is merely a reference for
# the beginning of the file tree mounted on top of it.

DISM.exe /Online /Cleanup-image /Restorehealth /Source:c:\mount\windows /LimitAccess

# You can see that attempts to use the Windows folder on the
# mount point, as a "reference" for restoration. It should be
# able to restore any WinSXS files that happen to be on the
# installer DVD version. It would help (obviously) if you use
# a Win 8.1 disc of recent vintage - using a Win 8.0 DVD image
# on a Win 8.1 system, I bet it would complain.
#
# As for the LimitAccess option, this is what it does.
# I don't know if the network is even up, if you're running
# WinPE by booting the installer DVD to Command Prompt.

"You can use /LimitAccess to prevent the DISM tool
from using Windows Update as a repair source or
as a backup repair source for online images"

So that's a basic idea as to how you could repair WinSXS.
It may need some adjustments on your part, to get that
working properly.

If that finishes properly, the next thing is SFC, which
checks that the System32 files are OK. You would do this
in the same session. The trick here, is identifying which
drive letter is which. I hate that, in this environment.
Normally, X: is the Command Prompt OS partition. The C:
partition could actually be C:, or in some cases
it might be D: . I have to list disk contents until
I'm convinced I'm pointed at the right partition
to fix. The same issue arises, even with the previous
command sequence - you have to positively identify your
partitions, to pick "good" places to work :-)

sfc /scannow /offbootdir=d:\ /offwindir=d:\windows

So those two, would be intended to fix corrupted system
files. This would be on a system that has already passed
CHKDSK. And we all know, that using CHKDSK is a double-edged
sword. It can fix stuff, or it can break stuff. It's nice
to have a backup of the target, just in case you're
not born lucky.

You will need to salt these commands to taste. The
above is merely some leads on what the commands
*might* look like.

Note - Eternal September has an incoming feed problem
right now, which is damping the responses you might
normally get.

Good luck,
Paul