The thing about the QVL is that RAM on there has been tested and verified as fully compatible. Other RAM probably will work, but there is no guarantee - and that's a bit of a gamble. It also raises flags for us when you later get BSODs that look RAM related. It may not be an issue at all, but on the other hand we can't just ignore it.
Why now? Components age and their characteristics change very slightly as they do. It's not impossible that the RAM was just about compatible when new but in ageing it's now just out of compatibility.
All that said, the two latest dumps (in Safe Mode I think?) are useful.
One is a 0x51 REGISTRY_ERROR bugcheck, which is interesting. I can see that the failure happened early on in a search of the registry hive (it's just at the "Category" level). The registry hives are loaded from the system drive at boot time and then referenced only in memory from then on. That means there are two potential failure areas here...
- Bad RAM that is fouling up the registry hive contents loaded in to it (we've looked hard at RAM)
- Bad system drive that is loading corrupted registry data (we haven't looked here at all yet)
There is another feature of this dump that is generally caused by BAD RAM but which could also be a bad drive; a checksum mismatch...
Code:
*** WARNING: Check Image - Checksum mismatch - Dump: 0x23298, File: 0x26bf9 - W:\Symbols\crashdmp.sys\F69BF9371e000\crashdmp.sys
What that tells us is that the checksum of the driver in the dump does not match the Microsoft checksum for that driver. That is typically caused by bad RAM corrupting the driver in the dump but could potentially be caused by the driver being corrupted as it's loaded. That driver (crashdmp.sys) is not always loaded and is loaded on demand, so perhaps this is a system drive issue?
The other dump also might point at the system drive. It's a 0x50 PAGE_FAULT_IN_NONPAGED_AREA bugcheck, which means a reference to a page that cannot be paged was unavailable. Since this happened in Safe Mode we know that this is not a driver error, so bad RAM is a distinct possibility.
However, in the call stack of this dump we can see disk accesses taking place, the ntfs.sys driver is called. We also see the fltmgr.sys driver called, this is the filter driver manager and usually that might indicate a flaky third-party filter driver, but again we're in Safe Mode, so that's not the case.
We're looking at a bad RAM reference whilst reading (or writing) to the disk and we know this cannot be a bad driver. That means it's either RAM (which we've looked at) or it's a drive (which we've not looked at), and that's probably the system drive since we're in Safe Mode.
Based on these two dumps I would suggest you now look at the system drive (and the boot drive if they are different). That will be the Kingston 250GB NVMe drive I think? Download the
Kingston SSD Manager and see whether that reports any issues with the drive, especially with the SMART data, or whether there is a firmware update for it? If that tool has a diagnostic function then use it to test the drive.