Windows 10 BSOD indicates a hardware problem - but what hardware is the problem?

Arlen Holder wrote:
On Wed, 25 Mar 2020 15:59:30 -0000 (UTC), Arlen Holder wrote:

Since this is a new install, I don't even know where mbam.exe came from,
where I don't use Cortana search so I ran the classic "salonb" command:
c:\ dir /s/a/s/on/b c:\tmp\salonb.txt

Correction on the "salonb" options (which are extremely useful!).

The dir salonb options I ran to look for mbam.exe were "/s/a/l/on/b":
cd c:\
dir /s/a/l/on/b c:\tmp\salonb.txt

Where, if I had wanted to, a findstr for the exe could have been attached:
dir /s/a/l/on/b c:\*.* | findstr "mbem.exe"

There was no mbem.exe extent.

It's a new installation of Windows 10 Pro, version 1909, so there isn't
even the Windows Defender running yet (as it's still almost fully default).
https://i.postimg.cc/KYyt5Cms/bsod21.jpg

Mbam.exe would be some Malwarebytes software.

It was just an example of a root cause for a system service exception.

The "system service", whatever it happened to be, was probably
hooked by the mbam realtime malware protection (not the one-shot
scanner they make).

As otherwise, it might not be easy to create a system service exception,
without industrial strength (AV/malware removal) software to
destabilize it.

Well, I hope it turns out it was just a RAM issue of some sort.
As tracking down something really low level, isn't going to be
easy. For example, if you had an AV program, I would not expect
anything the AV program does, to show up in a Procmon trace
(as an ETW event). There's lots of stuff in the OS we have
no hope of debugging, and this is only going to get worse
with time (as more containerization is used in the implementation).
Just as Linux has "snaps" and they can't be debugged.
I wasn't able to gain any traction on a particular
snap package.

Paul

"Arlen Holder" wrote in message ...

snip....

Arlen,

When running memory tests and using your numbering of the modules (1,2,3,4
left to right) you should use two modules that are in the same channel.
i.e. 1 & 3, or 2 & 4 when testing individual channels. The slots are color
coded - or should be but if not just use the above. MemTest86 will tell you
what is what.

If it ran all night without errors using the Windows memory test then I
would stuff all the memory back in and run MemTest86 and see how it fails.
You really can have intermittent bits only when all 4 memory modules are in
place - I know that for fact. The tests used in MemTest86 fully exercise
the memory sticks according to testing standards which are explained on
their site and they have years of experience. Never been refused a warranty
claim when I've run MemTest86 according to the sites instructions.

So test all 4 sticks, then 2 sticks in slots 1 & 3, then remove those and
put the remaining sticks into slots 2 & 4 noting the results. That
maintains the original sequence they were in to begin with and if there are
really intermittent failures, the "Hammer Test" as it's called, will find
them best when all 4 sticks are installed. Other tests run harmonic tests
that repeat specific patterns at various frequencies so the number of slots
being tested can affect results. Go for the gold, then narrow down the
testing sequence to insure you find all errors.

Your memory has a limited lifetime warranty
https://info.patriotmemory.com/warra...ametechlab.com


--

Bob S

On Wed, 25 Mar 2020 12:43:28 -0400, Paul wrote:

Well, I hope it turns out it was just a RAM issue of some sort.

Hi Paul,

Thanks for all your kind, patient, and purposefully helpful advice.
People like you are what make Usenet valuable to all us old men.

At the moment, shockingly, the machine has stayed alive nearly 20 hours,
which is longer than it has done since this started happening.

At the moment, what's removed is:
a. Two memory cards (4GB each for a loss of 8GB)
b. Two terabyte hard disk drives
c. One built-in DVD/CD optical drive
d. One Nvidia graphics card (the motherboard has graphics)

For screen real estate, I hooked up the second monitor, so the motherboard
is running both monitors just fine now (white, DVI, and blue VGA outputs).

What I'll do is let it run for a while (all power management has been
turned off) where, if/when it BSODs, I'll swap the other two cards in.

I don't know if I can do one 4GB card at a time, so I'll try that, but I
suspect it has to be in pairs, where I put them in adjacent slots.
https://i.postimg.cc/J0G9Qp8t/bsod28.jpg

Meanwhile, there are literally a couple hundred tweaks I need to make, one
by one, where, for an example, here are some of the registry treaks to set
up a basic Windows system to work properly for me.

*Copy 15-year old WinXP menu from WinXP to Win10, where it still works!*
C:\data\menu\{archiver,browser,cleaner,database,ed itor,finance,game,hardware,etc.}

*Disable keyboard capslock key*
1. Start the registry editor & navigate to "Keyboard Layout"
HKLM\SYSTEM\CurrentControlSet\Control\Keyboard Layout
2. Create a new "binary value" named (sans quotes) "Scancode Map"
3. To disable the capslock key, set the "Scancode Map" value to:
00,00,00,00,00,00,00,00,02,00,00,00,00,00,3a,00,00 ,00,00,00
To enable the capslock key, delete the "Scancode Map" altogether.
4. Reboot (you must reboot for it to take effect).

Here's what it should look like in the registry editor when done:
Value data:
00000000 00 00 00 00 00 00 00 00 ........
00000008 02 00 00 00 00 00 3A 00 ......:.
00000010 00 00 00 00 ....

*Remove " - Shortcut" when creating shortcuts*
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\Curre ntVersion\Explorer]
"link"=hex:00,00,00,00

*Open extensionless files in gVim*
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\.]
[HKEY_CLASSES_ROOT\.\shell]
[HKEY_CLASSES_ROOT\.\shell\open]
[HKEY_CLASSES_ROOT\.\shell\open\command]
@="\"C:\\app\\editor\\txt\\vim\\vim81\\gvim.exe\ " \"%1\""

*Add a 32-bit DWORD to open more than 15 files at a time*
HKCU\Software\Microsoft\Windows\CurrentVersion\Exp lorer
Name : MultipleInvokePromptMinimum
Type : DWORD
Default : 15 (decimal)
Change to: 100 (decimal)

*Turn off the Windows UAC queries when running VPN config files*
C:\Windows\System32\UserAccountControlSettings.exe
(I need a more graceful way to turn off _just_ VPN config files!)

*Clean up the quicklaunch right-click explorer menu*
{app,data,software,tmp}

*Add mvp hosts file*
http://winhelp2002.mvps.org/hosts.txt

*Add context menu entry for Open Admin Command Windows Here*
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Directory\shell\cmd2]
,-8506"
"Extended"=-
"Icon"="imageres.dll,-5323"
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Directory\shell\cmd2\command]
@="cmd.exe /s /k pushd \"%V\""
[HKEY_CLASSES_ROOT\Directory\Background\shell\cmd2]
,-8506"
"Extended"=-
"Icon"="imageres.dll,-5323"
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Directory\Background\shell\cmd2\ command]
@="cmd.exe /s /k pushd \"%V\""
[HKEY_CLASSES_ROOT\Drive\shell\cmd2]
,-8506"
"Extended"=-
"Icon"="imageres.dll,-5323"
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\Drive\shell\cmd2\command]
@="cmd.exe /s /k pushd \"%V\""
[HKEY_CLASSES_ROOT\LibraryFolder\Background\shell\c md2]
,-8506"
"Extended"=-
"Icon"="imageres.dll,-5323"
"NoWorkingDirectory"=""
[HKEY_CLASSES_ROOT\LibraryFolder\Background\shell\c md2\command]
@="cmd.exe /s /k pushd \"%V\""

*and a few hundred other mandatory Windows 10 tweaks as needed*
(including the Marek Novotny VPN scripts to run thousands of IP addresses)
--
Usenet is a public place for purposefully helpful adults to share ideas.

On Wed, 25 Mar 2020 15:48:27 -0400, n/a wrote:

When running memory tests and using your numbering of the modules (1,2,3,4
left to right) you should use two modules that are in the same channel.
i.e. 1 & 3, or 2 & 4 when testing individual channels.

Now that's interesting! I didn't realize that.
Did I do it wrong by not "staggering" the memory in odd or even slots?

Here's what I can tell you from _emperical_ evidence only!
o Originally, there were four 4GB memory cards in the four slots
https://i.postimg.cc/y6bKSHPB/bsod23.jpg
o The two left slots are black, the two right slots are blue.
https://i.postimg.cc/L4ZfrHh0/bsod22.jpg
o I pulled out the two adjacent blue slot cards:
https://i.postimg.cc/J0G9Qp8t/bsod28.jpg
o And the POST message claimed those were memory banks 3 & 4:
https://i.postimg.cc/bY4t9dHw/bsod29.jpg

The slots are color
coded - or should be but if not just use the above. MemTest86 will tell you
what is what.

I need to find a sacrificial flash drive to install the MemTest86 ISO on.
o Meanwhile, the PC has been running for about 20 hours, which is a record.

If it ran all night without errors using the Windows memory test then I
would stuff all the memory back in and run MemTest86 and see how it fails.
You really can have intermittent bits only when all 4 memory modules are in
place - I know that for fact. The tests used in MemTest86 fully exercise
the memory sticks according to testing standards which are explained on
their site and they have years of experience. Never been refused a warranty
claim when I've run MemTest86 according to the sites instructions.

OK. Given I have _never_ run MemTest86 and you have been successful, what
I'll do is what you suggest, which is re-populate the PC with all four
memory cards, and then run the MemTest86 once I find a spare flash card to
install the ISO on.

I'm shocked that the PC hasn't failed in the past 20 hours since it
wouldn't last an hour before I removed half the memory.

So test all 4 sticks, then 2 sticks in slots 1 & 3, then remove those and
put the remaining sticks into slots 2 & 4 noting the results.

I'll do exactly that:
a. I'll find a spare flash card to put the Memtest86 iso on.
b. I'll run Memtest86 with all four memory cards.
c. I'll run Memtest86 with slots 1 & 3 (the 1st blue, the 1st black slot).
d. I'll run Memtest86 with slots 2 & 4 (the 2nd blue, the 2nd black slot).

That
maintains the original sequence they were in to begin with and if there are
really intermittent failures, the "Hammer Test" as it's called, will find
them best when all 4 sticks are installed.

Thank you for this advice to run the memtest86 and to run it first on all
four to find the intermittences, if any.

Your memory has a limited lifetime warranty
https://info.patriotmemory.com/warra...ametechlab.com

Thanks for looking that up, as I've never even pulled a memory card out of
its slot in more than a decade or two (or so).

It doesn't seem to have an expiry date for that "limited lifetime" where I
got the desktop with the memory already inside of it at that time (many
years ago).
--
Usenet is a public party where adults gather to discuss topics of interest.

On Wed, 25 Mar 2020 22:43:10 -0000 (UTC), Arlen Holder wrote:

At the moment, shockingly, the machine has stayed alive nearly 20 hours,
which is longer than it has done since this started happening.

The Windows PC, surprisingly, is still alive one day later, surprisingly,
simply from (apparently) just removing two memory cards (and not even odd
or even cards - but simply two adjacent memory cards at that).

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.
--
Usenet is where purposefully helpful adults gather to politely discuss
issues of technical content.

"Arlen Holder" wrote in message ...

On Wed, 25 Mar 2020 15:48:27 -0400, n/a wrote:

When running memory tests and using your numbering of the modules
(1,2,3,4
left to right) you should use two modules that are in the same channel.
i.e. 1 & 3, or 2 & 4 when testing individual channels.

Now that's interesting! I didn't realize that.
Did I do it wrong by not "staggering" the memory in odd or even slots?

Here's what I can tell you from _emperical_ evidence only!
o Originally, there were four 4GB memory cards in the four slots
https://i.postimg.cc/y6bKSHPB/bsod23.jpg
o The two left slots are black, the two right slots are blue.
https://i.postimg.cc/L4ZfrHh0/bsod22.jpg
o I pulled out the two adjacent blue slot cards:
https://i.postimg.cc/J0G9Qp8t/bsod28.jpg
o And the POST message claimed those were memory banks 3 & 4:
https://i.postimg.cc/bY4t9dHw/bsod29.jpg

The slots are color
coded - or should be but if not just use the above. MemTest86 will tell
you
what is what.

I need to find a sacrificial flash drive to install the MemTest86 ISO on.
o Meanwhile, the PC has been running for about 20 hours, which is a record.

If it ran all night without errors using the Windows memory test then I
would stuff all the memory back in and run MemTest86 and see how it
fails.
You really can have intermittent bits only when all 4 memory modules are
in
place - I know that for fact. The tests used in MemTest86 fully exercise
the memory sticks according to testing standards which are explained on
their site and they have years of experience. Never been refused a
warranty
claim when I've run MemTest86 according to the sites instructions.

OK. Given I have _never_ run MemTest86 and you have been successful, what
I'll do is what you suggest, which is re-populate the PC with all four
memory cards, and then run the MemTest86 once I find a spare flash card to
install the ISO on.

I'm shocked that the PC hasn't failed in the past 20 hours since it
wouldn't last an hour before I removed half the memory.

So test all 4 sticks, then 2 sticks in slots 1 & 3, then remove those and
put the remaining sticks into slots 2 & 4 noting the results.

I'll do exactly that:
a. I'll find a spare flash card to put the Memtest86 iso on.
b. I'll run Memtest86 with all four memory cards.
c. I'll run Memtest86 with slots 1 & 3 (the 1st blue, the 1st black slot).
d. I'll run Memtest86 with slots 2 & 4 (the 2nd blue, the 2nd black slot).

That
maintains the original sequence they were in to begin with and if there
are
really intermittent failures, the "Hammer Test" as it's called, will find
them best when all 4 sticks are installed.

Thank you for this advice to run the memtest86 and to run it first on all
four to find the intermittences, if any.

Your memory has a limited lifetime warranty
https://info.patriotmemory.com/warra...ametechlab.com

Thanks for looking that up, as I've never even pulled a memory card out of
its slot in more than a decade or two (or so).

It doesn't seem to have an expiry date for that "limited lifetime" where I
got the desktop with the memory already inside of it at that time (many
years ago).

Arlen,

I see in the photo you posted that the memory slots are color coded black
and blue with 2 of each, side-by-side. So Channel A would be the first blue
slot and the first black slot reading right to left. Your DIMM's have a
label on the motherboard showing left to right numbering of 4, 3, 2, 1. So
channel A consists of two slots, number 1 and 3. Channel B slots are 2 and
4. Saying it another way - to test a pair in dual channel mode you fill
slot(s) 1 and 3 and/or slots 2 and 4 --- and not 1 and 2 and/or 3 and 4.
Hope that didn't make it confusing. But no matter, fill all the slots and
go with MemTest86.

With no errors in 24 hrs with only 2 sticks of memory, that sure is a good
sign - but of what, is yet to be discovered. You could move the same two
sticks over to the empty slots and run 24 hrs and see what blows up - if
anything. But to nail it down, install all memory and run MemTest86 as per
the instructions. Don't get creative and think you know the software better
than the authors - it will only waste your time. And you want to be able to
send the log to the manufacturer so they know what the failures are - for
warranty.

It is most likely a bad stick or two of memory but it could be a cold solder
joint on one of the memory slots pins that goes intermittent - fan
vibration, etc. So do the tests thoroughly to make sure you have nailed
down the memory module/s that are failing. As you've already seen, Win10
memory test isn't of much value for some types of failures. Once you test
all the memory, the test results will show you what is bad. So while
testing with MemTest86 lightly tap on each memory stick to see if you can
aggravate anything to narrow down a failing slot connector or solder joint.

On some of the tests (made up scenario) you can have an intermittent bit 17
but bits 16 and 18 may also show as failures and on the next test while bit
17 shows good. That Hammer Test is probably the best test. I think that is
like Test 13 in the queue but if it finds something, your screen will light
up with red lines of text telling you what it found ***or*** it will come to
a complete halt. If it just halts after a failure, good chance it didn't
save the log so take a photo of the screen.

Do yourself a favor and vacuum the CPU heat sink - I see some dust....;-)
Also, while you are looking at the innards, look very closely at all the
capacitors on the motherboard. The tops of each should be flat especially
those with the X indent on the top. Any bulging in the top or sides = bad
cap. Look at the area around the bottom of each to see if there are any
signs of leakage (brownish colored goop). If you find any bad ones, you can
replace them if you know how to handle a soldering iron - otherwise, think
about a new motherboard.
--

Bob S

On Thu, 26 Mar 2020 23:29:30 -0400, n/a wrote:

I see in the photo you posted that the memory slots are color coded black
and blue with 2 of each, side-by-side.

Yes.
o Banks 1 & 2 are blue; banks 3 & 4 are black (based on POST output).

Originally, I arbitrarily labeled, in black marker on the steel housing
o 1,2,3,4 (left to right, the CPU being to the right)

But in actuality, it must be:
o 4,3,2,1 (left to right), the CPU being to the right)

So Channel A would be the first blue
slot and the first black slot reading right to left. Your DIMM's have a
label on the motherboard showing left to right numbering of 4, 3, 2, 1.

You're right!

I must admit I had NOT seen that until just now, I _looked_ all over the
motherboard to see _where_ you saw labels, and they are there in this pic!
o https://i.postimg.cc/BvVCnMQX/bsod34.jpg
Just as you said they were!

The markings are strangely unbalanced though, for some reason:
o DIMM1
o DIMM2xMM1
o DIMM3xMM2
o DIMM4xMM3,xMM4

So channel A consists of 2 slots, number 1 & 3. Channel B slots are 2 & 4.

I think I now understand that, and have relabeled the chassis accordingly.

Saying it another way - to test a pair in dual channel mode you fill
slot(s) 1 and 3 and/or slots 2 and 4 --- and not 1 and 2 and/or 3 and 4.
Hope that didn't make it confusing.

I don't really know what a "channel" is, but since both you and Paul use
that term, I looked it up after running CPU-Z on the machine with the 2
memory cards still in banks 3 and 4:
https://i.postimg.cc/WpHnH6H1/bsod35.jpg

o What is Dual-Channel Memory?
https://www.crucial.com/articles/about-memory/what-is-dual-channel-memory
"There are memory controllers built with one channel, two channels
(dual channel), four channels (quad channel), six channels,
and eight channels."

o Dual-channel memory
https://www.computerhope.com/jargon/d/dual-channel-memory.htm
"The first channel is often slots one and two, and the second channel
is three and four. When installing memory in pairs make sure to install
them into the same colored slot to take advantage of the dual-channel
platform."
But their picture shows alternating colors, whereas mine shows colors
together, so it's confusing because the data is different.

o Multi-channel memory architecture
https://en.wikipedia.org/wiki/Multi-channel_memory_architecture
"Dual-channel architecture requires a dual-channel-capable motherboard
and two or more DDR, DDR2, DDR3, DDR4, or DDR5 memory modules.
The memory modules are installed into matching banks, each of which
belongs to a different channel)."

o What is a Motherboard Memory Controller?
https://www.brighthub.com/computing/hardware/articles/79382.aspx
"In ganged mode, there is a 128 bit wide logical DIMM that maps the
first 64 bits on the physical DDR channel A and the last 64 bit
on DDR channel B. The physical address space, in other words,
is interleaved between the two DIMMs in 64 bit steps"

But no matter, fill all the slots and go with MemTest86.

I've been dealing with Covid-19 issues at home, so things are getting
hectic, where the machine has remained alive, shockingly so, with the
memory in banks 3 & 4 only, where it's time to put the other two back in
and run that memtest86 (I still need a sacrificial memory stick for the
memtest86 ISO).

With no errors in 24 hrs with only 2 sticks of memory, that sure is a good
sign - but of what, is yet to be discovered. You could move the same two
sticks over to the empty slots and run 24 hrs and see what blows up - if
anything.

That's not a bad idea, as it shockingly has been running for two days now
(or so), where before, it wouldn't last an hour or two at most.

But to nail it down, install all memory and run MemTest86 as per
the instructions. Don't get creative and think you know the software better
than the authors - it will only waste your time. And you want to be able to
send the log to the manufacturer so they know what the failures are - for
warranty.

I think the best bang for the buck is, as you say, not to get creative and
just put memtest86 on a flash drive, boot, and test all four at once.

Do yourself a favor and vacuum the CPU heat sink - I see some dust....;-)

Thanks for that tip. What _started_ this whole mess in the first place, as
far as I can tell, is I was blowing the canned air on the dust, of which
there was originally tons and tons, and then, the machine shut down
(obviously I shouldn't have been using the canned air while it was
runnng),.

Then, for weeks (I stopped using the PC after a while 'cuz it wouldn't last
an hour), it would consistently BSOD.

But I don't know if blowing the dust was the cause or just coincidence; but
what I learned (the hard way) is I should clean the dust with a vaccuum,
and not canned air - and - I should power it down first!

Also, while you are looking at the innards, look very closely at all the
capacitors on the motherboard. The tops of each should be flat especially
those with the X indent on the top.

Good advice. I used to blow up electrolytic cans by sticking their leads in
a switched 120VAC socket in college long ago at the Physics lab benches,
where we thought it was funny when people switched on the lights that they
all blew up like firecrackers. (We were even worse in the chemistry labs,
blowing up nitrogen tri-iodide after paintint it wet on the lab benches.)
[As an aside, I'd kill my kids or grandkids if they ever did the
shenanigans we did with exploding things when we were kids.]

If you find any bad ones, you can
replace them if you know how to handle a soldering iron - otherwise, think
about a new motherboard.

I have soldering stations, solder suckers, etc., as I used to work as a
part timeer in a TV repair shop way back in the sixties when I was in
school.
--
Usenet is where adults share experience in a purposefully helpful manner.

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.
--
In addition, the BIOS screen has strange vertical lines in it, as if the
graphics card on the motherboard has been, somehow, affected.

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

On Wed, 20 May 2020 21:52:13 -0400, Paul wrote:

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.

Thanks Paul,
I don't think it's the memory, but it's certainly "something" related to
the hardware, since everything was perfect for about two months.

The original BSODs happened when I was cleaning the fans with air while the
machine was running (lesson learned the hard way), and then they went away
when I removed everything and ran a few scannow fixes (I don't remember
them all).

I tried rebooting to a Windwos boot DVD (which works but which doesn't
recognize the HDD), so I think what I'll do is buy a new HDD (again - this
is my third time over the past few years having to buy yet another terabyte
HDD).

It just is too hit-or-miss to "repair" a corrupted drive, whereas, to just
set up a new drive is more deterministic.

First I'll back up the data off the old drive by putting it in my second
desktop, which is what I have to do today.

Thanks for all your purposefully helpful advice; I really do appreciate
your suggestions.
--
Usenet is a wonderful public potluck of helpful technical discussions.

Arlen Holder wrote:


It just is too hit-or-miss to "repair" a corrupted drive, whereas, to just
set up a new drive is more deterministic.

First I'll back up the data off the old drive by putting it in my second
desktop, which is what I have to do today.

Thanks for all your purposefully helpful advice; I really do appreciate
your suggestions.

Start with the basics.

From Linux (LiveCD will do)

disktype
sudo apt install disktype # may require universe or multiverse to be turned on

sudo disktype /dev/sda

(As an example of when a distro doesn't turn on everything properly...
This is how you install synaptic on Ubuntu, when they don't want you
to have synaptic and make a nuisance of themselves.)

sudo add-apt-repository universe
sudo add-apt-repository multiverse
sudo apt-get update
sudo apt install synaptic
sudo synaptic

Disktype will "sniff" the MBR, then enumerate
the partitions and the detected types.

I don't think the drive is corrupted so much, that
this test won't work.

If the drive cannot be detected at BIOS level, and
all the cables are plugged in, *that's* a duff drive.

Paul

PSA: Sometimes, maybe perhaps, it's a "good thing" to turn off fastboot,
hibernation, and/or sleep in Windows 10.

I've been working, on and off, sporadically, for months on this Windows 10
hardware-related BSOD which often DESTROYS Windows' ability to boot.
o Windows 10 BSOD indicates a hardware problem - but what hardware
is the problem?
https://groups.google.com/forum/#!topic/alt.comp.microsoft.windows/u0ay9h777Wg

For example, I can remove all extraneous hardware from the desktop, and
then re-install Windows 10 from scratch, and invariably, when it BSODs, the
machine might often _never_ reboot successfully after that BSOD.

Why does a BSOD often but not always invariably corrupt the boot records?

I don't know why, but I suspect perhaps maybe a "sudden" BSOD "corrupts"
(somehow?) the hiberfile.sys or memory image or whatever because when I
turned off these three things, the BSOD's remained, but I could boot
afterward.
1. Turn off sleep
2. Turn off hibernation
3. Turn off fastboot

Now, when the machine hits a hardware BSOD, it won't reboot ever from its
own efforts, and it won't reboot even if I shut it down and reboot it
manually - but - if I remove the power cord such that all the LEDs go out
(after a minute or two) on the motherboard - THEN it boots again.

Before I turned off sleep/hibernation/fastboot, it _still_ often wouldn't
ever reboot, even after heroic efforts at a Windows-to-Windows repair.

The other thing I did was make copious system restore points, where I
haven't had to manually utilize them, but I don't know if the system
automatically uses them when it attempts an automatic repair.

In summary, TWO things might possibly save your boot records after a BSOD:
1. Copious system restore points, and/or
2. Turn off hibernation, fastboot, and sleep (I'm not so sure of sleep).

Why?
o I don't know why.

Do you?
--
Usenet is wonderful when everyone pitches in helpfully with knowledge.

On 08/16/2020 06:26 PM, Arlen Holder wrote:
For example, I can remove all extraneous hardware from the desktop,
and then re-install Windows 10 from scratch, and invariably, when it
BSODs, the machine might often_never_ reboot successfully after that
BSOD.

Invariably, it might often never, huh?

I had a Journalism instructor who tried overly hard to impress with his
class textbook. Yep, he wrote one of the books we used. He blew it in
the very first sentence.

On Sun, 16 Aug 2020 21:10:47 -0700, Corvid wrote:

For example, I can remove all extraneous hardware from the desktop,
and then re-install Windows 10 from scratch, and invariably, when it
BSODs, the machine might often_never_ reboot successfully after that
BSOD.

Invariably, it might often never, huh?

I am sorry if the language was too complex, where the main point was the
PSA that turning off the fancy fastboot & hibernation features of Windows
"seems" to have prevented the operating system from chewing itself up.

What happened _before_ I turned off fastboot & hibernation was:
a. The machine would run fine (for days or weeks on end).
b. At some point, it would BSOD (due to an unknown hardware issue).
c. The machine would attempt to reboot forever, after that BSOD.
(each time with a different BSOD message as described earlier)

If I let it reboot on its own, almost all the time it would fail.
(Every once in a while, it would reboot but almost never.)

Even with a manual reboot (using the power switch), it would almost
never reboot successfully.

Even after putting in a Windows 10 DVD and booting off of that, would it
almost never successfully repair the corrupted boot record (using all the
commands to fix the boot records already described in this thread).

In fact, it would _never_ reboot successfully, after that BSOD, until I
turned off the power to the desktop (I generally pull the power cord) and
until I waited for the LED on the motherboard to go out (I have the side
panels removed so I can see inside easily).

Then _sometimes_ after the BSOD, would it reboot - but only then.
o But even so, it almost never rebooted successfully after that.

In contrast to those "almost never" circumstances, so far, it has _always_
rebooted (or fixed the MBR on its own) once I did one simple thing:

I turned off hibernation & fastboot (and sleep).

Now that you know the circumstances, Corvid, in more detail, what can you
say to HELP on the problem set (or do you only play silly childish games)?

On 08/17/2020 04:04 PM, Arlen Holder wrote:
On Sun, 16 Aug 2020 21:10:47 -0700, Corvid wrote:

For example, I can remove all extraneous hardware from the
desktop, and then re-install Windows 10 from scratch, and
invariably, when it BSODs, the machine might often_never_ reboot
successfully after that BSOD.

Invariably, it might often never, huh?

I am sorry if the language was too complex, where the main point was
the

The language is nonsense. Your posts are potentially interesting pieces
turned into mind-numbing exercises for the reader. Invariably.

Now that you know the circumstances, Corvid, in more detail,

I don't.

what can you say to HELP on the problem set (or do you only play
silly childish games)?

My instructor's book was surely decent in its first draft, but then he
had to buff it up. That word "help" was too pedestrian, he swapped it
for something that said the same, but elegantly. And so, the intro began
"This book was written to assist the student learn... "