Frequent freezes and BSODs despite clean install and change of SSD

I have been having very frequent freezes and BSODs over the last several days, as well as other problems that were making my backup software malfunction. The problem with the backup software I resolved by replacing the dead CMOS battery and re-flashing the BIOS, but the freezes continue, even after a completely clean install of Windows on a different SSD. This makes me wonder whether the corrupted BIOS may have caused permanent damage to the hardware.

Here is my V2 log: Attachment 338052

BSODs:
Even though I get frequent BSODs with all kinds of stopcodes, not one of them has led to a successful memory dump. The progress stays at 0% and I have to hold down the power button for 5 seconds to turn the machine off.

The stopcodes have included: "critical process died", "unexpected store exception", "kernel data inpage error" (in gdxkrnl.sys one time and hidusb.sys another time), and "registry filter driver exception" (in wdfilter.sys).

My hardware:
My hardware is an ASRock 980DE3/U3S3 motherboard with an FX-8350 processor. 8GB RAM. GT-610 graphics card.

I have noticed freezes often happening very soon after starting to use Ableton Live, which suggests a possible connection with my Focusrite Scarlett 4Pre USB audio interface, but most of the freezes have happened while this has been switched off.

Two different installations of Windows on different disks:
Just to clarify: I took various steps, starting with sfc /scannow and chkdsk, going by way of replacing the system partition with a backup of it (that my backup software had confirmed as a valid image) made a few days before, and ending by reinstalling Windows while keeping my already installed apps, to try to resolve the problem on the system SSD. I then did a completely clean install of Windows on a different SSD (which I had used previously in a different computer, but noticed trouble with). When the freezes and blue screens continued with this clean installation on a different disk, I reverted to the original SSD. This was because reinstalling my software on a new installation would literally take me several days.

Disks:
As I have already said, I have tried two different SSDs, but got the same problem. I also ran chkdsk, HD Tune, Seatools and (in Ubuntu) Badblocks, but none of them detected a problem with the original SSD.

Memory:
Before I had discovered the problem with the BIOS (which means that several errors could have been at play), I ran memtest86 for 8 hours. It found no errors, but when I tried to interact with it in the morning, it froze.

I have since tried to run memtest86+, but that freezes every time within a few seconds of launching it. I don't know if this is connected to the freezes that occur while I am using Windows or if it is just that memtest86+ is not compatible with my motherboard.

Freezes without BSODs:
Even though I have frequent BSODs, most of the freezes do not lead to a BSOD.

A couple of freezes were unusual. Once today, while using Windows, the screen froze except for the mouse pointer. I was able to continue moving the mouse pointer for several seconds, perhaps as long as a minute, before that too froze.

I also, in the course of troubleshooting, tried booting Ubuntu from a flash drive and used it for several hours. I did not have a complete freeze, but at one point everything on my desktop froze, except for the mouse pointer. Even after this, I was still able to ping the computer from another machine on the network, which means that the kernel was still functioning.

For some reason, perhaps just a coincidence, when I was using the clean installation of Windows on a different disk, the freezes were much more frequent. I had 4, I think, in the hour or perhaps a bit more that I was using it.

Interestingly, 2 of those were within a couple of minutes of powering up the machine, as were some of the freezes and BSODs in the older installation of Windows. This reminds me of a problem I had on my other computer where I would frequently get BSODs shortly after booting or waking from sleep. That problem was due to poor contact between the wireless card and the motherboard.


CPU:
I ran Prime95 for an hour in Windows and stress-ng in Linux, also for an hour, but they detected no problem with the CPU.


Graphics card:
I ran Furmark, but that detected no problems. I also suspected that perhaps the latest Nvidia driver could be to blame, so I reverted to the driver installed by Windows by default, which dates back to 2017, but that did not resolve the freezes and BSODs.

So what is going on?
The problem doesn't appear to be software unless there is something fundamentally wrong with 21H1 and the problems I have had using Ubuntu and memtest86 are coincidences. It doesn't appear to be memory. There are no obvious problems with the CPU or the graphics card. So does that mean that I have a problem with my motherboard? or with the power supply? Or does it mean that some component is poorly installed? But the problems started after the computer hadn't been physically moved for a while.

Or to put it another way, how can I be sure enough that the problem is the motherboard (or the power supply) to be at the point where it is worth taking a chance on buying a replacement motherboard on eBay?

See - BSOD - Posting Instructions

Thanks for replying. The full memory dump is from 22 May, which is a while before I started having my current problems and also before I reinstalled Windows. I actually have this minidump Attachment 338357 from the same day which I found in windows.old. Will that do? I'm not clear about the security implications of publicly posting a full memory dump. I can't remember what was happening a month ago to cause that crash back in May.

On a separate note, swapping the graphics card did not stop the freezes and BSODs happening.

I also got the computer to freeze while running Ubuntu.

- - - Updated - - -

I've just remembered. The crash of 22 May (the date of the last memory dump) happened during boot after I had connected a second monitor to the computer while Windows was in hibernation.

Ztruker said:

The mini dump indicates Focusriteusb.sys is the cause. Doing a Google search found many other people having problems with the same or other Focuswrite drivers.
Suggest you disconnect your Focuswrite device (Scarlett) and see if the problems goes away. If it does then see if there is an updated driver available, otherwise find a replacement for it.

That doesn't surprise me with regard to that particular crash. I've known for a long time that I need to disable audio signal processing in my DAW before I hibernate the computer or I may run into problems. I may well have forgotten to do that on that occasion.

However, that crash was before my current problems, which involve freezes and blue screens but never lead to a memory dump being produced. Those crashes happen whether the Clarett 4Pre is on or off, and they happen both in Windows and in Linux. They started with a message about incorrect CMOS settings, but only some of them were resolved by replacing the CMOS battery and re-flashing the BIOS. My hypothesis is that the corrupt BIOS caused instructions to be executed that did damage to the motherboard. The instability seems to be getting worse. I tried powering up the PC last night, but it was unable to go even two minutes before seizing up, even though I tried to start it up 4 times. I ordered a replacement motherboard a few days ago, and that should be arriving tomorrow. So I'll find out soon enough whether my hypothesis is correct.

Ztruker said:

Could be motherboard, could also be the CPU.

You could be right. I'm betting on the motherboard being the problem because I ran Prime95 for an hour in Windows, and then stress-ng in Ubuntu, without triggering a crash. Unfortunately, since it's an AMD CPU, I couldn't use Intel's CPU diagnostic tool. It might conceivably be both motherboard and CPU, since the corrupt BIOS could potentially have caused multiple problems.

The replacement motherboard arrived this morning. Hopefully I will find time to install it this evening. So I'll find out soon enough.