Question I'm absolutely lost on how to fix various BSOD crashes ?

May 7, 2023
15
0
10
So, for the last month or so I've been having constant BSOD crashes on my computer with a varied number of reasons given to me. Thanks to BlueScreenViewer, I've go a lot of crash logs and a willingness to share whatever information is necessary. I have absolutely no idea how to fix it and I'm desperate for a solution. I've already run MemTest86 and it told me that I had no hardware issues with my RAM sticks and I've already replaced my old one to see if that was the issue.

Below, I've included a picture of the different crashes reported by BlueScreenViewer but have had no luck actually pinning down the issue. Please, someone help me find a solution.

 
You need to start by listing every single component in your PC.

You should also describe your specific scenario. How long are you using the computer before it BSODs? Is it activity dependent?
It is not activity dependent, it happens randomly as far as I know, I haven’t seen any constants in it.

I don’t know all my components by memory, is there some tool I can use to pull a list?
 
BlueScreenView is only really useful for identifying the really simple and obvious BSOD causes, for most dump analysis you need to upload the dumps here so we can have a proper look. The dumps are in C:\Windows\Minidump, zip up all dumps with a timestamp within the last week or so and upload that zip file.

Also please download Speccy (you can download the portable version if you don't want to install anything). Run Speccy, allow it to analyse your system and then click File > Publish snapshot. This will return a URL, please post that URL here.
 
BlueScreenView is only really useful for identifying the really simple and obvious BSOD causes, for most dump analysis you need to upload the dumps here so we can have a proper look. The dumps are in C:\Windows\Minidump, zip up all dumps with a timestamp within the last week or so and upload that zip file.

Also please download Speccy (you can download the portable version if you don't want to install anything). Run Speccy, allow it to analyse your system and then click File > Publish snapshot. This will return a URL, please post that URL here.
I am unable to do the Speccy setup at this exact moment as it’s rather late and I’m hitting the hay for bed tomorrow, but I made a zip earlier with my dump files, for some reason I only have five or so.

Here is the link; https://www.mediafire.com/file/alqhau2lpx280k6/Dump_Logs.rar/file

I will do the Speccy test tomorrow in the morning before I leave for work if I am able.
 
I'd still like to see the Speccy report but an intial analysis of the dumps strongly suggests a RAM problem. Firstly, none of the call stacks in any of the dumps show third-party driver calls, this is a stroing indication of a hardware problem. Secondly, most of the dumps indicate a RAM issue. An example is the call stack in the 050723-8234-01.dmp...
Code:
1: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffff500`99836e78 fffff802`12ebc49a     nt!KeBugCheckEx
01 fffff500`99836e80 fffff802`12e6d836     nt!MiDeleteVa+0x153a
02 fffff500`99836f80 fffff802`12e6d94b     nt!MiWalkPageTablesRecursively+0x776
03 fffff500`99837020 fffff802`12e6d94b     nt!MiWalkPageTablesRecursively+0x88b
04 fffff500`998370c0 fffff802`12e6d94b     nt!MiWalkPageTablesRecursively+0x88b
05 fffff500`99837160 fffff802`12e6a94b     nt!MiWalkPageTablesRecursively+0x88b
06 fffff500`99837200 fffff802`12ebad31     nt!MiWalkPageTables+0x36b
07 fffff500`99837300 fffff802`12e7e830     nt!MiDeletePagablePteRange+0x4f1
08 fffff500`99837610 fffff802`13285ba9     nt!MiDeleteVad+0x360
09 fffff500`99837720 fffff802`1328554c     nt!MiUnmapVad+0x49
0a fffff500`99837750 fffff802`1322441f     nt!MiCleanVad+0x30
0b fffff500`99837780 fffff802`13231550     nt!MmCleanProcessAddressSpace+0x137
0c fffff500`99837800 fffff802`13283f02     nt!PspRundownSingleProcess+0x20c
0d fffff500`99837890 fffff802`132992ae     nt!PspExitThread+0x5f6
0e fffff500`99837990 fffff802`1300f3f5     nt!NtTerminateProcess+0xde
0f fffff500`99837a00 00007ffc`0a28d5e4     nt!KiSystemServiceCopyEnd+0x25
10 0000006e`fa1dfb78 00000000`00000000     0x00007ffc`0a28d5e4
These call stacks are read from the bottom up (they are push-down stacks). You can see from the function calls that the action here was the termination of a process and the cleanup of the address space afterwards. After the page tables have been deleted for the address space and re-sequenced, we see the nt!MiDeleteVa call to delete the address space - and than we get a bugcheck. Everything that was happening in the stack is RAM related, so that's where I'd look first.

There are two ways to test your RAM:

The most reliable way, if you have more than one stick of RAM, is to remove a stick of RAM and run like that for a day or so - or until it BSODs. Try each stick on its own at a time, if you have a flaky stick you'll soon find it.

The other way is to run a RAM tester. These can never confirm that your RAM is good, but they can detect around 98% of RAM problems. I would recommend Memtest86. Extract the tool from the download and use that to make a bootable USB drive containing Memtest86. Boot that USB drive and Memtest86 will start running.

It will do four iterations of the 13 different tests, if it finds even a single error then you have a RAM issue. If it finds no errors after four iterations then restart Memtest86 and do a further four iterations.
 
I'd still like to see the Speccy report but an intial analysis of the dumps strongly suggests a RAM problem. Firstly, none of the call stacks in any of the dumps show third-party driver calls, this is a stroing indication of a hardware problem. Secondly, most of the dumps indicate a RAM issue. An example is the call stack in the 050723-8234-01.dmp...
Code:
1: kd> knL
 # Child-SP          RetAddr               Call Site
00 fffff500`99836e78 fffff802`12ebc49a     nt!KeBugCheckEx
01 fffff500`99836e80 fffff802`12e6d836     nt!MiDeleteVa+0x153a
02 fffff500`99836f80 fffff802`12e6d94b     nt!MiWalkPageTablesRecursively+0x776
03 fffff500`99837020 fffff802`12e6d94b     nt!MiWalkPageTablesRecursively+0x88b
04 fffff500`998370c0 fffff802`12e6d94b     nt!MiWalkPageTablesRecursively+0x88b
05 fffff500`99837160 fffff802`12e6a94b     nt!MiWalkPageTablesRecursively+0x88b
06 fffff500`99837200 fffff802`12ebad31     nt!MiWalkPageTables+0x36b
07 fffff500`99837300 fffff802`12e7e830     nt!MiDeletePagablePteRange+0x4f1
08 fffff500`99837610 fffff802`13285ba9     nt!MiDeleteVad+0x360
09 fffff500`99837720 fffff802`1328554c     nt!MiUnmapVad+0x49
0a fffff500`99837750 fffff802`1322441f     nt!MiCleanVad+0x30
0b fffff500`99837780 fffff802`13231550     nt!MmCleanProcessAddressSpace+0x137
0c fffff500`99837800 fffff802`13283f02     nt!PspRundownSingleProcess+0x20c
0d fffff500`99837890 fffff802`132992ae     nt!PspExitThread+0x5f6
0e fffff500`99837990 fffff802`1300f3f5     nt!NtTerminateProcess+0xde
0f fffff500`99837a00 00007ffc`0a28d5e4     nt!KiSystemServiceCopyEnd+0x25
10 0000006e`fa1dfb78 00000000`00000000     0x00007ffc`0a28d5e4
These call stacks are read from the bottom up (they are push-down stacks). You can see from the function calls that the action here was the termination of a process and the cleanup of the address space afterwards. After the page tables have been deleted for the address space and re-sequenced, we see the nt!MiDeleteVa call to delete the address space - and than we get a bugcheck. Everything that was happening in the stack is RAM related, so that's where I'd look first.

There are two ways to test your RAM:

The most reliable way, if you have more than one stick of RAM, is to remove a stick of RAM and run like that for a day or so - or until it BSODs. Try each stick on its own at a time, if you have a flaky stick you'll soon find it.

The other way is to run a RAM tester. These can never confirm that your RAM is good, but they can detect around 98% of RAM problems. I would recommend Memtest86. Extract the tool from the download and use that to make a bootable USB drive containing Memtest86. Boot that USB drive and Memtest86 will start running.

It will do four iterations of the 13 different tests, if it finds even a single error then you have a RAM issue. If it finds no errors after four iterations then restart Memtest86 and do a further four iterations.
I have run MemTest86 and it showed no issues, I will run it again later tonight to see later results.

Here are additional crashes that have happened since my last posting.

 
I still think that flaky RAM is the most likely cause here. The three dumps all fail for different reasons...

The 050723-10046-01.dmp fails because a DPC (the driver back-end) ran for too long....
Code:
0: kd> !dpx
Start memory scan  : 0xfffff80216c65e18 ($csp)
End memory scan    : 0xfffff80216c66000 (ISR Stack Base)
0xfffff80216c65e40 : 0xfffff80212afb320 : nt!KeDpcWatchdogProfileGlobalTriageBlock
0xfffff80216c65e78 : 0xfffff802120813c3 : nt!KeClockInterruptNotify+0x453
0xfffff80216c65f18 : 0xfffff80212af3a70 : nt!HalpKInterruptHeap+0x9b0
0xfffff80216c65f28 : 0xfffff80212080eaa : nt!HalpTimerClockIpiRoutine+0x1a
0xfffff80216c65f30 : 0xfffff80212af39c0 : nt!HalpKInterruptHeap+0x900
0xfffff80216c65f40 : 0xfffff802147d1500 : storport!RaidpAdapterDpcRoutine+0x1c0
0xfffff80216c65f58 : 0xfffff8021213e965 : nt!KiCallInterruptServiceRoutine+0xa5
0xfffff80216c65f60 : 0xfffff80212af39c0 : nt!HalpKInterruptHeap+0x900
0xfffff80216c65f68 : 0xfffff80216c65f40 : 0xfffff802147d1500 : storport!RaidpAdapterDpcRoutine+0x1c0
0xfffff80216c65f88 : 0xfffff802121fd94b : nt!KiInterruptSubDispatch+0x13b
0xfffff80216c65fa8 : 0xfffff802121fdbaa : nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
0xfffff80216c65fb8 : 0xfffff80212af39c0 : nt!HalpKInterruptHeap+0x900
0xfffff80216c65fd8 : 0xfffff802121fe377 : nt!KiInterruptDispatchNoLockNoEtw+0x37
The problem driver was likely the Microsoft storport.sys driver, but being a Microsoft driver the driver itself is not at fault. Notice that the frunction being called here is the storport!RaidpAdapterDpcRoutine, and it's called twice. You're not running a RAID config are you? Do you have any RAID options enabled in the BIOS?

The 050723-9546-01.dmp fails because of a memory error...
Code:
2: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffff830a`8e6f6f28 fffff802`4d0c6c39     nt!KeBugCheckEx
01 ffff830a`8e6f6f30 fffff802`4d0bf71e     nt!MiDeletePteRun+0x17b9
02 ffff830a`8e6f7140 fffff802`4d0baceb     nt!MiDeleteVaTail+0x6e
03 ffff830a`8e6f7170 fffff802`4d07e830     nt!MiDeletePagablePteRange+0x4ab
04 ffff830a`8e6f7480 fffff802`4d48555f     nt!MiDeleteVad+0x360
05 ffff830a`8e6f7590 fffff802`4d42441f     nt!MiCleanVad+0x43
06 ffff830a`8e6f75c0 fffff802`4d431550     nt!MmCleanProcessAddressSpace+0x137
07 ffff830a`8e6f7640 fffff802`4d483f02     nt!PspRundownSingleProcess+0x20c
08 ffff830a`8e6f76d0 fffff802`4d4c8578     nt!PspExitThread+0x5f6
09 ffff830a`8e6f77d0 fffff802`4d0ddf37     nt!KiSchedulerApcTerminate+0x38
0a ffff830a`8e6f7810 fffff802`4d201060     nt!KiDeliverApc+0x487
0b ffff830a`8e6f78c0 fffff802`4d20f49f     nt!KiInitiateUserApc+0x70
0c ffff830a`8e6f7a00 00007ffb`96790a74     nt!KiSystemServiceExit+0x9f
0d 0000000c`e59ff6c8 00000000`00000000     0x00007ffb`96790a74
There was a bugcheck whilst deleting a page table entry (the nt!MiDeletePteRun function call). The bugcheck code is MEMORY_MANAGEMENT, so this one strongly points at RAM.

The 050723-8609-01.dmp fails during a graphics operation, the Nvidia graphics card driver nvlddmkm.sys is on the call stack, so this driver cannot be eliminated as a potential cause of this BSOD. However, the failure happens during the freeing of a heap pool (a memory allocation)...
Code:
3: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffde8a`965d9578 fffff805`3a417cab     nt!KeBugCheckEx
01 ffffde8a`965d9580 fffff805`3a3cfb1f     nt!PspSystemThreadStartup$filt$0+0x44
02 ffffde8a`965d95c0 fffff805`3a4062ff     nt!_C_specific_handler+0x9f
03 ffffde8a`965d9630 fffff805`3a2e58c7     nt!RtlpExecuteHandlerForException+0xf
04 ffffde8a`965d9660 fffff805`3a2e7896     nt!RtlDispatchException+0x297
05 ffffde8a`965d9d80 fffff805`3a40fd6c     nt!KiDispatchException+0x186
06 ffffde8a`965da440 fffff805`3a40b7bd     nt!KiExceptionDispatch+0x12c
07 ffffde8a`965da620 fffff805`3a217797     nt!KiPageFault+0x43d
08 ffffde8a`965da7b0 fffff805`3a9b70b9     nt!ExFreeHeapPool+0xb7
09 ffffde8a`965da890 fffff805`3a268311     nt!ExFreePool+0x9
0a ffffde8a`965da8c0 fffff805`3a6a39a7     nt!CmpFreePoolWithTag+0x9
0b ffffde8a`965da8f0 fffff805`3a61389f     nt!CmpFreeKeyControlBlock+0xc7
0c ffffde8a`965da930 fffff805`3a670ce7     nt!CmpUnlockKcb+0x5f
0d ffffde8a`965da960 fffff805`3a28e5c5     nt!CmpDelayCloseWorker+0x147
0e ffffde8a`965daa70 fffff805`3a3265f5     nt!ExpWorkerThread+0x105
0f ffffde8a`965dab10 fffff805`3a404848     nt!PspSystemThreadStartup+0x55
10 ffffde8a`965dab60 00000000`00000000     nt!KiStartSystemThread+0x28
Frame 08 above is where the problem occurs, there is a page fault call immediately following. If we look more closely at frame 08...
Code:
3: kd> .frame /r 8
08 ffffde8a`965da7b0 fffff805`3a9b70b9     nt!ExFreeHeapPool+0xb7
rax=0000000000000000 rbx=ffffbb89e54ac4d0 rcx=0000000000000000
rdx=fffff8053a000000 rsi=0000000000004000 rdi=a2e64eada2e64ead
rip=fffff8053a217797 rsp=ffffde8a965da7b0 rbp=0000000000000001
 r8=00000000ffffffff  r9=7fffbb89e54ac500 r10=7ffffffffffffffc
r11=ffffbb89da2bd000 r12=0000000000000000 r13=0000000000000000
r14=ffffde8a965da9fc r15=0000000000000001
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0000  ds=002b  es=002b  fs=0053  gs=002b             efl=00040282
nt!ExFreeHeapPool+0xb7:
fffff805`3a217797 488b5810        mov     rbx,qword ptr [rax+10h] ds:002b:00000000`00000010=????????????????
The question marks for the resolved address indicate an invalid memory location. This could ultimately have been caused by nvlddmkm.sys of course, but given the other two dumps, which are unrelated to the graphics driver, I think this is more likely a RAM issue.

If your RAM is passing Memtest86 then remove one stick of RAM and run on just the other stick(s) for a few days. Swap the sticks around until each stick has been out and see whether the BSODs stop when one of the RAM sticks is out.
 
I still think that flaky RAM is the most likely cause here. The three dumps all fail for different reasons...

The 050723-10046-01.dmp fails because a DPC (the driver back-end) ran for too long....
Code:
0: kd> !dpx
Start memory scan  : 0xfffff80216c65e18 ($csp)
End memory scan    : 0xfffff80216c66000 (ISR Stack Base)
0xfffff80216c65e40 : 0xfffff80212afb320 : nt!KeDpcWatchdogProfileGlobalTriageBlock
0xfffff80216c65e78 : 0xfffff802120813c3 : nt!KeClockInterruptNotify+0x453
0xfffff80216c65f18 : 0xfffff80212af3a70 : nt!HalpKInterruptHeap+0x9b0
0xfffff80216c65f28 : 0xfffff80212080eaa : nt!HalpTimerClockIpiRoutine+0x1a
0xfffff80216c65f30 : 0xfffff80212af39c0 : nt!HalpKInterruptHeap+0x900
0xfffff80216c65f40 : 0xfffff802147d1500 : storport!RaidpAdapterDpcRoutine+0x1c0
0xfffff80216c65f58 : 0xfffff8021213e965 : nt!KiCallInterruptServiceRoutine+0xa5
0xfffff80216c65f60 : 0xfffff80212af39c0 : nt!HalpKInterruptHeap+0x900
0xfffff80216c65f68 : 0xfffff80216c65f40 : 0xfffff802147d1500 : storport!RaidpAdapterDpcRoutine+0x1c0
0xfffff80216c65f88 : 0xfffff802121fd94b : nt!KiInterruptSubDispatch+0x13b
0xfffff80216c65fa8 : 0xfffff802121fdbaa : nt!KiInterruptSubDispatchNoLockNoEtw+0xfa
0xfffff80216c65fb8 : 0xfffff80212af39c0 : nt!HalpKInterruptHeap+0x900
0xfffff80216c65fd8 : 0xfffff802121fe377 : nt!KiInterruptDispatchNoLockNoEtw+0x37
The problem driver was likely the Microsoft storport.sys driver, but being a Microsoft driver the driver itself is not at fault. Notice that the frunction being called here is the storport!RaidpAdapterDpcRoutine, and it's called twice. You're not running a RAID config are you? Do you have any RAID options enabled in the BIOS?

The 050723-9546-01.dmp fails because of a memory error...
Code:
2: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffff830a`8e6f6f28 fffff802`4d0c6c39     nt!KeBugCheckEx
01 ffff830a`8e6f6f30 fffff802`4d0bf71e     nt!MiDeletePteRun+0x17b9
02 ffff830a`8e6f7140 fffff802`4d0baceb     nt!MiDeleteVaTail+0x6e
03 ffff830a`8e6f7170 fffff802`4d07e830     nt!MiDeletePagablePteRange+0x4ab
04 ffff830a`8e6f7480 fffff802`4d48555f     nt!MiDeleteVad+0x360
05 ffff830a`8e6f7590 fffff802`4d42441f     nt!MiCleanVad+0x43
06 ffff830a`8e6f75c0 fffff802`4d431550     nt!MmCleanProcessAddressSpace+0x137
07 ffff830a`8e6f7640 fffff802`4d483f02     nt!PspRundownSingleProcess+0x20c
08 ffff830a`8e6f76d0 fffff802`4d4c8578     nt!PspExitThread+0x5f6
09 ffff830a`8e6f77d0 fffff802`4d0ddf37     nt!KiSchedulerApcTerminate+0x38
0a ffff830a`8e6f7810 fffff802`4d201060     nt!KiDeliverApc+0x487
0b ffff830a`8e6f78c0 fffff802`4d20f49f     nt!KiInitiateUserApc+0x70
0c ffff830a`8e6f7a00 00007ffb`96790a74     nt!KiSystemServiceExit+0x9f
0d 0000000c`e59ff6c8 00000000`00000000     0x00007ffb`96790a74
There was a bugcheck whilst deleting a page table entry (the nt!MiDeletePteRun function call). The bugcheck code is MEMORY_MANAGEMENT, so this one strongly points at RAM.

The 050723-8609-01.dmp fails during a graphics operation, the Nvidia graphics card driver nvlddmkm.sys is on the call stack, so this driver cannot be eliminated as a potential cause of this BSOD. However, the failure happens during the freeing of a heap pool (a memory allocation)...
Code:
3: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffde8a`965d9578 fffff805`3a417cab     nt!KeBugCheckEx
01 ffffde8a`965d9580 fffff805`3a3cfb1f     nt!PspSystemThreadStartup$filt$0+0x44
02 ffffde8a`965d95c0 fffff805`3a4062ff     nt!_C_specific_handler+0x9f
03 ffffde8a`965d9630 fffff805`3a2e58c7     nt!RtlpExecuteHandlerForException+0xf
04 ffffde8a`965d9660 fffff805`3a2e7896     nt!RtlDispatchException+0x297
05 ffffde8a`965d9d80 fffff805`3a40fd6c     nt!KiDispatchException+0x186
06 ffffde8a`965da440 fffff805`3a40b7bd     nt!KiExceptionDispatch+0x12c
07 ffffde8a`965da620 fffff805`3a217797     nt!KiPageFault+0x43d
08 ffffde8a`965da7b0 fffff805`3a9b70b9     nt!ExFreeHeapPool+0xb7
09 ffffde8a`965da890 fffff805`3a268311     nt!ExFreePool+0x9
0a ffffde8a`965da8c0 fffff805`3a6a39a7     nt!CmpFreePoolWithTag+0x9
0b ffffde8a`965da8f0 fffff805`3a61389f     nt!CmpFreeKeyControlBlock+0xc7
0c ffffde8a`965da930 fffff805`3a670ce7     nt!CmpUnlockKcb+0x5f
0d ffffde8a`965da960 fffff805`3a28e5c5     nt!CmpDelayCloseWorker+0x147
0e ffffde8a`965daa70 fffff805`3a3265f5     nt!ExpWorkerThread+0x105
0f ffffde8a`965dab10 fffff805`3a404848     nt!PspSystemThreadStartup+0x55
10 ffffde8a`965dab60 00000000`00000000     nt!KiStartSystemThread+0x28
Frame 08 above is where the problem occurs, there is a page fault call immediately following. If we look more closely at frame 08...
Code:
3: kd> .frame /r 8
08 ffffde8a`965da7b0 fffff805`3a9b70b9     nt!ExFreeHeapPool+0xb7
rax=0000000000000000 rbx=ffffbb89e54ac4d0 rcx=0000000000000000
rdx=fffff8053a000000 rsi=0000000000004000 rdi=a2e64eada2e64ead
rip=fffff8053a217797 rsp=ffffde8a965da7b0 rbp=0000000000000001
 r8=00000000ffffffff  r9=7fffbb89e54ac500 r10=7ffffffffffffffc
r11=ffffbb89da2bd000 r12=0000000000000000 r13=0000000000000000
r14=ffffde8a965da9fc r15=0000000000000001
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0000  ds=002b  es=002b  fs=0053  gs=002b             efl=00040282
nt!ExFreeHeapPool+0xb7:
fffff805`3a217797 488b5810        mov     rbx,qword ptr [rax+10h] ds:002b:00000000`00000010=????????????????
The question marks for the resolved address indicate an invalid memory location. This could ultimately have been caused by nvlddmkm.sys of course, but given the other two dumps, which are unrelated to the graphics driver, I think this is more likely a RAM issue.

If your RAM is passing Memtest86 then remove one stick of RAM and run on just the other stick(s) for a few days. Swap the sticks around until each stick has been out and see whether the BSODs stop when one of the RAM sticks is out.
I am still crashing with one stick, both are having similar issues without anything new except for my most recent BSOD, which I've linked below;


What do you suggest as a next step for me?
 
There are two possibilities here; one is that it's a hardware issue (which appears not to be RAM since it BSODs on each stick on its own), and the other is that it's a rouge third-party driver that we've not seen in the dumps yet.

I'm going to ask you to enable Driver Verifier, to see whether we can catch a rogue third-party driver in the act.

Driver Verifier subjects selected drivers (typically all third-party drivers) to extra tests and checks every time they are called. These extra checks are designed to uncover drivers that are misbehaving. If any selected driver fails any of the Driver Verifier tests/checks then Driver Verifier will BSOD. The resulting minidump should contain enough information for us to identify the flaky driver. It's thus essential to keep all minidumps created whilst Driver Verifier is enabled.

To enable Driver Verifier do the following:

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...
▪ Special Pool​
▪ Force IRQL checking​
▪ Pool Tracking​
▪ Deadlock Detection​
▪ Security Checks​
▪ Miscellaneous Checks​
▪ Power framework delay fuzzing​
▪ DDI compliance checking​
Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...
▪ Wdf01000.sys​
▪ ndis.sys​
▪ fltMgr.sys​
▪ Storport.sys​

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running until you have between 5 and 10 BSODs/dumps, or for 24 hours. Use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up (using the Windows built-in zip tool) and upload that zip file to here.
 
It could be a rounding error as well. Could run Prime95 and see if it outputs rounding errors.

run Prime 95 overnight as it can take a long time - https://www.guru3d.com/files-details/prime95-download.html

Prime 95 Instructions - https://appuals.com/how-to-run-a-cpu-stress-test-using-prime95/

the results will be saved in a text file in the folder Prime is installed in. Rounding errors point to not enough voltage on ram or cpu.

Do above post first though, I just thought I offer as they can cause random errors too.

if you going to run that, take a look at my precautions here as it can cause Boot loops - https://forums.tomshardware.com/threads/driver-verifier-instructions.3686888/
 
There are two possibilities here; one is that it's a hardware issue (which appears not to be RAM since it BSODs on each stick on its own), and the other is that it's a rouge third-party driver that we've not seen in the dumps yet.

I'm going to ask you to enable Driver Verifier, to see whether we can catch a rogue third-party driver in the act.

Driver Verifier subjects selected drivers (typically all third-party drivers) to extra tests and checks every time they are called. These extra checks are designed to uncover drivers that are misbehaving. If any selected driver fails any of the Driver Verifier tests/checks then Driver Verifier will BSOD. The resulting minidump should contain enough information for us to identify the flaky driver. It's thus essential to keep all minidumps created whilst Driver Verifier is enabled.

To enable Driver Verifier do the following:

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...
▪ Special Pool​
▪ Force IRQL checking​
▪ Pool Tracking​
▪ Deadlock Detection​
▪ Security Checks​
▪ Miscellaneous Checks​
▪ Power framework delay fuzzing​
▪ DDI compliance checking​
Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...
▪ Wdf01000.sys​
▪ ndis.sys​
▪ fltMgr.sys​
▪ Storport.sys​

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running until you have between 5 and 10 BSODs/dumps, or for 24 hours. Use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up (using the Windows built-in zip tool) and upload that zip file to here.
I've just enabled Driver Verifier and my computer is running atrociously, task manager is reading nearly 100% GPU at all times, my audio is stuttering and popping and everything is running really slowly. It's incredibly uncomfortable to use the computer in this state, though no crashes have happened and I don't know of any way to induce a BSOD to get the needed information. What do I do in this situation?
 
I will add some other suggestions:

You are already using Task Manager to observe system performance.

Also use Resource Monitor and Process Explorer to observe system performance but use only one tool at a time.

Process Explorer (Microsoft, free):

https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer

Objective being to discover what all is running on the computer, what resources are being used, to what extent (%), and what is using any given resource. (Note that some columns can be sorted by clicking the small arrows in the column headers. Very helpful if the displayed data is continually shifting too fast to read.)

= = = =

For error information look in Reliability Monitor/History and Event Viewer. Either one or both tools may be capturing some related error codes, warnings, or even informational events that occur just before or at the time of the crashes.

Reliability History is much more user friendly and the timeline format can be very revealing if there are patterns involved. You can display the results by Days/Weeks.

Event Viewer requires more time and effort to navigate and understand. To help:

https://forums.tomshardware.com/threads/how-to-use-windows-10-event-viewer.2752289/

Any given error can be clicked for more information and details. The results may or may not be helpful.

Look in Task Manager > Startup for any unknown or unexpected apps being launched at startup.

Look in Task Scheduler for any unknown or unexpected apps being triggered and then starting up.

Update History: Look for any failed or problem updates. May be a clue there.
 
I will add some other suggestions:

You are already using Task Manager to observe system performance.

Also use Resource Monitor and Process Explorer to observe system performance but use only one tool at a time.

Process Explorer (Microsoft, free):

https://learn.microsoft.com/en-us/sysinternals/downloads/process-explorer

Objective being to discover what all is running on the computer, what resources are being used, to what extent (%), and what is using any given resource. (Note that some columns can be sorted by clicking the small arrows in the column headers. Very helpful if the displayed data is continually shifting too fast to read.)

= = = =

For error information look in Reliability Monitor/History and Event Viewer. Either one or both tools may be capturing some related error codes, warnings, or even informational events that occur just before or at the time of the crashes.

Reliability History is much more user friendly and the timeline format can be very revealing if there are patterns involved. You can display the results by Days/Weeks.

Event Viewer requires more time and effort to navigate and understand. To help:

https://forums.tomshardware.com/threads/how-to-use-windows-10-event-viewer.2752289/

Any given error can be clicked for more information and details. The results may or may not be helpful.

Look in Task Manager > Startup for any unknown or unexpected apps being launched at startup.

Look in Task Scheduler for any unknown or unexpected apps being triggered and then starting up.

Update History: Look for any failed or problem updates. May be a clue there.
Update history shows a failed update for today; View: https://imgur.com/a/Cu2FMlH


As for reliability monitor, there's a lot which seems to be logs from when it crashed to BSOD; View: https://imgur.com/a/aWxKwLg


Didn't see anything notable on the other things you mentioned.
 
There are two possibilities here; one is that it's a hardware issue (which appears not to be RAM since it BSODs on each stick on its own), and the other is that it's a rouge third-party driver that we've not seen in the dumps yet.

I'm going to ask you to enable Driver Verifier, to see whether we can catch a rogue third-party driver in the act.

Driver Verifier subjects selected drivers (typically all third-party drivers) to extra tests and checks every time they are called. These extra checks are designed to uncover drivers that are misbehaving. If any selected driver fails any of the Driver Verifier tests/checks then Driver Verifier will BSOD. The resulting minidump should contain enough information for us to identify the flaky driver. It's thus essential to keep all minidumps created whilst Driver Verifier is enabled.

To enable Driver Verifier do the following:

1. Take a System Restore point and/or take a disk image of your system drive (with Acronis, Macrium Reflect, or similar). It is possible that Driver Verifier may BSOD a driver during the boot process (some drivers are loaded during boot). If that happens you'll be stuck in a boot-BSOD loop.

If you should end up in a boot-BSOD loop, boot the Windows installation media and use that to run system restore and restore to the restore point you took, to remove Driver Verifier and get you booting again. Alternatively you can use the Acronis, Macrium Reflect, or similar, boot media to restore the disk image you took.

Please don't skip this step. it's the only way out of a Driver Verifier boot-BSOD loop.

2. Start the Driver Verifier setup dialog by entering the command verifier in either the Run command box or in a command prompt.

3. On that initial dialog, click the radio button for 'Create custom settings (for code developers)' - the second option - and click the Next button.

4. On the second dialog check (click) the checkboxes for the following tests...
▪ Special Pool​
▪ Force IRQL checking​
▪ Pool Tracking​
▪ Deadlock Detection​
▪ Security Checks​
▪ Miscellaneous Checks​
▪ Power framework delay fuzzing​
▪ DDI compliance checking​
Then click the Next button.

5. On the next dialog click the radio button for 'Select driver names from a list' - the last option - and click the Next button.

6. On the next dialog click on the 'Provider' heading, this will sort the drivers on this column (it makes it easier to isolate Microsoft drivers).

7. Now check (click) ALL drivers that DO NOT have Microsoft as the provider (ie. check all third-party drivers).

8. Then, on the same dialog, check the following Microsoft drivers (and ONLY these Microsoft drivers)...
▪ Wdf01000.sys​
▪ ndis.sys​
▪ fltMgr.sys​
▪ Storport.sys​

9. Now click Finish and then reboot. Driver Verifiier will be enabled.

Be aware that Driver Verifier will remain enabled across all reboots and shutdowns. It can only be disabled manually.

Also be aware that we expect BSODs. Indeed, we want BSODs, to be able to identify the flaky driver(s). You MUST keep all minidumps created whilst Driver Verifier is running, so disable any disk cleanup tools you may have.

10. Leave Driver Verifier running until you have between 5 and 10 BSODs/dumps, or for 24 hours. Use your PC as normal during this time, but do try and make it BSOD. Use every game or app that you normally use, and especially those where you have seen it BSOD in the past.

11. To turn Driver Verifier off enter the command verifier /reset in either Run command box or a command prompt and reboot.

Should you wish to check whether Driver Verfier is enabled or not, open a command prompt and enter the command verifier /query.

12. When Driver Verifier has been disabled, navigate to the folder C:\Windows\Minidump and locate all .dmp files in there that are related to the period when Driver Verifier was running (check the timestamps). Zip these files up (using the Windows built-in zip tool) and upload that zip file to here.
The computer has not bluescreened once with heavy use while Driver Verifier is enabled. Given that it is actually painful to use the computer in this state due to the popping audio that this has caused, I am going to revert it until I hear back from you on the next step
 
The failed update is dated 5/9. The problems precede the date. However, that does not exclude whatever is happening from also causing some update to fail.

= = = =

I suggest a different approach. Disable Driver Verifier along with any and all other tools being launched at start up, immediately manually launched by you, or later triggered via Task Scheduler.

Objective being to re-establish a base, stable system that performs as configured and expected. No BSODs or other problems.

Then, if and as required, start re-introducing other background apps, tools, etc.. Just do so slowly, one tool at a time and be sure to allow time between each addition. Monitor system performance and the logs for changes in performance and error changes. Either error types and/or numbers of errors.

= = = =

Select the "Weeks" timeline and look for the date when all those critical errors began.

Take a look at the details for those events. The details (error codes, etc.) may or may not be helpful.

= = = =

Three things that can also be done:

1) Run the Windows built in troubleshooters. The troubleshooters may find and fix something.

2) Run "sfc /scannow".

3) Run "dism"

References for 2 and 3:

https://www.lifewire.com/how-to-use-sfc-scannow-to-repair-windows-system-files-2626161

How to use DISM command tool to repair Windows 10 image | Windows Central

Very likely that those unexpected shutdowns caused some file corruption and that, in turn, just makes things worse.
 
The failed update is dated 5/9. The problems precede the date. However, that does not exclude whatever is happening from also causing some update to fail.

= = = =

I suggest a different approach. Disable Driver Verifier along with any and all other tools being launched at start up, immediately manually launched by you, or later triggered via Task Scheduler.

Objective being to re-establish a base, stable system that performs as configured and expected. No BSODs or other problems.

Then, if and as required, start re-introducing other background apps, tools, etc.. Just do so slowly, one tool at a time and be sure to allow time between each addition. Monitor system performance and the logs for changes in performance and error changes. Either error types and/or numbers of errors.

= = = =

Select the "Weeks" timeline and look for the date when all those critical errors began.

Take a look at the details for those events. The details (error codes, etc.) may or may not be helpful.

= = = =

Three things that can also be done:

1) Run the Windows built in troubleshooters. The troubleshooters may find and fix something.

2) Run "sfc /scannow".

3) Run "dism"

References for 2 and 3:

https://www.lifewire.com/how-to-use-sfc-scannow-to-repair-windows-system-files-2626161

How to use DISM command tool to repair Windows 10 image | Windows Central

Very likely that those unexpected shutdowns caused some file corruption and that, in turn, just makes things worse.
SFC and DISM were both run, as far as I see there was no changes.
 
Is there (via Reliability History) a specific date when all the critcal errors (red circles) began to appear?

= = = =

Going back a bit:

"my audio is stuttering and popping and everything is running really slowly."

and

"Given that it is actually painful to use the computer in this state due to the popping audio".

What peripherals are installed and how are all of those peripherals connected?

Sketch out a diagram showing all devices, ports, and cable connections. Include power cables and outlets as well. Audio, video, network, USB, electrical (surge protectors, power strips,etc.).

Do you see any "loops"? E.g., A connected to B connected to C connected to D connected to A again.

Any such path of connections that could create a ground loop.

Or provides a potential path for some electrostatic build up or elecrical short to zap the computer.
 
Sorry for the delayed response. If Driver Verifier did not BSOD then your issue is most likely hardware.

To test your CPU run Prime95 as advised above, run small FFTs, Large FFTs and Blend test one at a time. You should also run the Intel Processor Diagnostic Tool.

To test your graphics card run Furmark as described here.

I think your NVMe SSD is a Samsung? If so use Samsung Magician to perform a full diagnostic on it, also see whether Magician can find an updated driver or firmware for the drive.