Acquired License from Microsoft Store (self-installed)
Age of system (hardware): Between 2016-2019
Age of OS installation: 4 days / have you re-installed the OS? - yes
CPU: AMD Ryzen 5 1600
Video Card: NVIDIA GeForce RTX 2070 (EVGA)
MotherBoard: MSI X370 GAMING PLUS (MS-7A33)
Power Supply - be quite 560W
Memory: G.Skill Aegis 4x 4Gb Sticks
Driver Verifier - is currently running for 2h
attached the collection.zip and my latest crashdump
I had issues with my system for a long while. For the longest, I assumed it was my GPU because I used to have a 2nd hand Radeon card which caused tons of issues after installation.
(My old GPU burned and I had to get a replacement since then I replaced my mainboard, ram and replaced my GPU itself.)
The BSODs I have ranged from "reference by pointer" Kernel exceptions etc.
I did run memtest in the past but will obviously do another later today and update this thread. (my this is my 2nd Ryzen Motherboard since the 1st one also had BSOD issues where I assumed it was compatible with my RAM).
As far as I can tell there isn't enough information in the minidumps to get details about 0x18 bugchecks. Is the system generating a C:\Windows\MEMORY.DMP file and if so, can you make it available via a cloud drive or file sharing service?
Have you tried the system just using the NVMe driver that comes with Windows rather than using the Samsung version? Older Samsung versions have had issues on some systems and I know they recently released a newer version but I don't know exactly what changed about the driver.
That memory.dmp is actually a different bugcheck code: IRQL_NOT_LESS_OR_EQUAL. The thread that triggered the crash was owned by a process named lghub_agent.exe which is not one I recognize. Searches suggest it's a Logitech component but I'm not certain.
You might be right about the RAM. Personally, I don't trust the results of any RAM test utilities when it comes to DDR4 memory. I've seen too many instances of memtest86 passing after hours of testing only to find out later there was a bad DIMM. I ask people to instead try their systems normally but with only 1 DIMM installed at a time to see if the system becomes unstable with 1 versus the other(s); basically trying to isolate a bad DIMM.
The latest dump was a memory corruption problem with the first parameter being either an unknown or undocumented code (0x41201). I tend to think hardware problems when undocumented codes show up for 0x1A bugchecks so it might be worth trying the memory test suggested above.
After a few days of "no crashes" I really thought it was fixed when I was greeted with 2 crashes in a row "KERNEL_DATA_INPAGE_ERROR" and "KMODE_EXCEPTION_NOT_HANDLED".
I still didn't have time to do the 1-Stick-Ram-At-The-Time-Test |
Looking at the 3 memory dumps I don't see anything in common except for random memory corruption. The process that owned the thread which crashed in each dump was different and they all seem to be executing Microsoft code when the crashes occur. I think the first thing to try would be attempting to make sure the memory is okay. Since you have 4 DIMMs you could take it down to 2 DIMMs which shouldn't be too constraining for most games or apps. See if one pair is stable while the other is not. If you can isolate a pair as problematic you could then try each of that set of 2 by itself to see if you can isolate a bad DIMM.
It's not necessarily being caused by bad memory but we need to be confident we have a solid hardware foundation. So far, the errors don't really allow us to rule anything out at this point.
edit: Is there a reason the Device Setup Manager is running for a HP Envy 32 on your system? As far as I can tell your system isn't an HP but maybe I'm missing something.