Arlen Holder wrote:
On Thu, 26 Mar 2020 07:52:56 -0000 (UTC), Arlen Holder wrote:

I find it hard to believe we zeroed in so easily on the culprit, but I'll
keep the PC alive for another day just to make sure, before running full
memtest86 tests (as suggested by n/a & Paul) on all four memory sticks.

UPDATE:

The PC stayed alive until earlier this week, with zero problems.
o That's with the RAM cards all back in the original four slots

Then, I put the Nvidia GeForce 210 graphics card back...
o And, it worked fine, for, oh, a few hours.

Albeit, the Nvidia GPU fan was super noisy the whole time...
o Then... suddenly.... wham!

Now the PC won't reboot again... for days.
o So I'm starting over... (without the Nvidia card!)

Interestingly, the boot won't recognize the HDD at all...
o I get the Windows blue flag on a black background... forever.

I'm booting to a flash drive as we speak...
o And trying to figure out (on another PC) what the commands are...

So far, I've tried (to no avail)...
o bootrec.exe /fixmbr
(that works)
o bootrec.exe /fix boot
(access is denied)
o bootrec.exe /scanos
(total identified windwos installations = 0)
etc.

Your RAM-related issues (whatever they are), could
have damaged the Registry.

That's the first thing to fail, when people do Overclocking
tests using a Windows install for the purpose. The
registry gets hit. That's why I tell people to use
a Linux LiveCD for that sort of testing, and get
a Linux version of Prime95 for stress testing,
from mersenne.org.

A System Restore point could have copies of the Registry,
and going back an SR might bring it back. Registry files
are in two places - system registries are in the Windows
folder hierarchy, while your personal profile has registry
files that cover things like program settings.

If you can bring up the system in Safe Mode, then an
SR restoration done there is "un-reversible". You
can't undo it if you restore from Safe Mode.

And since Windows 10 has a bad habit of turning off SR,
it's "never on when you need it". That happened to
me the other day as well, "I think I turned on SR...
dammit, it's off".

As for the "can't find Windows" thing, usually a
single missing file does that. It's not like the
fricken folder has entirely disappeared with 5000
files or something. The Microsoft logic is a
bit too "brittle" when making declarations like
this. All it takes is the tiniest bits of damage,
to get a result like that. Then your job is to
see whether it's "winload.exe" that's missing or
whatever.

Sometimes, the guilty file is in the small print
error message. I was puttering around with some
brokenness a while back, wondering "well, what the
hell is corrupt?", and after doing a few reboots,
I looked at the screen, and in the "tiny print
error message", it actually gave the filename. Doh!

On a failure to boot, you can use your Macrium emergency
boot CD, and try to get it to restore boot-ability.
Followed by using the Windows repair routine. That's my
favorite order for repair. If the file system has really
been trashed (which happens), you'll figure it out
pretty quickly, that your dumpster is on fire.

And you cannot rely on Linux in cases like this,
because the $MFTMIRR will be damaged to start with.
And I don't think even Ubuntu Fossil has this fixed
yet (removal of $MFTMIRR check). On an intact file
system, I could use windows 7 to do a CHKDSK and
repair the $MFTMIRR, but it might take *hours*
to clunk through the Extended Attributes - it only
processes one or two of those per second.

In 2020, fixing busted stuff really really sucks!
I cannot emphasize this enough. The damage to the
file system from Windows 10, is a gift that keeps
on giving, extending repair intervals by hours.

Paul