Question Random BSODs over the last few weeks ?

May 29, 2024
9
0
10
Hi All

I have been having recurring BSODS's over the last few weeks and I am at a point where I'm not sure what to do next to try and resolve the problem.
I get different error messages on the BSOD with some recurring more frequently than others

I have tried the following things but am still having the problems:

Hardware:

  • Removed GFX card (3090)
  • Removed each stick of ram
  • Removed Primary SSD - tried to boot to USB for and i got a BSOD
  • Removed Secondary SSD's
  • Changed Bios settings to default
  • Unplugged all USB devices except for Keyboard/ mouse and headset

Windows:
  • Run DISM
  • Run SFC - worked once and now gives Windows Resource Protection could not perform the requested operation when I run it via cmd prompt with admin rights.

I can post the .DMP files if that is helpful. I have tried reading them using WinDBG but I'm not well versed with them and I cant work out the issue.

Is anyone able to offer some advice? Any help is appreciated.

EDIT: i have also started getting crashes in Microsoft Edge - Error code: STATUS_ACCESS_VIOLATION,
I'm not sure if its related or something separate.
 
Last edited:
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 . . .
 
I appreciate that you've removed each stick of RAM as a test, but taken collectively these dumps all point at RAM. There are no third-party drivers referenced in any of them and they fail with different bugchecks and in different operations, several of them fail during memory access operations too.

Would you please run Memtest86 on your RAM just to check...
  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.
Also please download and run the SysnativeBSODCollectionApp and upload the resulting zip file to a cloud service with a link to it here. The SysnativeBSODCollectionApp collects all the troubleshooting data we're likely to need. It DOES NOT collect any personally identifying data. It's used by several highly respected Windows help forums (including this one). I'm a senior BSOD analyst on the Sysnative forum where this tool came from, so I know it to be safe.

You can of course look at what's in the zip file before you upload it, most of the files are txt files. Please don't change or delete anything though. If you want a description of what each file contains you'll find that here.
 
I had trouble getting MemTest86 to boot from USB so I ran it from my BIOS (V10.0 Free (Build 1000))

Took 10 hours, zero errors, # tests passed 40/40.

I will run it again overnight to confirm. Then run the SysnativeBSODCollectionApp.
 
I had trouble getting MemTest86 to boot from USB so I ran it from my BIOS (V10.0 Free (Build 1000))
What sort of trouble? Did you make the boot USB drive as described above? Did you make it first in the boot order? What happened when it tried to boot?

Memtest86 boots fine in a UEFI environment (which is what you're running), that you can't get it to boot may well be a symptom, so we need to know what happens.

Based on the dumps and what I'm seeing in your logs, I still think that RAM is the most likely cause. I'm also a tad confused, in your OP you said this...
Removed each stick of ram
But I can now see that you only have a single 32GB RAM stick installed in slot A2. What are you not telling us here?

BTW. Most of us contribute to many forums, so keeping it here is fine. Cross-posting isn't encouraged.
 
What sort of trouble? Did you make the boot USB drive as described above? Did you make it first in the boot order? What happened when it tried to boot?

Memtest86 boots fine in a UEFI environment (which is what you're running), that you can't get it to boot may well be a symptom, so we need to know what happens.

Based on the dumps and what I'm seeing in your logs, I still think that RAM is the most likely cause. I'm also a tad confused, in your OP you said this...

But I can now see that you only have a single 32GB RAM stick installed in slot A2. What are you not telling us here?

BTW. Most of us contribute to many forums, so keeping it here is fine. Cross-posting isn't encouraged.
I created the USB fine. When I choose the usb as first in boot order, the lights blinks once or twice on the usb stick while its trying to boot, then it just loads windows from the SSD. No error appears.

I should have mentioned i had a similar problem earlier when trying a windows 11 USB to try and repair my installation. It would skip the USB and go to SSD.

EDIT: I tried again, disabling the SSD and only having the USB in the boot sequence, it just went back to my bios after trying to restart.

I have two 32gb sticks of RAM, after taking one out, then taking the other out for testing i have just left the machine with only one stick in it. I can put the other back in and get logs when it BSOD's with both installed if that would help.
 
Last edited:
That booting from USB issue is a problem and could well be connected to these random BSODs. However, I've just realised that you have an i9-13900K CPU and there is a known issue with those (and the i9-14900K), see https://www.tomshardware.com/pc-com...blame-other-high-end-intel-cpus-also-affected. There is a recent BIOS update (2301) with mitigations to address this issue. If this were mine I think I'd upgrade to that BIOS and then see how things go, because this looks very much like a hardware problem to me.

In addition, the two 32GB RAM sticks you have installed are not on the QVL for the motherboard. When you're getting BSODs that may be RAM related that too is a worry.
 
That booting from USB issue is a problem and could well be connected to these random BSODs. However, I've just realised that you have an i9-13900K CPU and there is a known issue with those (and the i9-14900K), see https://www.tomshardware.com/pc-com...blame-other-high-end-intel-cpus-also-affected. There is a recent BIOS update (2301) with mitigations to address this issue. If this were mine I think I'd upgrade to that BIOS and then see how things go, because this looks very much like a hardware problem to me.

In addition, the two 32GB RAM sticks you have installed are not on the QVL for the motherboard. When you're getting BSODs that may be RAM related that too is a worry.
Thanks for all the help.

I have just updated to the latest bios and used the default intel settings.

Ill run the pc for a few hours and see if that has resolved the issue.
 
Still getting BSOD after the BIOS update (although perhaps less often? could just be a perception thing)

Tried a new stick of RAM as well, and have had one BSOD since i installed it.

If you have any other ideas im willing to try them :).
 
I would join an Intel forum regarding the i9-13900K issues and make your voice heard. It's really hard to know what to suggest when we already know that that CPU has a potential flaw. I don;t know how successful those BIOS mitigations are supposed to be, AFAIK Intel and the motherboard vendors are still blaming each other.

Despite this looking very much like a hardware problem it might be worth your enabling Driver Verifier. In the unlikely event that this is a rogue driver we should be able to catch it with Driver Verifier - don't hold your breath though...

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
These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

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 for 48 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. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing. The Driver Verifier generated BSODs are these...
  • 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
  • 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
  • 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
  • 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
  • 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
  • 0xE6: DRIVER_VERIFIER_DMA_VIOLATION
If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

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. If drivers are listed then it's enabled, if no drivers are listed then it's not.

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 if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).
 
I would join an Intel forum regarding the i9-13900K issues and make your voice heard. It's really hard to know what to suggest when we already know that that CPU has a potential flaw. I don;t know how successful those BIOS mitigations are supposed to be, AFAIK Intel and the motherboard vendors are still blaming each other.

Despite this looking very much like a hardware problem it might be worth your enabling Driver Verifier. In the unlikely event that this is a rogue driver we should be able to catch it with Driver Verifier - don't hold your breath though...

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
These are high-level Microsoft drivers that manage lower-level third-party drivers that we otherwise wouldn't be able to trap. That's why they're included.

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 for 48 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. If Windows doesn't automatically reboot after each BSOD then just reboot as normal and continue testing. The Driver Verifier generated BSODs are these...
  • 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
  • 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION
  • 0xC6: DRIVER_CAUGHT_MODIFYING_FREED_POOL
  • 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION
  • 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION
  • 0xE6: DRIVER_VERIFIER_DMA_VIOLATION
If you see any of these BSOD types then you can disable Driver Verifier early because you'll have caught a misbehaving driver.

Note: Because Driver Verifier is doing extra work each time a third-party driver is loaded you will notice some performance degradation with Driver Verifier enabled. This is a price you'll have to pay in order to locate any flaky drivers. And remember, Driver Verifier can only test drivers that are loaded, so you need to ensure that every third-party driver gets loaded by using all apps, features and devices.

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. If drivers are listed then it's enabled, if no drivers are listed then it's not.

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 if you like, or not as you choose. Upload the file(s) to the cloud with a link to it/them here (be sure to make it public).
Thanks for your help with this.

I have joined an Intel forum and have turned on driver verifier as well.