Question Frequent BSOD crashing with different reason each time ?

thomashouston · Apr 28, 2023

Hello everyone,
I am currently having issue with multiple BSODs every day, often with different reason in the BSOD screen.

A few things I have tried

using just 1 RAM sticks
move RAM stick to different RAM slot
sfc /scannow
checkdisk
install newest chipset firmware
install latest BIOS
install latest VGA driver
install latest SSD firmware
clean boot
idle on safe mode (still BSOD)
reinstall windows (had a blue screen during windows installation once)
unplug and replug every cables from PSU from both ends
replaced the boot SSD
use different VGA card

My PC spec
CPU : AMD Ryzen 5 3600
Motherboard : MSI x570 Gaming Plus
RAM : 8x4 GB Corsair Vengeance
VGA : NVIDIA GTX 1660 Super
Storage

SAMSUNG 850 EVO 250 GB (boot)
Seagate 2000 GB Hard drive
Crucial P1 1000GB

Below is 5 minidump files from the BSOD I had today

Microsoft OneDrive

1drv.ms

Thank you for reading.

ubuysa · Apr 28, 2023

Three of the dumps clearly show Panda Security is the likely issue. The drivers PSINReg.sys and PSINProt.sys appear in the call stack. The other two dumps are inconclusive, but that doesn't mean they're not caused by Panda though.

The versions of these two drivers that you have installed are old...

Code:

11: kd> lmDvmPSINReg
Browse full module list
start             end                 module name
fffff807`7b550000 fffff807`7b570000   PSINReg  T (no symbols)        
    Loaded symbol image file: PSINReg.sys
    Image path: PSINReg.sys
    Image name: PSINReg.sys
    Browse all global symbols  functions  data
    Timestamp:        Tue Jun  4 19:34:11 2019 (5CF69D83)
    CheckSum:         0002A629
    ImageSize:        00020000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

10: kd> lmDvmPSINProt
Browse full module list
start             end                 module name
fffff800`34400000 fffff800`34428000   PSINProt T (no symbols)        
    Loaded symbol image file: PSINProt.sys
    Image path: PSINProt.sys
    Image name: PSINProt.sys
    Browse all global symbols  functions  data
    Timestamp:        Tue Jun  4 19:41:34 2019 (5CF69F3E)
    CheckSum:         000328E7
    ImageSize:        00028000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

You could look for updated drivers for Panda Security but in all honesty you're better off without it. I've seen all of the third-party antivirus tools cause BSODs over the years, some more often than others. You really don't need anything other than Windows Firewall and Windows Defender - and they're built in to Windows.

One of the dumps references nvlddmkm.sys, your Nvidia graphics driver. The version you have installed is a little old...

Code:

10: kd> lmDvmnvlddmkm
Browse full module list
start             end                 module name
fffff800`3c8d0000 fffff800`3f1f7000   nvlddmkm   (deferred)             
    Image path: nvlddmkm.sys
    Image name: nvlddmkm.sys
    Browse all global symbols  functions  data
    Timestamp:        Thu Mar 17 14:00:43 2022 (623322EB)
    CheckSum:         0285E3FE
    ImageSize:        02927000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

You might want to consider updating that driver to be on the safe side.

thomashouston · Apr 28, 2023

ubuysa said:
Three of the dumps clearly show Panda Security is the likely issue. The drivers PSINReg.sys and PSINProt.sys appear in the call stack. The other two dumps are inconclusive, but that doesn't mean they're not caused by Panda though.

The versions of these two drivers that you have installed are old...

Code:

11: kd> lmDvmPSINReg Browse full module list start end module name fffff807`7b550000 fffff807`7b570000 PSINReg T (no symbols) Loaded symbol image file: PSINReg.sys Image path: PSINReg.sys Image name: PSINReg.sys Browse all global symbols functions data Timestamp: Tue Jun 4 19:34:11 2019 (5CF69D83) CheckSum: 0002A629 ImageSize: 00020000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 Information from resource tables: 10: kd> lmDvmPSINProt Browse full module list start end module name fffff800`34400000 fffff800`34428000 PSINProt T (no symbols) Loaded symbol image file: PSINProt.sys Image path: PSINProt.sys Image name: PSINProt.sys Browse all global symbols functions data Timestamp: Tue Jun 4 19:41:34 2019 (5CF69F3E) CheckSum: 000328E7 ImageSize: 00028000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 Information from resource tables:

You could look for updated drivers for Panda Security but in all honesty you're better off without it. I've seen all of the third-party antivirus tools cause BSODs over the years, some more often than others. You really don't need anything other than Windows Firewall and Windows Defender - and they're built in to Windows.

One of the dumps references nvlddmkm.sys, your Nvidia graphics driver. The version you have installed is a little old...

Code:

10: kd> lmDvmnvlddmkm Browse full module list start end module name fffff800`3c8d0000 fffff800`3f1f7000 nvlddmkm (deferred) Image path: nvlddmkm.sys Image name: nvlddmkm.sys Browse all global symbols functions data Timestamp: Thu Mar 17 14:00:43 2022 (623322EB) CheckSum: 0285E3FE ImageSize: 02927000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 Information from resource tables:

You might want to consider updating that driver to be on the safe side.

thank you for answering.
I have removed Panda AV for now, though I have had BSODs occur even before Panda was installed.

ubuysa · Apr 28, 2023

Then update your Nvidia graphics driver.

thomashouston · Apr 29, 2023

@ubuysa
removed Panda and updated VGA driver, still BSOD

below is the new minidump files from latest crash

Minidumps_2.zip

Compressed (zipped) Folder

1drv.ms

@hizoto
I had Panda, removed it on ubuysa's suggestion.
my RAM is on 3200 MHz already

ubuysa · Apr 29, 2023

Both BSODs were whilst your were using Firefox, although neither dump provides any useful clues. It's not uncommon for browser extensions to go rogue and cause problems, so I'd suggest you start Firefox in troubleshooting mode. Do whatever you were doing when the two previous BSODs happened and see whether you can make it BSOD again. If it won't BSOD in troubleshooting mode then try disabling/uninstalling browser extensions one at a time to try and locate the problem one.

You do have some older drivers installed, but let's see whether this is a Firefox issue first.

thomashouston · Apr 29, 2023

ubuysa said:
Both BSODs were whilst your were using Firefox, although neither dump provides any useful clues. It's not uncommon for browser extensions to go rogue and cause problems, so I'd suggest you start Firefox in troubleshooting mode. Do whatever you were doing when the two previous BSODs happened and see whether you can make it BSOD again. If it won't BSOD in troubleshooting mode then try disabling/uninstalling browser extensions one at a time to try and locate the problem one.

You do have some older drivers installed, but let's see whether this is a Firefox issue first.

I will try it.
Though I have tried leaving the PC idle (no program running) on windows normal mode and safe mode and I got BSOD during that.
I even got BSOD during windows install...

ubuysa · Apr 29, 2023

thomashouston said:
I will try it.
Though I have tried leaving the PC idle (no program running) on windows normal mode and safe mode and I got BSOD during that.
I even got BSOD during windows install...

Ah, then in that case we'd best check your RAM before we do anything else. Download Memtest86 and use the extracted tool to make a bootable USB drive (it can be a small drive). You then boot that USB drive and Memtest86 will start running. Allow it to complete all four iterations of the 13 different tests. If it reports no erros than restart Memtest86 and run another four iterations.

thomashouston · Apr 30, 2023

ubuysa said:
Ah, then in that case we'd best check your RAM before we do anything else. Download Memtest86 and use the extracted tool to make a bootable USB drive (it can be a small drive). You then boot that USB drive and Memtest86 will start running. Allow it to complete all four iterations of the 13 different tests. If it reports no erros than restart Memtest86 and run another four iterations.

run the test twice, no error reported on both test.
only 1 report saved, I pressed the wrong key when asked about the report

MemTest86-Report-20230430-214433.html

HTML Document

1drv.ms

ubuysa · May 1, 2023

Ok, though that doesn't prove that your RAM is good, but it does mean it's not an immediate suspect. We need to find the driver that's causing these BSODs then, and the best way to do that is to enable Driver Verifier.

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, that will 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 the initial Driver Verifier 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.

thomashouston · May 2, 2023

ubuysa said:
Ok, though that doesn't prove that your RAM is good, but it does mean it's not an immediate suspect. We need to find the driver that's causing these BSODs then, and the best way to do that is to enable Driver Verifier.

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, that will 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 the initial Driver Verifier 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.

here is the minidump files after running verifier for 24 hours

Minidumps_verifier.zip

Compressed (zipped) Folder

1drv.ms

ubuysa · May 2, 2023

None of those dumps were triggered by Driver Verifier and that suggests this is more likely to be a hardware issue. In addition, none of the dumps have any third-party drivers on their call stacks, that again suggests these BSODs are more likely caused by hardware.

All these dumps however, do suggest that you may have a hardware issue. I'll try an explain why I think that....

One of the BDOSs happened because an attempt was made to execute a privileged instruction (exception code 0xC0000096), but the executing function was a Windows function (nt!KeAcquireSpinLockAtDpcLevel) and Windows modules don't make those kinds of error.

Another BSOD happened because an attempt was made to access an invalid page (paged out or not allocated) whilst running at an elevated IRQL (IRQL_NOT_LESS_OR_EQUAL), but the executing function was a Windows function (nt!KeAcquireSpinLockAtDpcLevel) and Windows modules don't make those kinds of error.

The third dump happened because the page frame number list was corrupted (PFN_LIST_CORRUPT) which is usually a driver error, yet the executing function was a Windows function (dxgmms2!VidSchIsVSyncEnabled) and Windows modules don't make those kinds of error.

The final BSOD also happened because the page frame number list was corrupted (PFN_LIST_CORRUPT) which is usually a driver error, yet the executing function was a Windows function (Ntfs!NtfsNonCachedIo) and Windows modules don't make those kinds of error.

The two most likely causes of these kinds of hardware error are the CPU and RAM.

I know we've tested your RAM with Memtest, but that's not 100% accurate (no RAM tester can be). The most reliable way to test your RAM is to remove one stick and run on the other three for a few days or until you get a BSOD. Then swap that stick with another one until you have run without each RAM stick for a few days and it BSODs every time. Then we know it's not your RAM.

To test your CPU I would suggest you run Prime95, which will stress test your CPU. You will need to run some sort of temperature monitor (like RealTemp) and stop Prime95 if your CPU temp rises close to Tmax (95C for your CPU).

When you run Prime95, run Small FFTs, In-place large FFTs, and Blend for a few hours each - run them one at a time, not together. If CPU temperatures reach dangerous levels, if the system crashes, or if hardware errors are discovered by the diagnostics then you likely have a faulty CPU.

thomashouston · May 2, 2023

ubuysa said:
None of those dumps were triggered by Driver Verifier and that suggests this is more likely to be a hardware issue. In addition, none of the dumps have any third-party drivers on their call stacks, that again suggests these BSODs are more likely caused by hardware.

All these dumps however, do suggest that you may have a hardware issue. I'll try an explain why I think that....

One of the BDOSs happened because an attempt was made to execute a privileged instruction (exception code 0xC0000096), but the executing function was a Windows function (nt!KeAcquireSpinLockAtDpcLevel) and Windows modules don't make those kinds of error.

Another BSOD happened because an attempt was made to access an invalid page (paged out or not allocated) whilst running at an elevated IRQL (IRQL_NOT_LESS_OR_EQUAL), but the executing function was a Windows function (nt!KeAcquireSpinLockAtDpcLevel) and Windows modules don't make those kinds of error.

The third dump happened because the page frame number list was corrupted (PFN_LIST_CORRUPT) which is usually a driver error, yet the executing function was a Windows function (dxgmms2!VidSchIsVSyncEnabled) and Windows modules don't make those kinds of error.

The final BSOD also happened because the page frame number list was corrupted (PFN_LIST_CORRUPT) which is usually a driver error, yet the executing function was a Windows function (Ntfs!NtfsNonCachedIo) and Windows modules don't make those kinds of error.

The two most likely causes of these kinds of hardware error are the CPU and RAM.

I know we've tested your RAM with Memtest, but that's not 100% accurate (no RAM tester can be). The most reliable way to test your RAM is to remove one stick and run on the other three for a few days or until you get a BSOD. Then swap that stick with another one until you have run without each RAM stick for a few days and it BSODs every time. Then we know it's not your RAM.

To test your CPU I would suggest you run Prime95, which will stress test your CPU. You will need to run some sort of temperature monitor (like RealTemp) and stop Prime95 if your CPU temp rises close to Tmax (95C for your CPU).

When you run Prime95, run Small FFTs, In-place large FFTs, and Blend for a few hours each - run them one at a time, not together. If CPU temperatures reach dangerous levels, if the system crashes, or if hardware errors are discovered by the diagnostics then you likely have a faulty CPU.

I run prime95 small test and the temp reach ~95C on the CCD within 10 minutes.
so I stopped the test then.
should I let the test run until all of the CPU cores got close to 95C?

prime95-small-test.png

PNG Image

1drv.ms

also, I am not sure if this is important,
I notice often the firefox tab crashed or straight up BSOD during typing such as this answer than letting youtube run or running other program. I think I got BSOD 2 times during typing answer on this forum once.

ubuysa · May 2, 2023

That's unusual. AFAIK Prime95 should run indefinitely on a stable CPU.

Can you check your CPU temps during normal operation please? How hot does it get?

thomashouston · May 2, 2023

ubuysa said:
That's unusual. AFAIK Prime95 should run indefinitely on a stable CPU.

Can you check your CPU temps during normal operation please? How hot does it get?

I stopped the test myself.
I see the temp reach 95C and got a little freaked out.
Should I let it run until BSOD occur?
On my normal use usually it is ~50C.

ubuysa · May 2, 2023

I wouldn't want to suggest you push your CPU thermals to what might be dangerous levels.

Let's do the safer thing for now then, and remove one stick of RAM for a few days (or until a BSOD occurs), then swap sticks.

If you want to upload the dumps for the BSODs you just had I'll take a look and see whether they confirm my suspicions.

thomashouston · May 3, 2023

I am using just 2 sticks of RAM now, and I got BSOD.

050323-6093-01.dmp

DMP File

1drv.ms

Do you need specifically 3 ram sticks or 2 is fine?

I also borrowed an 8GB ram stick from a friend and still got BSOD

050323-6109-01.dmp

DMP File

1drv.ms

ubuysa · May 3, 2023

Ah, now this dump is interesting. It's a VIDEO_DXGKRNL_FATAL_ERROR bugcheck, which is very rare. The dxgkrnl.sys driver is a Microsoft DirectX kernel driver, so the driver itself is not suspect and you recently updated the Nvidia driver (nvlddmkm.sys) to the most recent version. This is very likely a graphics card problem then and could well be the hardware that I suspected from earlier dumps.

In the call stack in this dump you can see what's happened...

Code:

10: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffff898e`a7e84488 fffff807`5d7c3ad0     nt!KeBugCheckEx
01 ffff898e`a7e84490 fffff807`5d629f39     watchdog!WdLogEvent5_WdCriticalError+0xe0
02 ffff898e`a7e844d0 fffff807`5d508b39     dxgkrnl!DXGADAPTER::DdiEscape+0x1a9
03 ffff898e`a7e84580 fffff807`5940f3f8     dxgkrnl!DxgkEscape+0x1879
04 ffff898e`a7e84b00 00007ffd`6ffb4be4     nt!KiSystemServiceCopyEnd+0x28
05 00000000`1230f358 00000000`00000000     0x00007ffd`6ffb4be4

The dxgkrnl!DXGADAPTER::diEscape function call looks like a call to dxgkrnl.sys to access the adapter (the graphics card) and something goes wrong, causing the watchdog to bugcheck. If we look more closely at that dxgkrnl.sys function call...

Code:

10: kd> .frame /r 02
02 ffff898e`a7e844d0 fffff807`5d508b39     dxgkrnl!DXGADAPTER::DdiEscape+0x1a9
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000113
rdx=0000000000000026 rsi=ffffd40c00a0d4b0 rdi=ffffd40bf9364000
rip=fffff8075d629f39 rsp=ffff898ea7e844d0 rbp=ffff898ea7e84550
 r8=0000000000000000  r9=000000005d509e4d r10=fffff807593fbc10
r11=000000000000000f r12=0000000000000000 r13=ffffd40bf9364000
r14=fffff8075d509e4d r15=ffff898ea7e846b8
iopl=0         nv up ei ng nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00040282
dxgkrnl!DXGADAPTER::DdiEscape+0x1a9:
fffff807`5d629f39 f0ff8f0c110000  lock dec dword ptr [rdi+110Ch] ds:002b:ffffd40b`f936510c=????????

You can see that the address that the DEC instruction is acting on is invalid (the ????????). It's an address pointed to by the contents of the RDI register plus 0x110C. One possibility is that the driver has messed up the pointer value in the RDI register, but you recently updated the Nvidia driver. The other possibility is that a graphics card failure has caused the graphics driver to mess up the pointer. Since earlier dumps are suggesting a hardware cause, we must now focus on the graphics card.

I did take a look at the second dump, though borrowing RAM means the dump is largely useless. We don't know, for example, whether it's compatible with your board and/or CPU.

Running RAM two sticks at a time is a good idea. Try swapping with the other two sticks and see what difference that makes.

BTW are you sure you didn't disturb the graphics card slightly when you were adding/removing RAM sticks? You might try removing the graphics card and then re-inserting it fully.

thomashouston · May 4, 2023

ubuysa said:
Ah, now this dump is interesting. It's a VIDEO_DXGKRNL_FATAL_ERROR bugcheck, which is very rare. The dxgkrnl.sys driver is a Microsoft DirectX kernel driver, so the driver itself is not suspect and you recently updated the Nvidia driver (nvlddmkm.sys) to the most recent version. This is very likely a graphics card problem then and could well be the hardware that I suspected from earlier dumps.

In the call stack in this dump you can see what's happened...

Code:

10: kd> knL # Child-SP RetAddr Call Site 00 ffff898e`a7e84488 fffff807`5d7c3ad0 nt!KeBugCheckEx 01 ffff898e`a7e84490 fffff807`5d629f39 watchdog!WdLogEvent5_WdCriticalError+0xe0 02 ffff898e`a7e844d0 fffff807`5d508b39 dxgkrnl!DXGADAPTER::DdiEscape+0x1a9 03 ffff898e`a7e84580 fffff807`5940f3f8 dxgkrnl!DxgkEscape+0x1879 04 ffff898e`a7e84b00 00007ffd`6ffb4be4 nt!KiSystemServiceCopyEnd+0x28 05 00000000`1230f358 00000000`00000000 0x00007ffd`6ffb4be4

The dxgkrnl!DXGADAPTER::diEscape function call looks like a call to dxgkrnl.sys to access the adapter (the graphics card) and something goes wrong, causing the watchdog to bugcheck. If we look more closely at that dxgkrnl.sys function call...

Code:

10: kd> .frame /r 02 02 ffff898e`a7e844d0 fffff807`5d508b39 dxgkrnl!DXGADAPTER::DdiEscape+0x1a9 rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000113 rdx=0000000000000026 rsi=ffffd40c00a0d4b0 rdi=ffffd40bf9364000 rip=fffff8075d629f39 rsp=ffff898ea7e844d0 rbp=ffff898ea7e84550 r8=0000000000000000 r9=000000005d509e4d r10=fffff807593fbc10 r11=000000000000000f r12=0000000000000000 r13=ffffd40bf9364000 r14=fffff8075d509e4d r15=ffff898ea7e846b8 iopl=0 nv up ei ng nz na pe nc cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00040282 dxgkrnl!DXGADAPTER::DdiEscape+0x1a9: fffff807`5d629f39 f0ff8f0c110000 lock dec dword ptr [rdi+110Ch] ds:002b:ffffd40b`f936510c=????????

You can see that the address that the DEC instruction is acting on is invalid (the ????????). It's an address pointed to by the contents of the RDI register plus 0x110C. One possibility is that the driver has messed up the pointer value in the RDI register, but you recently updated the Nvidia driver. The other possibility is that a graphics card failure has caused the graphics driver to mess up the pointer. Since earlier dumps are suggesting a hardware cause, we must now focus on the graphics card.

I did take a look at the second dump, though borrowing RAM means the dump is largely useless. We don't know, for example, whether it's compatible with your board and/or CPU.

Running RAM two sticks at a time is a good idea. Try swapping with the other two sticks and see what difference that makes.

BTW are you sure you didn't disturb the graphics card slightly when you were adding/removing RAM sticks? You might try removing the graphics card and then re-inserting it fully.

switched to the other 2 ram sticks, still BSOD. here is the minidump files

Minidumps_4.zip

Compressed (zipped) Folder

1drv.ms

I removed and re-inserted the VGA card too before the BSOD

ubuysa · May 5, 2023

Firstly, can you please download Speccy (you can download the portable version if you don't want to install it). Run Speccy and let it analyse your system. Then click File > Publish snapshot. You'll be given a URL, please post that there. That will help us see exactly what system and software you are running.

One of the dumps is clear cut (050523-6437-01.dmp) this is a straightforward IRQL_NOT_LESS_OR_EQUAl, meaning a driver has accessed a virtual page that's paged out or not allocated (or is bad) whilst running at an elevated IRQL. This bugcheck is almost always a third-party driver misbehaving and getting its memory pointers messed up. That's what has happened here. If we look at the trap frame you can see that the instruction pointer - the RIP register - (which points to the next instruction to be executed) is pointing at address 0x1 - and that's clearly invalid...

Code:

TRAP_FRAME:  ffff9482bc637240 -- (.trap 0xffff9482bc637240)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=000000000000000a
rdx=0000000000000002 rsi=0000000000000000 rdi=0000000000000000
rip=0000000000000001 rsp=ffff9482bc6373d0 rbp=0000000000000000
 r8=ffff92f8d9200290  r9=0000000000000004 r10=0000000000000070
r11=000000000000000a r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
00000000`00000001 ??              ???
Resetting default scope

The question is, which third-party driver did this? The call stack gives us the answer...

Code:

10: kd> !dpx
Start memory scan  : 0xffff9482bc6370f8 ($csp)
End memory scan    : 0xffff9482bc638000 (Kernel Stack Base)

               rsp : 0xffff9482bc6370f8 : 0xfffff80353c0fc29 : nt!KiBugCheckDispatch+0x69
               r11 : 0xffff9482bc637238 : 0xfffff80353c0b7e3 : nt!KiPageFault+0x463
Unable to load image Ld9VMMR0.r0, Win32 error 0n2
*** WARNING: Unable to verify timestamp for Ld9VMMR0.r0
0xffff9482bc6370f8 : 0xfffff80353c0fc29 : nt!KiBugCheckDispatch+0x69
0xffff9482bc637238 : 0xfffff80353c0b7e3 : nt!KiPageFault+0x463
0xffff9482bc637240 : 0xfffff80300000002 :  Trap @ ffff9482bc637240
0xffff9482bc637728 : 0xfffff80353a17a42 : nt!ExFreeHeapPool+0x362
Unable to load image Ld9BoxSup.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for Ld9BoxSup.sys
0xffff9482bc637890 : 0x6269726464726962 :  !da "birddrib"
0xffff9482bc637898 : 0xfffff80353a1eaba : nt!IopReferenceFileObject+0x3a
0xffff9482bc6378a8 : 0xfffff80353a211fe : nt!HalPutDmaAdapter+0xe
0xffff9482bc6378d8 : 0xfffff80353e10206 : nt!IopXxxControlFile+0x706
0xffff9482bc637a18 : 0xfffff80353e0fae6 : nt!NtDeviceIoControlFile+0x56
0xffff9482bc637a80 : 0xfffff80353e0fa90 : nt!NtDeviceIoControlFile
0xffff9482bc637a88 : 0xfffff80353c0f3f8 : nt!KiSystemServiceCopyEnd+0x28
0xffff9482bc637af8 : 0xfffff80353c0f3f8 : nt!KiSystemServiceCopyEnd+0x28
0xffff9482bc637b00 : 0xffffb08c838ef080 :  Trap @ ffff9482bc637b00

The Ld9BoxSup.sys driver is the only third-party driver called. It's related to the LDPlayer and it's almost a year old...

Code:

10: kd> lmDvmLd9BoxSup
Browse full module list
start             end                 module name
fffff803`bb130000 fffff803`bb1a3000   Ld9BoxSup T (no symbols)          
    Loaded symbol image file: Ld9BoxSup.sys
    Image path: Ld9BoxSup.sys
    Image name: Ld9BoxSup.sys
    Browse all global symbols  functions  data
    Timestamp:        Tue Jul 26 11:53:02 2022 (62DFAB6E)
    CheckSum:         00067628
    ImageSize:        00073000
    Translations:     0000.04b0 0000.04e4 0409.04b0 0409.04e4
    Information from resource tables:

I would suggest you look for an updated version of LDPlayer or uninstall it.

The other dump (050523-7593-01.dmp) isn't as clear cut. There are no third-party drivers on the call stack, that generally points more at a hardware cause. We can see that this BSOD happened during disk access...

Code:

11: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffbb82`624366b8 fffff805`3140fc29     nt!KeBugCheckEx
01 ffffbb82`624366c0 fffff805`3140b7e3     nt!KiBugCheckDispatch+0x69
02 ffffbb82`62436800 fffff805`31223822     nt!KiPageFault+0x463
03 ffffbb82`62436990 fffff805`31221d49     nt!KxReleaseQueuedSpinLock+0x32
04 ffffbb82`624369c0 fffff805`3400c220     nt!ExAcquireResourceExclusiveLite+0xd9
05 ffffbb82`62436a50 fffff805`3400bfcc     Ntfs!NtfsAcquireExclusiveFcb+0x90
06 ffffbb82`62436ad0 fffff805`340ef458     Ntfs!NtfsAcquireFcbWithPaging+0xac
07 ffffbb82`62436b40 fffff805`340ef92c     Ntfs!NtfsFindPrefixHashEntry+0xb08
08 ffffbb82`62436c90 fffff805`340f09d0     Ntfs!NtfsFindStartingNode+0x25c
09 ffffbb82`62436d80 fffff805`340ebe7b     Ntfs!NtfsCommonCreate+0x580
0a ffffbb82`62437060 fffff805`31211385     Ntfs!NtfsFsdCreate+0x1db
0b ffffbb82`624372e0 fffff805`2dc8710f     nt!IofCallDriver+0x55
0c ffffbb82`62437320 fffff805`2dcb9f54     FLTMGR!FltpLegacyProcessingAfterPreCallbacksCompleted+0x28f
0d ffffbb82`62437390 fffff805`31211385     FLTMGR!FltpCreate+0x324
0e ffffbb82`62437440 fffff805`3120d944     nt!IofCallDriver+0x55
0f ffffbb82`62437480 fffff805`315ff58b     nt!IoCallDriverWithTracing+0x34
10 ffffbb82`624374d0 fffff805`3161501e     nt!IopParseDevice+0x11bb
11 ffffbb82`62437640 fffff805`3160ccea     nt!ObpLookupObjectName+0x3fe
12 ffffbb82`62437810 fffff805`315fd0ac     nt!ObOpenObjectByNameEx+0x1fa
13 ffffbb82`62437940 fffff805`315fbd69     nt!IopCreateFile+0x132c
14 ffffbb82`62437a00 fffff805`3140f3f8     nt!NtCreateFile+0x79
15 ffffbb82`62437a90 00007ffd`f4f0db04     nt!KiSystemServiceCopyEnd+0x28
16 0000006d`d1f7bb98 00000000`00000000     0x00007ffd`f4f0db04

Notice the calls to ntfs.sys in the call stack above. This is a Windows driver, so it's not at fault, but there are preceding calls to fltmgr.sys (you read these stacks from the bottom up). Filter drivers are installed by apps (and by system functions) to modify the driver functionality in some way. Antivirus tools are one example of apps that add filter drivers to the disk access driver stack. This is why I've asked for the Speccy output link.

Can you also please export and upload your System and Application logs....

1. Enter the command eventvwr into the Run command box. The Event Viewer will open.
2. Locate the Windows Logs folder in the left hand pane and expand it by clicking on the arrow (>) to the left of it.
3. Right-click on the Application entry and select 'Save all events as...'. Choose a folder anywhere that suits you and a filename of 'Application' (an .evtx suffix will be added automatically).
4. Right-click on the System entry and select 'Save all events as...'. Choose a folder anywhere that suits you and a filename of 'System' (an .evtx suffix will be added automatically).
5. Zip the Application.evtx and System.evtx files together and upload the zip file here.

thomashouston · May 5, 2023

speccy link

http://speccy.piriform.com/results/jv367MqLlUH2TKYyeavkE5E

event viewer log here

Event_viewer.7z

7Z File

1drv.ms

ubuysa · May 6, 2023

I don't see anything alarming in your Speccy output, except that the RAM speed is shown as 2133MHz, but I think that's the base clock speed and not the speed it's actually running at. Others might be able to confirm/refute that?

There is nothing in your System log to indicate that these BSODs are anything other than hardware, which is also what many of your dumps are pointing to. We know it's not RAM, and that you CPU overheats quickly running Prime95 is very suspicious.

You might want to try using AIDA64 to test your CPU, it uses more realistic workloads. It's not free but there is a 30 day trial period, although there is some limited functionality during the trial. There are other AMD CPU stress testing tools here.

At the moment my feeling is that this is likely a CPU problem, but you can't prove that from analysing dumps, only by stress testing the CPU.

thomashouston · May 6, 2023

ubuysa said:
I don't see anything alarming in your Speccy output, except that the RAM speed is shown as 2133MHz, but I think that's the base clock speed and not the speed it's actually running at. Others might be able to confirm/refute that?

There is nothing in your System log to indicate that these BSODs are anything other than hardware, which is also what many of your dumps are pointing to. We know it's not RAM, and that you CPU overheats quickly running Prime95 is very suspicious.

You might want to try using AIDA64 to test your CPU, it uses more realistic workloads. It's not free but there is a 30 day trial period, although there is some limited functionality during the trial. There are other AMD CPU stress testing tools here.

At the moment my feeling is that this is likely a CPU problem, but you can't prove that from analysing dumps, only by stress testing the CPU.

in task manager, ram speed is shown to be 2133 MHz, so I think it is the actual running speed.
3200 MHz is only if XMP is enabled, which is disabled right now.

from this post, https://forums.tomshardware.com/thr...ach-100-c-with-prime95.3595966/#post-21698711, apparently it is "understandable" the temp gets so high so quickly. only found 1 though, so it's an anecdotal experience.
I did find many post about 90C or above temp running prime95 on this processor on stock cooler.

I ran cinebench23 10 minutes and 30 minutes test, both ends with 87C max.
will run other test later on.

ubuysa · May 7, 2023

The only other thing you can do is to enable Driver Verifier again, in the same way I showed you, and leave it running for a much longer period to try and catch a flaky third-party driver. If it still doesn't BSOD any third-party drivers then this is almost certainly a hardware problem. We know it's not RAM, so that really only leaves the CPU, the motherboard, or the PSU...

I'm no hardware expert so if an extended Driver Verifier run doesn't catch any third-party drivers you need the help of someone more experienced in hardware troubleshooting than I am.

Question Frequent BSOD crashing with different reason each time ?

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Distinguished

Share this page