BSOD on friend's computer. Im sure its the memory stick but...

[Andre Lopes]

Greetings,

I have a friend whos having weird random BSOD's.
He formatted his computer with original Windows 10 x64 Pro. But the errors happens randomly. This time, it took 7 days for it to happen after formatting his computer.
Anyway, I ran a 1 pass test with memtest and no errors showed up. his S.M.A.R.T also show no errors. I updated his BIOS and cleared CMOS. Updated all drivers and nothing.

Im about to run a full day memtest just to be sure, but Im expecting no errors.
I was able to get 3 memorydumps and analyzed them but I couldnt come up with proper conclusions its really a memory stick issue. I wanted you guys to check if you agree its the memory stick or not.

I really appreciate any help at all.


Information:

Spoiler

Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz
ASUS H110M-CS/BR Rev X.0x

Display adapter 0
ID 0x4000000
Name Intel(R) HD Graphics 530

Display adapter 1
Name NVIDIA GeForce GTX 1070
Board Manufacturer EVGA Corp.

------
Memory Information
-----
DMI Memory Device
designation DIMM_A1
format DIMM
type DDR4
total width 64 bits
data width 64 bits
size 8 GB

DMI Memory Device
designation DIMM_B1
format DIMM
type DDR4
total width 64 bits
data width 64 bits
size 8 GB

Memory SPD

DIMM # 1
SMBus address 0x50
Memory type DDR4
Module format UDIMM
Manufacturer (ID) (0000000000000000000000)
Size 8192 MBytes
Max bandwidth DDR4-2400 (1200 MHz)
Part number V01D4LF8GB5285282400
Manufacturing date Week 46/Year 16
Nominal Voltage 1.20 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 10.0-10-10-24-34 @ 727 MHz
JEDEC #2 11.0-11-11-26-37 @ 800 MHz
JEDEC #3 12.0-12-12-28-40 @ 872 MHz
JEDEC #4 13.0-14-14-31-44 @ 945 MHz
JEDEC #5 14.0-14-14-33-47 @ 1018 MHz
JEDEC #6 15.0-15-15-35-50 @ 1090 MHz
JEDEC #7 16.0-16-16-38-54 @ 1163 MHz
JEDEC #8 17.0-17-17-39-55 @ 1200 MHz
JEDEC #9 18.0-17-17-39-55 @ 1200 MHz
JEDEC #10 19.0-17-17-39-55 @ 1200 MHz
JEDEC #11 20.0-17-17-39-55 @ 1200 MHz
JEDEC #12 21.0-17-17-39-55 @ 1200 MHz

DIMM # 2
SMBus address 0x52
Memory type DDR4
Module format UDIMM
Manufacturer (ID) (0000000000000000000000)
Size 8192 MBytes
Max bandwidth DDR4-2400 (1200 MHz)
Part number V01D4LF8GB5285282400
Manufacturing date Week 46/Year 16
Nominal Voltage 1.20 Volts
EPP no
XMP no
AMP no
JEDEC timings table CL-tRCD-tRP-tRAS-tRC @ frequency
JEDEC #1 10.0-10-10-24-34 @ 727 MHz
JEDEC #2 11.0-11-11-26-37 @ 800 MHz
JEDEC #3 12.0-12-12-28-40 @ 872 MHz
JEDEC #4 13.0-14-14-31-44 @ 945 MHz
JEDEC #5 14.0-14-14-33-47 @ 1018 MHz
JEDEC #6 15.0-15-15-35-50 @ 1090 MHz
JEDEC #7 16.0-16-16-38-54 @ 1163 MHz
JEDEC #8 17.0-17-17-39-55 @ 1200 MHz
JEDEC #9 18.0-17-17-39-55 @ 1200 MHz
JEDEC #10 19.0-17-17-39-55 @ 1200 MHz
JEDEC #11 20.0-17-17-39-55 @ 1200 MHz
JEDEC #12 21.0-17-17-39-55 @ 1200 MHz

WhosCrashed Report

Spoiler

Crash Dump Analysis

Crash dumps are enabled on your computer.

Crash dump directories:
C:\Windows
C:\Windows\Minidump

On Wed 16/01/2019 19:27:50 your computer crashed or a problem was reported
crash dump file: C:\Windows\Minidump\011619-21484-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x1B1B40)
Bugcheck code: 0x1A (0x41201, 0xFFFFF5BFFED79A80, 0x87000000EF98F867, 0xFFFFA20DF4456D00)
Error: MEMORY_MANAGEMENT
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that a severe memory management error occurred.
This might be a case of memory corruption. This may be because of a hardware issue such as faulty RAM, overheating (thermal issue) or because of a buggy driver. This problem might also be caused because of overheating (thermal issue).
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Wed 16/01/2019 19:27:50 your computer crashed or a problem was reported
crash dump file: C:\Windows\MEMORY.DMP
This was probably caused by the following module: ntkrnlmp.exe (nt!memset+0x78CA8)
Bugcheck code: 0x1A (0x41201, 0xFFFFF5BFFED79A80, 0x87000000EF98F867, 0xFFFFA20DF4456D00)
Error: MEMORY_MANAGEMENT
Bug check description: This indicates that a severe memory management error occurred.
This might be a case of memory corruption. This may be because of a hardware issue such as faulty RAM, overheating (thermal issue) or because of a buggy driver. This problem might also be caused because of overheating (thermal issue).
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Wed 16/01/2019 15:53:24 your computer crashed or a problem was reported
crash dump file: C:\Windows\Minidump\011619-23546-01.dmp
This was probably caused by the following module: ntoskrnl.exe (nt+0x1B1B40)
Bugcheck code: 0x50 (0xFFFFCA8A5302BEA8, 0x0, 0xFFFFF8065D96D551, 0x2)
Error: PAGE_FAULT_IN_NONPAGED_AREA
file path: C:\Windows\system32\ntoskrnl.exe
product: Microsoft® Windows® Operating System
company: Microsoft Corporation
description: NT Kernel & System
Bug check description: This indicates that invalid system memory has been referenced.
This appears to be a typical software driver bug and is not likely to be caused by a hardware problem.
The crash took place in the Windows kernel. Possibly this problem is caused by another driver that cannot be identified at this time.



On Wed 16/01/2019 15:18:19 your computer crashed or a problem was reported
crash dump file: C:\Windows\Minidump\011619-26468-01.dmp
This was probably caused by the following module: shareduserdata.sys (SharedUserData+0x308)
Bugcheck code: 0x1A (0x61941, 0x7FFE0308, 0xD, 0xFFFFD38D3DDB7A00)
Error: MEMORY_MANAGEMENT
Bug check description: This indicates that a severe memory management error occurred.
This might be a case of memory corruption. This may be because of a hardware issue such as faulty RAM, overheating (thermal issue) or because of a buggy driver. This problem might also be caused because of overheating (thermal issue).
The crash took place in a storage driver or controller driver. Since there is no other responsible driver detected, this could be pointing to a malfunctioning drive or corrupted disk. It's suggested that you run CHKDSK.

 

[alceryes]

With 16GBs of RAM about 5-6 hours of memtest86 should be good enough to show memory errors. Then try some intel burn or prime95 tests to put the CPU through its paces.
If it doesn't show anything out of the ordinary I would start to suspect other components or the OS. It could be that the reason it took 7 days to start failing again is because of some software/driver incompatibility or corruption that is getting installed days after the reload. If you're still not sure after testing reload it again but keep the OS as minimal as possible while testing.

 

[Andre Lopes]

With 16GBs of RAM about 5-6 hours of memtest86 should be good enough to show memory errors. Then try some intel burn or prime95 tests to put the CPU through its paces.
If it doesn't show anything out of the ordinary I would start to suspect other components or the OS. It could be that the reason it took 7 days to start failing again is because of some software/driver incompatibility or corruption that is getting installed days after the reload. If you're still not sure after testing reload it again but keep the OS as minimal as possible while testing.

With 16GBs of RAM about 5-6 hours of memtest86 should be good enough to show memory errors. Then try some intel burn or prime95 tests to put the CPU through its paces.
If it doesn't show anything out of the ordinary I would start to suspect other components or the OS. It could be that the reason it took 7 days to start failing again is because of some software/driver incompatibility or corruption that is getting installed days after the reload. If you're still not sure after testing reload it again but keep the OS as minimal as possible while testing.

Im thinking about formatting it and running memtest for 12 hours.

Do you suggest prime95? Which settings should I use? Im always uncomfortable with it heating up the computer.

The user said that After restoring windows, it stopped giving BSOD's. So im quite sure its not hardware, however, I wanna make sure.
What do you suggest?


Thanks for the help!

 

[alceryes]

Remember, as long as you stay within the recommended thermal thresholds of the components, they are *supposed* to be able to run without issues. With that said, I never do a 12-hour burn in. 5-6 hours is more than enough.

Just monitor your CPU temps for the first couple hours. If they stay below 80C (even better, 75C) then it's okay to burn it in for a few more hours. Anything beyond that and you are probably causing extra CPU circuit degradation via electron migration.

Would the extra degradation ever affect your friends CPU before he replaces it...? Probably not.