check reliability monitor, turn off Rebar , try use 1 RAM first

Originally posted by ˢᵈˣ FatCat:

check reliability monitor, turn off Rebar , try use 1 RAM first

First, what's Reliability Monitor? Second, ReBar gives me quite significant performance improvements in most games, so I wouldn't want to disable it. Third, testing each kit would take a long time as it's really random in how the issue exhibits, and I already tested the RAM with TestMem5 and that didn't show any issues in the 1h 30m long run.

Switch to an older MSI bios.

Originally posted by Agenda 2025:

Switch to an older MSI bios.

I think I'll look at the serial number on the motherboard's box and guess which BIOS it came with, thanks.

Downgrading should be the same process as updating, right? Extract the BIOS archive into the USB, and then do the usual thing?

Can you archive (.zip) the corresponding minidumps and upload the file?

Originally posted by Julien, cut it out.:

Can you archive (.zip) the corresponding minidumps and upload the file?

That's the issue, there's no BSOD or kernel panic when that happens, meaning Windows or Linux have no idea that it occured in the first place.

Originally posted by SiberianLeon:

Originally posted by Agenda 2025:

Switch to an older MSI bios.

I think I'll look at the serial number on the motherboard's box and guess which BIOS it came with, thanks.

Downgrading should be the same process as updating, right? Extract the BIOS archive into the USB, and then do the usual thing?

your bios version should show in "bios"

Originally posted by 󠀡󠀡:

Originally posted by SiberianLeon:

I think I'll look at the serial number on the motherboard's box and guess which BIOS it came with, thanks.

Downgrading should be the same process as updating, right? Extract the BIOS archive into the USB, and then do the usual thing?

your bios version should show in "bios"

On the box or in the BIOS directly? I did update it a few days ago, but there were some people saying you shouldn't do it if you have the USB plugged to a 3.0 port, which I did but the PC continues to work with the same quirks.

First things first, that PSU is not great. I'd start there.

Originally posted by SiberianLeon:

It happened with the MSI A520M-A PRO motherboard while playing Payday 2, and it seems to be happening more often lately with the MSI B550M PRO-VDH that I bought in July 2025. It doesn't seem to be related to the OS as I mentioned above, and I also ran TestMem5 earlier today which showed no errors during the 1h 30m test, so it doesn't appear to be the problem with my G.Skill Aegis RAM modules that are 8GB each, or 32GB in total. It doesn't seem to matter whether I enable XMP or set up the DRAM frequency manually to 3200MHz, further suggesting that RAM is not the problem.

The motherboard change MAY be coincidental. Some problems simply get worse with time and it may have occurred with or without the motherboard change. But it could also be related to the motherboard especially if it's unstable memory because the motherboard can be a pretty important variable in a system's memory stability, especially as you approach heavier configurations (which yours sort of may be).

Keep in mind that setting XMP and it being 3,200 MHz and manually setting 3,200 MHz are more or less doing the same thing, so you didn't isolate anything by trying that. XMP is nothing more than a profile that tells the motherboard "I have these pre-configured frequency and timings values, so use them".

A memory configuration becomes more demanding to stabilize as the following occur...

1. DIMM count per channel goes up.

2. Rank count per channel goes up.

3. Frequency goes up.

4. Timings become tighter.

Therefore, whenever you want to try and rule RAM out, you would want to disabled XMP entirely (let it run at JEDEC defaults of 2,133 MHz or whatever) and perhaps even consider going down to two DIMMs, especially if the memory was sold as a pair of kits instead of the same kit of 4.

For reference, many late AM4 platforms (meaning Zen 2/3 CPUs and 500 series chipsets) should typically top out around (or a bit above) four quad rank DIMMs at 3,600 MHz, so you're potentially a bit below that, but pretty close. And this is not always guaranteed (silicon lottery is at play), so less than what I just stated can be unstable with some hardware combinations.

Originally posted by SiberianLeon:

I don't recall this kind of behavior back when I had an Intel Arc A580 from late September 2024 to late December 2024. Well, it did BSOD on me plenty of times, but that was due to the drivers. Here, the problem seems to be at the hardware level.

That's only a time frame of three months, and it too was problematic? How are you sure the previous driver crashes themselves weren't a cascading result of this same hardware instability? After all, many driver instabilities are precisely because of hardware issues somewhere. Not all, but many are.

Random reboots with a BSOD, sometimes with a freeze/pause during a Black screen before it, is often a machine check exception (Windows will often log this as an uncorrectable hardware error). There may be logs in Windows WHEA folders (these will be most helpful in trying to narrow down the cause if they exist) and/or logs in Event Viewer (less helpful here, since I'd simply expect Event ID 41 and 18, and they probably wouldn't hold specific clues for this). Machine check exceptions can be caused for a number of reasons but they are almost always a hardware stability issue rather than a software issue. The latter isn't impossible though.

When dealing with machine check exceptions, having spares to swap out is what it often comes down to. Again, I'd start with the PSU. "Lighten the memory configuration" by disabling XMP and going down to two DIMMs. If a different PSU and lighter RAM configuration still fail, try another GPU.

Originally posted by Illusion of Progress:

First things first, that PSU is not great. I'd start there.

Originally posted by SiberianLeon:

It happened with the MSI A520M-A PRO motherboard while playing Payday 2, and it seems to be happening more often lately with the MSI B550M PRO-VDH that I bought in July 2025. It doesn't seem to be related to the OS as I mentioned above, and I also ran TestMem5 earlier today which showed no errors during the 1h 30m test, so it doesn't appear to be the problem with my G.Skill Aegis RAM modules that are 8GB each, or 32GB in total. It doesn't seem to matter whether I enable XMP or set up the DRAM frequency manually to 3200MHz, further suggesting that RAM is not the problem.

The motherboard change MAY be coincidental. Some problems simply get worse with time and it may have occurred with or without the motherboard change. But it could also be related to the motherboard especially if it's unstable memory because the motherboard can be a pretty important variable in a system's memory stability, especially as you approach heavier configurations (which yours sort of may be).

Keep in mind that setting XMP and it being 3,200 MHz and manually setting 3,200 MHz are more or less doing the same thing, so you didn't isolate anything by trying that. XMP is nothing more than a profile that tells the motherboard "I have these pre-configured frequency and timings values, so use them".

A memory configuration becomes more demanding to stabilize as the following occur...

1. DIMM count per channel goes up.

2. Rank count per channel goes up.

3. Frequency goes up.

4. Timings become tighter.

Therefore, whenever you want to try and rule RAM out, you would want to disabled XMP entirely (let it run at JEDEC defaults of 2,133 MHz or whatever) and perhaps even consider going down to two DIMMs, especially if the memory was sold as a pair of kits instead of the same kit of 4.

For reference, many late AM4 platforms (meaning Zen 2/3 CPUs and 500 series chipsets) should typically top out around (or a bit above) four quad rank DIMMs at 3,600 MHz, so you're potentially a bit below that, but pretty close. And this is not always guaranteed (silicon lottery is at play), so less than what I just stated can be unstable with some hardware combinations.

Originally posted by SiberianLeon:

I don't recall this kind of behavior back when I had an Intel Arc A580 from late September 2024 to late December 2024. Well, it did BSOD on me plenty of times, but that was due to the drivers. Here, the problem seems to be at the hardware level.

That's only a time frame of three months, and it too was problematic? How are you sure the previous driver crashes themselves weren't a cascading result of this same hardware instability? After all, many driver instabilities are precisely because of hardware issues somewhere. Not all, but many are.

Random reboots with a BSOD, sometimes with a freeze/pause during a Black screen before it, is often a machine check exception (Windows will often log this as an uncorrectable hardware error). There may be logs in Windows WHEA folders (these will be most helpful in trying to narrow down the cause if they exist) and/or logs in Event Viewer (less helpful here, since I'd simply expect Event ID 41 and 18, and they probably wouldn't hold specific clues for this). Machine check exceptions can be caused for a number of reasons but they are almost always a hardware stability issue rather than a software issue. The latter isn't impossible though.

When dealing with machine check exceptions, having spares to swap out is what it often comes down to. Again, I'd start with the PSU. "Lighten the memory configuration" by disabling XMP and going down to two DIMMs. If a different PSU and lighter RAM configuration still fail, try another GPU.

I'll think about replacing the PSU to something less clumsy as my PC case looks like a spaghetti with all those cables sticking out and barely fitting inside.

I'll be honest about the RAM, I bought the first pair of 16GB G.Skill Aegis RAM in September 2024 and then another pair in August 2025, and I made sure they were the same kits by looking at their serial numbers, which they were.

If memory configuration is the culprit, how come it has only happened when I was just chilling or playing non-demanding games? I remember playing Silent Hill 2, Resident Evil 4, The Last of Us Part I and II, and plenty of other heavy titles for hours and they wouldn't crash my PC, but something like Payday 2 and Left 4 Dead 2 would. I don't believe that RAM is the issue considering that I ran a test with TestMem5 for an hour and half with 0 errors.

Disabling XMP and any overclocking back to 2133MHz leads to a large performance hit in games, which is something that I want to avoid like with ReBar.

The Arc issue was with the drivers, and I know this because I used it first hand with a variety of drivers. I even posted a thread about it a while ago, I'm sure you can find it if you dig deeper in this subforum.

Again, I never see a blue screen when this happens. The computer either freezes up completely or reboots without any error messages. The only thing Event Viewer says is that the unexpected shutdown has occured, nothing more useful than that.

Looks like I'll have to replace the PSU with something more reliable and compact. All those cables make me lose my mind whenever I have to deal with them.

Well. Likely a faulty RAM stick, swap and find the ♥♥♥♥

Originally posted by Im smoking gas:

Well. Likely a faulty RAM stick, swap and find the ♥♥♥♥

How many times do I have to say that the RAM is unlikely to be the issue? I ran TestMem5 for an hour and half with no errors reported. Or do I have to run Windows' own memory diagnostics tool too?

Install CPUz, run the validator, and then post the link to the result so people can see the hardware details and the configuration.

Abrupt poweroffs will show up in the event logs with event ID 41 (which is essentially the error for an unclean shutdown; so not solely pointing to a power off).

Could be software but in regards to hardware the first two things I'd check are your PSU and the memory.

You can run the Windows Memory Diagnostic thats built into Windows. Or download memtest86 and make a USB boot disk and use that to run a full memory test to see if your memory is faulty or unstable. Using XMP and/or manually configuring the memory to the same settings doesn't preclude the memory being a problem as you're suggesting. Run a mem test on it and see if you're getting errors. If so try setting the memory to its stock JEDEC speeds/timings and then run another mem test to see if you are still getting errors or not. If so then you have bad memory, if not then you have memory that is unstable at the overclocked settings.

Could also be due to the GPU and/or it's VRAM especially if you've undervolted it too much. Try putting it back to sock and run some stress tests on it to see if you're still getting lockups and crashes.

Originally posted by SiberianLeon:

Originally posted by Im smoking gas:

Well. Likely a faulty RAM stick, swap and find the ♥♥♥♥

How many times do I have to say that the RAM is unlikely to be the issue? I ran TestMem5 for an hour and half with no errors reported. Or do I have to run Windows' own memory diagnostics tool too?

Same happened to me, no errors in memtest86, but it kept freezing.
Btw, what RAM you have? Dual or quad channel DDR5?
Windows Diagnostic tool is crap, it cannot find issues.
Try setting DRAM voltage from Auto to standard value, helped for me.

Originally posted by SiberianLeon:

Originally posted by Im smoking gas:

Well. Likely a faulty RAM stick, swap and find the ♥♥♥♥

How many times do I have to say that the RAM is unlikely to be the issue? I ran TestMem5 for an hour and half with no errors reported. Or do I have to run Windows' own memory diagnostics tool too?

Use memtest86 and make sure it's running in parallel mode (mutli-core/multi-threaded) so that it runs the tests across all of your CPU cores. Memory issues aren't solely isolated to just the memory modules and can result from the modules themselves, the DIMM slots, the traces to the CPU, the IMC in the CPU, the CPU cache, etc.

Let it run for the entire test with at least 2 passes. memtest86 will run 12 different memory test patterns to look for various types of memory failures. Letting it run for "X" amount to time isn't the same as letting it run for the full test pass and letting it do at least 2 passes. I'm not sure about TestMem5 but typically an hour and a half isn't going to have completed a full pass of memtest86.