BSOD ntoskrnl.exe IRQL_NOT_LESS_OR_EQUAL

[Channji]

Hi, I purchased this PC from PCS around 6 month ago and had no issues until recently.
Been having repetitive BSODs with the error codes in the title, ranging from hours after start-up to 2 minutes after logging in.
Have been trying solutions I found online the past few days; commands in the prompt, memory diagnostic test and windows reset to no avail.
Working on posting my minidump files. For now heres my build:
Case
PCS PRISM TG BLACK ARGB MID TOWER CASE
Processor (CPU)
Intel® Core™ i7 16-Core Processor i7-13700K (Up to 5.4GHz) 30MB Cache
Motherboard
GIGABYTE B760 GAMING X AX DDR4 (LGA1700, DDR4, USB 3.2) - ARGB Ready!
Memory (RAM)
32GB Corsair VENGEANCE RGB PRO DDR4 3600MHz (2 x 16GB)
Graphics Card
16GB NVIDIA GEFORCE RTX 4080 - HDMI, DP, LHR
1st M.2 SSD Drive
1TB SOLIDIGM P41+ GEN 4 M.2 NVMe PCIe SSD (up to 4125MB/sR, 2950MB/sW)
1st Storage Drive
4TB SEAGATE BARRACUDA SATA-III 3.5" HDD, 6GB/s, 5400RPM, 256MB CACHE
DVD/BLU-RAY Drive
NOT REQUIRED
Power Supply
CORSAIR 850W RMx SERIES™ MODULAR 80 PLUS® GOLD, ULTRA QUIET
Power Cable
1 x 1.5 Metre UK Power Cable (Kettle Lead, 1.0mm Core)
Processor Cooling
CORSAIR H100x RGB ELITE HIGH PERFORMANCE CPU COOLER
Thermal Paste
STANDARD THERMAL PASTE FOR SUFFICIENT COOLING
Sound Card
ONBOARD 6 CHANNEL (5.1) HIGH DEF AUDIO (AS STANDARD)
Network Card
ONBOARD LAN PORT
Wireless Network Card
NOT REQUIRED
USB/Thunderbolt Options
MIN. 2 x USB 3.0 & 2 x USB 2.0 PORTS @ BACK PANEL + MIN. 2 FRONT PORTS
Operating System
Windows 11 Home 64 Bit - inc. Single Licence [KUK-00003]
Operating System Language
United Kingdom - English Language
Windows Recovery Media
Windows 10/11 Multi-Language Recovery Image - Unlimited Downloads from Online Account
Office Software
FREE 30 Day Trial of Microsoft 365® (Operating System Required)
Anti-Virus
Norton 360 inc. Game Optimizer - Free 90 Day License
Browser
Microsoft® Edge
Warranty
3 Year Standard Warranty (1 Month Collect & Return, 1 Year Parts, 3 Year Labour)
Delivery
STANDARD INSURED DELIVERY TO UK MAINLAND (MON-FRI)
Build Time
Standard Build - Approximately 9 to 12 working days
Welcome Book
PCSpecialist Welcome Book - United Kingdom & Republic of Ireland

 

[Scott]

I edited your post to remove your Windows key, don't want that getting stolen

If you have a look at the link below it will guide you on how to provide the logs from your system that can be checked here.

When you're seeking help with a BSOD

Don't Panic! Many people panic when they get a BOSD, partly this is because they happen unexpectedly and because they usually happen without warning, but also because many believe they mean you have a hardware problem. The good news is that in the majority of cases a BSOD is a software problem...

www.pcspecialist.co.uk

 

[Channji]

I edited your post to remove your Windows key, don't want that getting stolen

If you have a look at the link below it will guide you on how to provide the logs from your system that can be checked here.

When you're seeking help with a BSOD

Don't Panic! Many people panic when they get a BOSD, partly this is because they happen unexpectedly and because they usually happen without warning, but also because many believe they mean you have a hardware problem. The good news is that in the majority of cases a BSOD is a software problem...

www.pcspecialist.co.uk

yikes ! thats me rushing before another bsod lol, thanks !

 

[ubuysa]

Hello, and welcome to the tech support forum!

The 0xA (IRQL_NOT_LESS_OR_EQUAL) BSOD is almost always caused by a bad (or missing) third party driver. It happens when a page fault occurs whilst the processor is running at an elevated IRQL. A page fault occurs when the referenced memory location is either not allocated, page out, is backed by bad RAM, or because the driver mucked up the memory pointer. The IRQL is a hierarchy that processors use to serialise interrupts, page faults are not allowed when running at an IRQL above 0.

Can you 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.

 

[Channji]

SysnativeFileCollectionApp.zip
hope this works thanks !

Hello, and welcome to the tech support forum!

The 0xA (IRQL_NOT_LESS_OR_EQUAL) BSOD is almost always caused by a bad (or missing) third party driver. It happens when a page fault occurs whilst the processor is running at an elevated IRQL. A page fault occurs when the referenced memory location is either not allocated, page out, is backed by bad RAM, or because the driver mucked up the memory pointer. The IRQL is a hierarchy that processors use to serialise interrupts, page faults are not allowed when running at an IRQL above 0.

Can you 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.

 

[Channji]

Hello, and welcome to the tech support forum!

The 0xA (IRQL_NOT_LESS_OR_EQUAL) BSOD is almost always caused by a bad (or missing) third party driver. It happens when a page fault occurs whilst the processor is running at an elevated IRQL. A page fault occurs when the referenced memory location is either not allocated, page out, is backed by bad RAM, or because the driver mucked up the memory pointer. The IRQL is a hierarchy that processors use to serialise interrupts, page faults are not allowed when running at an IRQL above 0.

Can you 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.

minidumps.zip
in case you still need them, thanks ! another note, just had another BSOD with a new (to me) error code: PAGE_FAULT_IN_NONPAGED-AREA

 

[Channji]

Forgot to mention in the post, have also tried updating windows + drivers

 

[ubuysa]

Yep, that's good. Thanks.

The four dumps uploaded don't highlight any particular third-party driver, although one references nvlddmkm.sys (the Nvidia graphics driver) I think that's coincidence. Taking these four dumps as a group, and including the second 0x50 BSOD you just reported, bad RAM must be a suspect here.

Two of the dumps fail because of a misaligned instruction pointer, this is what points to the next instruction to be executed. It can be messed up by bad drivers, but I'd expect to see the third-party driver responsible in the dump and we don't. The other two dumps fail in the same way, both fail coming out of the idle loop and before any third-party drivers are called.

I suggest you run Memtest86...

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.

However, in addition to the above in your Application log there are many Side-By-Side errors, typically (but not exclusively) for MSI Afterburner (which I believe to be a flaky app in any case)...

Log Name:      Application
Source:        SideBySide
Date:          11/04/2024 14:12:37
Event ID:      33
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Persephonie
Description:
Activation context generation failed for "D:\MSI Afterburner\MSIAfterburner.exe". Dependent Assembly Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

There is also at least one Side-By-Side error for the RivaTuner Statistics Server...

Log Name:      Application
Source:        SideBySide
Date:          11/04/2024 14:00:11
Event ID:      33
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Persephonie
Description:
Activation context generation failed for "D:\RivaTuner Statistics Server\DesktopOverlayHost.exe". Dependent Assembly Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

These Side-By-Side errors indicate a problem accessing specific shared system dlls. Side-By-Side execution is used where several versions of the same dll exist and it's vital that a process references only the correct version. What these erors indicate is that the required dll could not be found.

These might well be related to any RAM error you may have, but they might indicate either an error in your Windows configuration (if the dlls are Microsoft dlls) or a problem with the third-party apps (if they supply different versions of the same dll). I don't think that this would cause a BSOD however, just a crash of the specific app. However, it might be worth fully uninstalling both MSI Afterburner and Riva Tuner and see whether that stops the BSODs.

I'd also suggest opening an elevated command prompt and running the following command...

dism /online /cleanup-image  /checkhealth

If that finds no corruptions then all is good, but if it does find corruptions then run the following command...

dism /online /cleanup-image /restorehealth

If that completes with no errors then all is good, but if you get errors take a screenshot of the output and post that here.

If dism runs clean or fixes any errors then run the following command...

sfc /scannow

If that finds errors and fixes them then all is good (most of the errors that sfc finds are trivial) but if it cannot fix errors post a screenshot of the output.

The dism and sfc commands should fix any Windows issues that might cause these Side-By-Side errors.

Let me know how all that goes. Don't worry if none of this stops the BSODs, there are other troubleshooting tools we can use, but it's important to start with the obvious first.

 

[Channji]

Yep, that's good. Thanks.

The four dumps uploaded don't highlight any particular third-party driver, although one references nvlddmkm.sys (the Nvidia graphics driver) I think that's coincidence. Taking these four dumps as a group, and including the second 0x50 BSOD you just reported, bad RAM must be a suspect here.

Two of the dumps fail because of a misaligned instruction pointer, this is what points to the next instruction to be executed. It can be messed up by bad drivers, but I'd expect to see the third-party driver responsible in the dump and we don't. The other two dumps fail in the same way, both fail coming out of the idle loop and before any third-party drivers are called.

I suggest you run Memtest86...

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.

However, in addition to the above in your Application log there are many Side-By-Side errors, typically (but not exclusively) for MSI Afterburner (which I believe to be a flaky app in any case)...

Log Name:      Application
Source:        SideBySide
Date:          11/04/2024 14:12:37
Event ID:      33
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Persephonie
Description:
Activation context generation failed for "D:\MSI Afterburner\MSIAfterburner.exe". Dependent Assembly Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

There is also at least one Side-By-Side error for the RivaTuner Statistics Server...

Log Name:      Application
Source:        SideBySide
Date:          11/04/2024 14:00:11
Event ID:      33
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Persephonie
Description:
Activation context generation failed for "D:\RivaTuner Statistics Server\DesktopOverlayHost.exe". Dependent Assembly Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

These Side-By-Side errors indicate a problem accessing specific shared system dlls. Side-By-Side execution is used where several versions of the same dll exist and it's vital that a process references only the correct version. What these erors indicate is that the required dll could not be found.

These might well be related to any RAM error you may have, but they might indicate either an error in your Windows configuration (if the dlls are Microsoft dlls) or a problem with the third-party apps (if they supply different versions of the same dll). I don't think that this would cause a BSOD however, just a crash of the specific app. However, it might be worth fully uninstalling both MSI Afterburner and Riva Tuner and see whether that stops the BSODs.

I'd also suggest opening an elevated command prompt and running the following command...

dism /online /cleanup-image  /checkhealth

If that finds no corruptions then all is good, but if it does find corruptions then run the following command...

dism /online /cleanup-image /restorehealth

If that completes with no errors then all is good, but if you get errors take a screenshot of the output and post that here.

If dism runs clean or fixes any errors then run the following command...

sfc /scannow

If that finds errors and fixes them then all is good (most of the errors that sfc finds are trivial) but if it cannot fix errors post a screenshot of the output.

The dism and sfc commands should fix any Windows issues that might cause these Side-By-Side errors.

Let me know how all that goes. Don't worry if none of this stops the BSODs, there are other troubleshooting tools we can use, but it's important to start with the obvious first.

Thank you so much for this !

Have uninstalled the programs you mentioned, will do some testing and see if the system will bsod tomorrow.

I ran the first command you recommended, came back with “No component store corruption detected.
The opertation completed successfully.”

Will do MemTest tomorrow as I have heard it can take a while? No time today unfortunately. Will post back here with an update. Again, thank you !

 

[Channji]

Yep, that's good. Thanks.

The four dumps uploaded don't highlight any particular third-party driver, although one references nvlddmkm.sys (the Nvidia graphics driver) I think that's coincidence. Taking these four dumps as a group, and including the second 0x50 BSOD you just reported, bad RAM must be a suspect here.

Two of the dumps fail because of a misaligned instruction pointer, this is what points to the next instruction to be executed. It can be messed up by bad drivers, but I'd expect to see the third-party driver responsible in the dump and we don't. The other two dumps fail in the same way, both fail coming out of the idle loop and before any third-party drivers are called.

I suggest you run Memtest86...

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.

However, in addition to the above in your Application log there are many Side-By-Side errors, typically (but not exclusively) for MSI Afterburner (which I believe to be a flaky app in any case)...

Log Name:      Application
Source:        SideBySide
Date:          11/04/2024 14:12:37
Event ID:      33
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Persephonie
Description:
Activation context generation failed for "D:\MSI Afterburner\MSIAfterburner.exe". Dependent Assembly Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

There is also at least one Side-By-Side error for the RivaTuner Statistics Server...

Log Name:      Application
Source:        SideBySide
Date:          11/04/2024 14:00:11
Event ID:      33
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Persephonie
Description:
Activation context generation failed for "D:\RivaTuner Statistics Server\DesktopOverlayHost.exe". Dependent Assembly Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

These Side-By-Side errors indicate a problem accessing specific shared system dlls. Side-By-Side execution is used where several versions of the same dll exist and it's vital that a process references only the correct version. What these erors indicate is that the required dll could not be found.

These might well be related to any RAM error you may have, but they might indicate either an error in your Windows configuration (if the dlls are Microsoft dlls) or a problem with the third-party apps (if they supply different versions of the same dll). I don't think that this would cause a BSOD however, just a crash of the specific app. However, it might be worth fully uninstalling both MSI Afterburner and Riva Tuner and see whether that stops the BSODs.

I'd also suggest opening an elevated command prompt and running the following command...

dism /online /cleanup-image  /checkhealth

If that finds no corruptions then all is good, but if it does find corruptions then run the following command...

dism /online /cleanup-image /restorehealth

If that completes with no errors then all is good, but if you get errors take a screenshot of the output and post that here.

If dism runs clean or fixes any errors then run the following command...

sfc /scannow

If that finds errors and fixes them then all is good (most of the errors that sfc finds are trivial) but if it cannot fix errors post a screenshot of the output.

The dism and sfc commands should fix any Windows issues that might cause these Side-By-Side errors.

Let me know how all that goes. Don't worry if none of this stops the BSODs, there are other troubleshooting tools we can use, but it's important to start with the obvious first.

Had a fortunate change of plans, will be able to run MemTest overnight tonight. Just had a question, can i run my system in safe mode during the test? I’m not sure ill be able to trust the desktop to not bsod during the test otherwise. Thanks again !

 

[ubuysa]

Memtest86 doesn't use Windows at all. It's a bootable system running it's own OS. It will take many hours on 32Gb, but do try and run it twice, it's best if the second run immediately follows the first.

Another way of testing RAM is to remove one stick for a day or two, or until you get a BSOD. Then swap sticks for a day or two, or until you get a BSOD.

If it BSODs on only one stick then you have your problem. If it BSODs on either stick it's unlikely to be bad RAM.

 

[Channji]

Memtest86 doesn't use Windows at all. It's a bootable system running it's own OS. It will take many hours on 32Gb, but do try and run it twice, it's best if the second run immediately follows the first.

Another way of testing RAM is to remove one stick for a day or two, or until you get a BSOD. Then swap sticks for a day or two, or until you get a BSOD.

If it BSODs on only one stick then you have your problem. If it BSODs on either stick it's unlikely to be bad RAM.

Right !! I understand it now haha, watched a couple videos. Will post an update in the morning. Thanks !!

 

[Channji]

Yep, that's good. Thanks.

The four dumps uploaded don't highlight any particular third-party driver, although one references nvlddmkm.sys (the Nvidia graphics driver) I think that's coincidence. Taking these four dumps as a group, and including the second 0x50 BSOD you just reported, bad RAM must be a suspect here.

Two of the dumps fail because of a misaligned instruction pointer, this is what points to the next instruction to be executed. It can be messed up by bad drivers, but I'd expect to see the third-party driver responsible in the dump and we don't. The other two dumps fail in the same way, both fail coming out of the idle loop and before any third-party drivers are called.

I suggest you run Memtest86...

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.

However, in addition to the above in your Application log there are many Side-By-Side errors, typically (but not exclusively) for MSI Afterburner (which I believe to be a flaky app in any case)...

Log Name:      Application
Source:        SideBySide
Date:          11/04/2024 14:12:37
Event ID:      33
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Persephonie
Description:
Activation context generation failed for "D:\MSI Afterburner\MSIAfterburner.exe". Dependent Assembly Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

There is also at least one Side-By-Side error for the RivaTuner Statistics Server...

Log Name:      Application
Source:        SideBySide
Date:          11/04/2024 14:00:11
Event ID:      33
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      Persephonie
Description:
Activation context generation failed for "D:\RivaTuner Statistics Server\DesktopOverlayHost.exe". Dependent Assembly Microsoft.VC90.MFC,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.

These Side-By-Side errors indicate a problem accessing specific shared system dlls. Side-By-Side execution is used where several versions of the same dll exist and it's vital that a process references only the correct version. What these erors indicate is that the required dll could not be found.

These might well be related to any RAM error you may have, but they might indicate either an error in your Windows configuration (if the dlls are Microsoft dlls) or a problem with the third-party apps (if they supply different versions of the same dll). I don't think that this would cause a BSOD however, just a crash of the specific app. However, it might be worth fully uninstalling both MSI Afterburner and Riva Tuner and see whether that stops the BSODs.

I'd also suggest opening an elevated command prompt and running the following command...

dism /online /cleanup-image  /checkhealth

If that finds no corruptions then all is good, but if it does find corruptions then run the following command...

dism /online /cleanup-image /restorehealth

If that completes with no errors then all is good, but if you get errors take a screenshot of the output and post that here.

If dism runs clean or fixes any errors then run the following command...

sfc /scannow

If that finds errors and fixes them then all is good (most of the errors that sfc finds are trivial) but if it cannot fix errors post a screenshot of the output.

The dism and sfc commands should fix any Windows issues that might cause these Side-By-Side errors.

Let me know how all that goes. Don't worry if none of this stops the BSODs, there are other troubleshooting tools we can use, but it's important to start with the obvious first.

memtest results.zip
heres the memtest results. had a bsod last night during the process of getting memtest onto the usb, and just one now in the middle of writing this, they seem to be really frequent now. would you like me to run the sysnative again?

 

[ubuysa]

Just be aware that Memtest86 cannot prove that your RAM is good, but it does give us a lot of confidence that it probably is good.

Yes, please run the SysnatioveBSODCollectionApp again and upload the zip file.

 

[Channji]

Just be aware that Memtest86 cannot prove that your RAM is good, but it does give us a lot of confidence that it probably is good.

Yes, please run the SysnatioveBSODCollectionApp again and upload the zip file.

SysnativeFileCollectionApp.zip
heres the one i just did.
Okay so, do you mean we can be confident its not a hardware issue?

had another 2 bsods while writing this ! do you think a full reset might help? as before i only reset while keeping personal files, making me think now that would virtually do nothing

 

[ubuysa]

TBH I think this IS a hardware problem, but let me go through the new data first.

 

[ubuysa]

I'm still thinking that hardware is the most likely cause here, the principal reason is that none of these dumps (except for one) reference any third-party drivers in the lead up to the BSODs. That's generally a pretty strong indication of a hardware problem. I am seeing most dumps failing on the nt!guard_dispatch_icall function call. This seems to be related to the Control Flow Guard feature of Windows 10/11 to mitigate code injection exploits. You can disable this feature, but I'm not going to suggest that just yet. Intsead we'll see whether we can shake any flaky third-party drivers out by enabling 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, 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).

 

[Channji]

I'm still thinking that hardware is the most likely cause here, the principal reason is that none of these dumps (except for one) reference any third-party drivers in the lead up to the BSODs. That's generally a pretty strong indication of a hardware problem. I am seeing most dumps failing on the nt!guard_dispatch_icall function call. This seems to be related to the Control Flow Guard feature of Windows 10/11 to mitigate code injection exploits. You can disable this feature, but I'm not going to suggest that just yet. Intsead we'll see whether we can shake any flaky third-party drivers out by enabling 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, 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).

Working on this now. Can i store my windows backup on my pc’s hard drive still? Or will i need to do it on something external - in reference to if it finds itself in a bsod loop

 

[Channji]

I'm still thinking that hardware is the most likely cause here, the principal reason is that none of these dumps (except for one) reference any third-party drivers in the lead up to the BSODs. That's generally a pretty strong indication of a hardware problem. I am seeing most dumps failing on the nt!guard_dispatch_icall function call. This seems to be related to the Control Flow Guard feature of Windows 10/11 to mitigate code injection exploits. You can disable this feature, but I'm not going to suggest that just yet. Intsead we'll see whether we can shake any flaky third-party drivers out by enabling 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, 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).

Attempting to create backup using macrium, however the thing keeps on blue screening while its creating the file

 

[ubuysa]

Just take a restore point then.

If its BSODing that often there's something else I'd like you to try. Can you do one of the following:

Either go into the BIOS and disable C-States completely.

Or in the active Windows power policy, expand the Processor Power Management section and set both the maximum and minimum processor power state to 99%.

Both of these steps will stop the processors entering a low power state when idle. Most of your dumps show failures coming out of an idle state, so let's see whether this stops them.