Question Help needed to resolve BSOD errors ?

[Swell_Jell]

Motherboard ASRock B650E PG Riptide WiFi
GPU NVIDIA GeForce RTX 4080
Processor AMD Ryzen 7 7800X3D 8-Core Processor 4.20 GHz
Installed RAM 32.0 GB (31.1 GB usable)
System type 64-bit operating system, x64-based processor

As the title says, I've been experiencing BSODs. The PC is relatively new, I built it in December and for the most part I'm happy with it. Unfortunately there are some applications which have been triggering BSOD's, though on some occasions they have happened randomly. This is very disappointing, and it's been a major source of stress recently. This is my first time building a PC and I kind of went all in on it. I'm worried it might be something I'm not capable of fixing, but I'm hoping somebody more experienced will know what to do.

I'm pretty new here and I don't know how to attach the dmp files. Also, if my specs are not detailed enough let me know.

 

[Colif]

I'm pretty new here and I don't know how to attach the dmp files. Also, if my specs are not detailed enough let me know.

Can you follow option one on the following link - here - and then do this step below: Small memory dumps - Have Windows Create a Small Memory Dump (Minidump) on BSOD - that creates a file in c windows/minidump after the next BSOD

1. Open Windows File Explore
   
2. Navigate to C:\Windows\Minidump
   
3. Copy the mini-dump files out onto your Desktop
   
4. Do not use Winzip, use the built in facility in Windows
   
5. Select those files on your Desktop, right click them and choose 'Send to' - Compressed (zipped) folder
   
6. Upload the zip file to the Cloud (OneDrive, DropBox . . . etc.)
   
7. Then post a link here to the zip file, so we can take a look for you . . .
   

applications are victims, its rare one is actual cause.

 

[ubuysa]

When you have completed the above, and you've have a few BSODs, got to the folder C:\Windows\Minidump and upload all files in there to a cloud service. Then post a link to those files in the cloud service here. Be sure to make them public so we don't have to login to download them.

Also, as above, your applications are not causing these BSODs - they can't. It's way more likely that a kernel-mode driver that you have installed is causing these BSODs. Analysing the dumps should allow us to determine which driver is at fault.

 

[Swell_Jell]

Can you follow option one on the following link - here - and then do this step below: Small memory dumps - Have Windows Create a Small Memory Dump (Minidump) on BSOD - that creates a file in c windows/minidump after the next BSOD

1. Open Windows File Explore
2. Navigate to C:\Windows\Minidump
3. Copy the mini-dump files out onto your Desktop
4. Do not use Winzip, use the built in facility in Windows
5. Select those files on your Desktop, right click them and choose 'Send to' - Compressed (zipped) folder
6. Upload the zip file to the Cloud (OneDrive, DropBox . . . etc.)
7. Then post a link here to the zip file, so we can take a look for you . . .

applications are victims, its rare one is actual cause.

When you have completed the above, and you've have a few BSODs, got to the folder C:\Windows\Minidump and upload all files in there to a cloud service. Then post a link to those files in the cloud service here. Be sure to make them public so we don't have to login to download them.

Also, as above, your applications are not causing these BSODs - they can't. It's way more likely that a kernel-mode driver that you have installed is causing these BSODs. Analysing the dumps should allow us to determine which driver is at fault.

Alright, I've racked up a few BSOD mini-dumps. This link should work: https://1drv.ms/u/s!ApW_3o1-0VV2gq4ISleN-bQ5eeiugA?e=bTQU8m

So if the problem is a driver, what does that mean? Would deleting or updating it be a solution?

 

[Colif]

So if the problem is a driver, what does that mean? Would deleting or updating it be a solution?

replacing it normally enough.

Ubuysa may see more in dumps than I can but I have a look anyway
report - mostly for me


File: 013124-9640-01.dmp (Feb 1 2024 - 11:58:32)
BugCheck: [DPC_WATCHDOG_VIOLATION (133)]
Probably caused by: ntkrnlmp.exe (Process: svchost.exe)
Uptime: 0 Day(s), 0 Hour(s), 32 Min(s), and 44 Sec(s)

File: 013124-12828-01.dmp (Feb 1 2024 - 15:11:00)
BugCheck: [ATTEMPTED_WRITE_TO_READONLY_MEMORY (BE)]
Probably caused by: ntkrnlmp.exe (Process: NVDisplay.Cont)
Uptime: 0 Day(s), 0 Hour(s), 00 Min(s), and 11 Sec(s)

File: 013124-11046-01.dmp (Feb 1 2024 - 11:25:31)
BugCheck: [SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007E)]
*** WARNING: Unable to verify timestamp for mtkwl6ex.sys
Probably caused by: mtkwl6ex.sys (Process: System)
Uptime: 2 Day(s), 21 Hour(s), 53 Min(s), and 32 Sec(s)

File: 013124-10390-01.dmp (Feb 1 2024 - 15:09:00)
BugCheck: [PAGE_FAULT_IN_NONPAGED_AREA (50)]
Probably caused by: ntkrnlmp.exe (Process: GameOverlayUI.)
Uptime: 0 Day(s), 1 Hour(s), 01 Min(s), and 33 Sec(s)

File: 013124-10140-01.dmp (Feb 1 2024 - 15:12:51)
BugCheck: [MEMORY_MANAGEMENT (1A)]
Probably caused by: ntkrnlmp.exe (Process: svchost.exe)
Uptime: 0 Day(s), 0 Hour(s), 00 Min(s), and 16 Sec(s)


okay, one of them caused by your Wifi driver, try going here and updating it to latest - https://pg.asrock.com/mb/AMD/B650E PG Riptide WiFi/index.asp#Download
MediaTek Wireless Lan driver ver:3.3.0.0702 is the driver you after.

Try updating your Nvidia drivers as well.

 

[Swell_Jell]

okay, one of them caused by your Wifi driver, try going here and updating it to latest - https://pg.asrock.com/mb/AMD/B650E PG Riptide WiFi/index.asp#Download
MediaTek Wireless Lan driver ver:3.3.0.0702 is the driver you after.

Try updating your Nvidia drivers as well.

Okay, grabbed the wifi driver. Also, I realized I have never used the GeForce Experience app. I forgot it existed despite it being right there on my desktop. I've created an account and downloaded the most recent game ready driver, so I'll see if that helps anything once I have time to experiment with it.

 

[Colif]

Sure, let us know if you get any more errors

 

[ubuysa]

Taken as a whole these dumps are pointing strongly at bad RAM.

One dump (the 0x1000007E) does reference mtkwl6ex.sys, a WiFi driver, and results from an integer overflow in an IDIV (integer divide) instruction in that driver...

CONTEXT:  fffffe0988586930 -- (.cxr 0xfffffe0988586930)
rax=00000000ffffff7e rbx=00000000ffffffc0 rcx=ffff948300190000
rdx=00000000bab60f41 rsi=ffff94830b3b0028 rdi=ffff948300190000
rip=fffff805b00ae085 rsp=fffffe0988587358 rbp=ffff948300a10028
 r8=0000000000000002  r9=ffff9483001901c5 r10=0000000000000000
r11=fffffe0987737481 r12=ffff948300a10028 r13=ffff9482fca65040
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00050287
mtkwl6ex+0xae085:
fffff805`b00ae085 f7f9            idiv    eax,ecx
Resetting default scope

That could well be a driver foul-up, though it could also be bad RAM. It's certainly well worth updating that driver however.

The other dumps are 0xBE, 0x50, 0x1A, and a 0x133.

For that last dump (the 0x133) we'd need a full kernel dump to analyse it, but you've had other BSODs since then so that dump has been overwritten. The other three dumps have no third-party drivers on the call stack leading up to the bugcheck - that is a good indication of a hardware cause.

The 0xBE occurs because the page table is corrupted. Argument 2 in the dump gives the PTE contents (8a00000000800121) which is a non-canonical address (ie. outside the allowed addressing range). That's most like due to bad RAM.

The 0x50 occurs when the kernel is accessing session Id information from RAM and references an invalid page...

TRAP_FRAME:  ffffa387cf776440 -- (.trap 0xffffa387cf776440)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000144d0c00 rbx=0000000000000000 rcx=ffffdf8806a660c0
rdx=ffffdf0bf8440c0b rsi=0000000000000000 rdi=0000000000000000
rip=fffff8075c8af0a8 rsp=ffffa387cf7765d8 rbp=ffffa387cf7774e0
 r8=00000000ffffffff  r9=7ffffffffffffffc r10=00000000ffffffff
r11=0000000000001000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!MmGetSessionId+0x28:
fffff807`5c8af0a8 8b4208          mov     eax,dword ptr [rdx+8] ds:ffffdf0b`f8440c13=????????
Resetting default scope

Microsoft functions never make this kind of error so that error is most likely due to bad RAM backing the referenced address (ffffdf0b`f8440c13=????????).

The 0x1A occurs because of a page table corruption (the 0x41790 value in argument 1). It's a bit of a faff to locate the page table entry, but it's here...

8: kd> !pte ffffedf6`c01925f8
                                           VA ffffed80324bf000
PXE at FFFFEDF6FB7DBED8    PPE at FFFFEDF6FB7DB000    PDE at FFFFEDF6FB600C90    PTE at FFFFEDF6C01925F8
contains 0A00000528767863  contains 0A00000513A80867  contains 0A0000050CE81867  contains 1A00000520047867
pfn 528767    ---DA--KWEV  pfn 513a80    ---DA--UWEV  pfn 50ce81    ---DA--UWEV  pfn 520047    ---DA--UWEV

The flags in there (---DA--UWEV) indicate that this page table entry is mapping a user-mode page (from the U) so this could be a user-mode app or driver fouling up, but given the other dumps this is more likely to be down to bad RAM.

I would test your RAM...

1. Download Memtest86 (free), use the imageUSB.exe tool extracted from the download to make a bootable USB drive containing Memtest86 (1GB is plenty big enough). Do this on a different PC if you can, because you can't fully trust yours at the moment.
2. Then boot that USB drive on your PC, Memtest86 will start running as soon as it boots.
3. If no errors have been found after the four iterations of the 13 different tests that the free version does, then restart Memtest86 and do another four iterations. Even a single bit error is a failure.

 

[Swell_Jell]

Taken as a whole these dumps are pointing strongly at bad RAM.

One dump (the 0x1000007E) does reference mtkwl6ex.sys, a WiFi driver, and results from an integer overflow in an IDIV (integer divide) instruction in that driver...

CONTEXT:  fffffe0988586930 -- (.cxr 0xfffffe0988586930)
rax=00000000ffffff7e rbx=00000000ffffffc0 rcx=ffff948300190000
rdx=00000000bab60f41 rsi=ffff94830b3b0028 rdi=ffff948300190000
rip=fffff805b00ae085 rsp=fffffe0988587358 rbp=ffff948300a10028
 r8=0000000000000002  r9=ffff9483001901c5 r10=0000000000000000
r11=fffffe0987737481 r12=ffff948300a10028 r13=ffff9482fca65040
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po cy
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00050287
mtkwl6ex+0xae085:
fffff805`b00ae085 f7f9            idiv    eax,ecx
Resetting default scope

That could well be a driver foul-up, though it could also be bad RAM. It's certainly well worth updating that driver however.

The other dumps are 0xBE, 0x50, 0x1A, and a 0x133.

For that last dump (the 0x133) we'd need a full kernel dump to analyse it, but you've had other BSODs since then so that dump has been overwritten. The other three dumps have no third-party drivers on the call stack leading up to the bugcheck - that is a good indication of a hardware cause.

The 0xBE occurs because the page table is corrupted. Argument 2 in the dump gives the PTE contents (8a00000000800121) which is a non-canonical address (ie. outside the allowed addressing range). That's most like due to bad RAM.

The 0x50 occurs when the kernel is accessing session Id information from RAM and references an invalid page...

TRAP_FRAME:  ffffa387cf776440 -- (.trap 0xffffa387cf776440)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=00000000144d0c00 rbx=0000000000000000 rcx=ffffdf8806a660c0
rdx=ffffdf0bf8440c0b rsi=0000000000000000 rdi=0000000000000000
rip=fffff8075c8af0a8 rsp=ffffa387cf7765d8 rbp=ffffa387cf7774e0
 r8=00000000ffffffff  r9=7ffffffffffffffc r10=00000000ffffffff
r11=0000000000001000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!MmGetSessionId+0x28:
fffff807`5c8af0a8 8b4208          mov     eax,dword ptr [rdx+8] ds:ffffdf0b`f8440c13=????????
Resetting default scope

Microsoft functions never make this kind of error so that error is most likely due to bad RAM backing the referenced address (ffffdf0b`f8440c13=????????).

The 0x1A occurs because of a page table corruption (the 0x41790 value in argument 1). It's a bit of a faff to locate the page table entry, but it's here...

8: kd> !pte ffffedf6`c01925f8
                                           VA ffffed80324bf000
PXE at FFFFEDF6FB7DBED8    PPE at FFFFEDF6FB7DB000    PDE at FFFFEDF6FB600C90    PTE at FFFFEDF6C01925F8
contains 0A00000528767863  contains 0A00000513A80867  contains 0A0000050CE81867  contains 1A00000520047867
pfn 528767    ---DA--KWEV  pfn 513a80    ---DA--UWEV  pfn 50ce81    ---DA--UWEV  pfn 520047    ---DA--UWEV

The flags in there (---DA--UWEV) indicate that this page table entry is mapping a user-mode page (from the U) so this could be a user-mode app or driver fouling up, but given the other dumps this is more likely to be down to bad RAM.

I would test your RAM...

1. Download Memtest86 (free), use the imageUSB.exe tool extracted from the download to make a bootable USB drive containing Memtest86 (1GB is plenty big enough). Do this on a different PC if you can, because you can't fully trust yours at the moment.
2. Then boot that USB drive on your PC, Memtest86 will start running as soon as it boots.
3. If no errors have been found after the four iterations of the 13 different tests that the free version does, then restart Memtest86 and do another four iterations. Even a single bit error is a failure.

I was afraid it might be a hardware issue. Getting inside my case was ideally not what I wanted to have to do, but if I must. I will do all of this once I am off work.

As a side note, I did run one test last night on an application that was consistently suffering BSODs, unfortunately the steps I took with the drivers were not enough on their own. After reading your message, it makes sense why.

 

[Swell_Jell]

The test stopped prematurely due to too many errors.

 

[gardenman]

You have 2 sticks. Take one out and see what happens. Then test the other. Be sure to place the 1 stick in the proper slot (you may need to read your motherboard manual for this).

	0MHz	Unknown	Unknown
16384MB	4800MHz	Unknown	F5-6400J3239G16G
16384MB	4800MHz	Unknown	F5-6400J3239G16G

 

[ubuysa]

The above advice is good, but even if only one stick is faulty I would recommend that you either buy a replacement RAM stick with exactly the same part number as the good one, or buy a pack of two matched RAM sticks and give the good one away. RAM sticks really need to be matched pairs if you want stability.

 

[Swell_Jell]

You have 2 sticks. Take one out and see what happens. Then test the other. Be sure to place the 1 stick in the proper slot (you may need to read your motherboard manual for this).

	0MHz	Unknown	Unknown
16384MB	4800MHz	Unknown	F5-6400J3239G16G
16384MB	4800MHz	Unknown	F5-6400J3239G16G

I just tested one of the sticks and no errors were reported, so can I safely assume the other stick is causing problems?

 

[gardenman]

I wouldn't. I would test the other one too. Make sure you know what the issue is, then you can fix it and move on. Otherwise you're just guessing. And you can run your PC with 16GB of RAM, if you don't need the 32GB.

 

[Swell_Jell]

You all were right, one of my RAM sticks was bad. I suppose it was bad from the start. The culprit has been removed and my PC has suffered zero BSOD's since. Seriously, thank you all for the support. I'd mark more than one reply as a solution if I could.