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