Question BSOD caused by ntoskrnl.exe ?

[CankoP]

For the last 2-3 months I have been getting random BSODs on my laptop. The crashes happen very randomly. Most of the time the blue screen just flashes for a second and restarts my system without creating a .dmp file. Other times my screen just goes black and I have to manually reboot the laptop. When .dmp files are created after the crash it always says in BlueScreenView that ntoskrnl.exe is the problematic driver.
I've tried to read about this issue online and fix it myself, but haven't had any success.
What I've tried:

• updating drivers I thought could have caused this
• running Windows Memory Diagnostic Tool
• ran an SFC
• installed Windows anew on the system

Here's a link to my .dmp files:

Microsoft OneDrive

1drv.ms

Any help would be massively appreciated!

 

[hedwar2011]

When posting a thread of troubleshooting nature, it's customary to include your full system's specs. Please list the specs to your build like so:
CPU:
CPU cooler:
Motherboard:
Ram:
SSD/HDD:
GPU:
PSU:
Chassis:
OS:
Monitor:

Also, have you tried running in Safe Mode? It isn't going to be fully functioning but will allow you to eliminate most 3rd party programs/apps from possibly causing it.

 

[CankoP]

Mobo: ASUS TUF Gaming A17 FA706IH
CPU: AMD Ryzen 7 4800H
RAM: 8GB DDR4-3200 SO-DIMM
SSD: 1TB PCIe 3.0 NVMe M.2 SSD
GPU: NVIDIA GeForce GTX 1650 4GB
OS: Windows 10

Will try to run in Safe Mode and post what happens.

 

[ubuysa]

My bet is that Safe Mode will fail - because I think this is a RAM problem. The six minidumps, although not identical, all point strongly at RAM. You have two ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY, a dump with a misaligned instruction pointer, a FAST_ERESOURCE_PRECONDITION_VIOLATION (which I've never seen before), a couple of dumps with an attempt to execute an illegal instruction (that will be a bad instruction pointer), and a memory access violation dump.

All-in-all the common denominator between these dumps is RAM. I know you've run the Windows Memory Diagnostic but that isn't very thorough and finds only obvious RAM issues.

Since you only have one stick of RAM we can't test by removing one stick, so you'll need to run the best RAM tester we know of; Memtest86...

1. Download Memtest86 (free) and 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 your laptop at the moment.
2. Then, on your laptop, boot that USB drive, 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 immediately restart Memtest86 (don't leave a gap), and do another four iterations.

Even a single error is a failure.

 

[CankoP]

My bet is that Safe Mode will fail - because I think this is a RAM problem. The six minidumps, although not identical, all point strongly at RAM. You have two ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY, a dump with a misaligned instruction pointer, a FAST_ERESOURCE_PRECONDITION_VIOLATION (which I've never seen before), a couple of dumps with an attempt to execute an illegal instruction (that will be a bad instruction pointer), and a memory access violation dump.

All-in-all the common denominator between these dumps is RAM. I know you've run the Windows Memory Diagnostic but that isn't very thorough and finds only obvious RAM issues.

Since you only have one stick of RAM we can't test by removing one stick, so you'll need to run the best RAM tester we know of; Memtest86...

1. Download Memtest86 (free) and 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 your laptop at the moment.
2. Then, on your laptop, boot that USB drive, 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 immediately restart Memtest86 (don't leave a gap), and do another four iterations.

Even a single error is a failure.

I ran one yesterday with no errors, I'll run it again.

Also the two ATTEMPTED_EXECUTE_OF_NONEXECUTE_MEMORY were caused by a Virtual Machine that wasn't set up properly.

 

[ubuysa]

How do you know that VM wasn't causing the other BSODs then?

 

[CankoP]

How do you know that VM wasn't causing the other BSODs then?

The laptop was looked at by an "expert" and he said he fixed that issue. On top of that I haven't used the VM since I got the laptop back.

 

[CankoP]

Ran MemTest86 twice today with no errors.

 

[hedwar2011]

Ran MemTest86 twice today with no errors.

Did you run it exactly as @ubuysa indicated? If so and it still didn't generate any errors then something else is at play.

How did running in Safe Mode transpire?

 

[CankoP]

Did you run it exactly as @ubuysa indicated? If so and it still didn't generate any errors then something else is at play.

How did running in Safe Mode transpire?

Ran it exactly as they said.

Haven't ran it in Safe Mode for a long enough period of time for it to crash.

Also here's a link to the new .dmp files it created:

Minidump.rar

Compressed (zipped) Folder

1drv.ms

New Minidump.rar

Compressed (zipped) Folder

1drv.ms

Sorry that they are separated.

 

[ubuysa]

I only looked at the dumps from November, but, once again, they're strongly pointing at RAM. Have you ever checked your temperatures when running? Laptops suffer greatly from overheating if they're not cleaned regularly. Run a temperature monitor like HWMonitor (free) both at idle and under max load. Post a screenshot of CPU and GPU temps in both states here.

I too want to see it running in Safe Mode. Safe Mode is no fun, you won't be able to do any useful work because Safe Mode is a stripped-down Windows system with no third-party drivers loaded. Some devices won't work properly (or at all) and your display will be clunky low res - because none of the required third-party drivers are loaded.

The sole purpose of Safe Mode is to see whether it will BSOD, so you have to do your best to try and make it BSOD and you have to run it long enough to have had a BSOD. I would strongly suggest you run it in Safe Mode for at least 48 hours, or until you get a BSOD. You should leave it running overnight too, in order to see whether it BSODs when idle.

Try Safe Mode with Networking at first, because you'll have Internet access and it will be a little more usable (but you'll also have the third-party network adapter driver loaded). If it BSODs in this mode then restart it in Safe Mode without networking and see whether it BSODs then (when you won't have the third-party network adapter loaded).

Running is Safe Mode is a pain, but it's the best way to see whether this is a hardware problem or a software problem and so it's important that you give it every chance to BSOD in Safe Mode - that means running it for long enough.

 

[CankoP]

I only looked at the dumps from November, but, once again, they're strongly pointing at RAM. Have you ever checked your temperatures when running? Laptops suffer greatly from overheating if they're not cleaned regularly. Run a temperature monitor like HWMonitor (free) both at idle and under max load. Post a screenshot of CPU and GPU temps in both states here.

I too want to see it running in Safe Mode. Safe Mode is no fun, you won't be able to do any useful work because Safe Mode is a stripped-down Windows system with no third-party drivers loaded. Some devices won't work properly (or at all) and your display will be clunky low res - because none of the required third-party drivers are loaded.

The sole purpose of Safe Mode is to see whether it will BSOD, so you have to do your best to try and make it BSOD and you have to run it long enough to have had a BSOD. I would strongly suggest you run it in Safe Mode for at least 48 hours, or until you get a BSOD. You should leave it running overnight too, in order to see whether it BSODs when idle.

Try Safe Mode with Networking at first, because you'll have Internet access and it will be a little more usable (but you'll also have the third-party network adapter driver loaded). If it BSODs in this mode then restart it in Safe Mode without networking and see whether it BSODs then (when you won't have the third-party network adapter loaded).

Running is Safe Mode is a pain, but it's the best way to see whether this is a hardware problem or a software problem and so it's important that you give it every chance to BSOD in Safe Mode - that means running it for long enough.

Here are the screenshots:

CPU and GPU temps

Folder

1drv.ms

While I was stressing out the system it crashed again with a new error.

new crash.rar

Compressed (zipped) Folder

1drv.ms

 

[CankoP]

Got two new BSOD messages and .dmp files:

Microsoft OneDrive

1drv.ms

These crashes weren't while running in Safe Mode.

 

[ubuysa]

First things first: did you run it in Safe Mode long enough to make it crash? It doesn't seem so by the speed of your response. It is VERY important for us to know whether it fails in Safe Mode.

The 110523-119640-01.dmp dump was caused by Genshin Impact anti-cheat. Their HoYoKProtect.sys driver is on the call stack leading to the bugcheck...

14: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffca01`fd246d28 fffff805`6fe11729     nt!KeBugCheckEx
01 ffffca01`fd246d30 fffff805`6fe0be3d     nt!KiBugCheckDispatch+0x69
02 ffffca01`fd246e70 fffff809`31d73e5d     nt!KiDoubleFaultAbort+0x2bd
03 ffffffff`fffffe80 00000000`00000000     HoYoKProtect+0x273e5d

All of the anti-cheat tools cause BSODs now and again on various systems.

The other two later dumps (110523-117734-01.dmp & 110523-105734-01.dmp) are inconclusive. They could also be caused by HoYoKProtect.sys but that would just be a guess at the moment, these dumps could also have a hardware cause. We need to see it running in Safe Mode for 48 hours to eliminate hardware as a potential cause.

 

[CankoP]

First things first: did you run it in Safe Mode long enough to make it crash? It doesn't seem so by the speed of your response. It is VERY important for us to know whether it fails in Safe Mode.

The 110523-119640-01.dmp dump was caused by Genshin Impact anti-cheat. Their HoYoKProtect.sys driver is on the call stack leading to the bugcheck...

14: kd> knL
 # Child-SP          RetAddr               Call Site
00 ffffca01`fd246d28 fffff805`6fe11729     nt!KeBugCheckEx
01 ffffca01`fd246d30 fffff805`6fe0be3d     nt!KiBugCheckDispatch+0x69
02 ffffca01`fd246e70 fffff809`31d73e5d     nt!KiDoubleFaultAbort+0x2bd
03 ffffffff`fffffe80 00000000`00000000     HoYoKProtect+0x273e5d

All of the anti-cheat tools cause BSODs now and again on various systems.

The other two later dumps (110523-117734-01.dmp & 110523-105734-01.dmp) are inconclusive. They could also be caused by HoYoKProtect.sys but that would just be a guess at the moment, these dumps could also have a hardware cause. We need to see it running in Safe Mode for 48 hours to eliminate hardware as a potential cause.

It has been running in Safe Mode for the last 12-ish hours, will leave it on Safe Mode for the full 48 hours

 

[ubuysa]

It has been running in Safe Mode for the last 12-ish hours, will leave it on Safe Mode for the full 48 hours

Please do you best to make it BSOD, we need to be certain that it won't BSOD in Safe Mode....

 

[CankoP]

It has now been 48 hours since I started to run the laptop in Safe Mode.
I tried to stress out my system and make it BSOD, but to no avail. It didn't crash even once in Safe Mode.

 

[CankoP]

After exiting Safe Mode, I thought it would be a good idea to do a clean install of both my integrated and dedicated graphics drivers. Sometime after doing so, my system crashed twice.

These are the new .dmp files:

minidump 5.rar

Compressed (zipped) Folder

1drv.ms

 

[ubuysa]

If it didn't BSOD in Safe Mode then we can be pretty confident that your hardware is good. However, and confusingly, the two recent BSODs both look very much like RAM problems, one is a 0xC0000005 exception (memory access violation) and the other is even flagged by the debugger as a hardware problem.

However, running in Safe Mode makes that far less likely now. In addition, one of the recent dumps shows several (un-named) filter drivers being called and any of these could be a potential problem. I suggest that now you should enable Driver Verifier to see whether we can catch a rogue driver....

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, in 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 until you have between 5 and 10 BSODs/dumps, or 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.

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.

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/them public).

 

[CankoP]

If it didn't BSOD in Safe Mode then we can be pretty confident that your hardware is good. However, and confusingly, the two recent BSODs both look very much like RAM problems, one is a 0xC0000005 exception (memory access violation) and the other is even flagged by the debugger as a hardware problem.

However, running in Safe Mode makes that far less likely now. In addition, one of the recent dumps shows several (un-named) filter drivers being called and any of these could be a potential problem. I suggest that now you should enable Driver Verifier to see whether we can catch a rogue driver....

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, in 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 until you have between 5 and 10 BSODs/dumps, or 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.

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.

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/them public).

These are the newest I could find. There were two more, but I forgot to add them and they dissapeared.

driver verifier dumps.rar

Compressed (zipped) Folder

1drv.ms

 

[CankoP]

When I tried to use VirsualBox today I could consistently get a driver verifier detected blue screen.

Microsoft OneDrive

1drv.ms

Could this cause all the crashes while I am not even running it?

 

[ubuysa]

You can disable Driver Verifier now.

None of those dumps were caused by Driver Verifier failing a third-party driver. That doesn't mean that all your third-party drivers are good however, because Driver Verifier can only test drivers when they are loaded. However, the fact that you've had 5 BSODs that are not Driver Verifier caused suggests that this isn't a driver issue.

These five dumps fail with (mostly) different bugchecks; there are two 0x1E, a 0xA, 0x4A, and a 0x139, but the common denominator in all five dumps is (again) RAM. There are three stack pointer errors, a 0xC0000005 exception, a corrupt LIST entry, and a failure during page table manipulation.

RAM is one area that Safe Mode can't fully test, because you can't run enough processes to fill it. Memtest86 runs clean, but even that can't find all RAM issues. I'm assuming that your 8GB of RAM is in just one RAM card? That prevents us trying to remove one card an run on just the other one sadly.

In that case I'm going to ask you to run Prime95. This is primarily a CPU stress testing tool, but two of the tests also stress RAM to some extent, so this should tell us whether RAM is an issue for you. Prime95 will make your CPU run hot and in a laptop that can be bad news, so the first thing I suggest you do is to give the insides of the laptop a good clean. Pay particular attention to the vents on the case, ensure they are all clear, also ensure that the finned heat exchanger right next to the fan is also clean and free of dust and fluff. ALL of the cooling is done there and you need a clean airflow through that heat exchanger.

Before you run Prime95 elevate the laptop a little (an inch or so) being careful not to block any air vents. Make sure it has a clear space around it so that hot air can escape and cool air can flow in (typically cool air is drawn in via the bottom). Download an run a temperature monitor (like CoreTemp) so you can keep a close eye on CPU temperatures.

Run each of the three Prime95 tests (small FFTs, large FFTs, and Blend) one after the other for a minimum of 30 minutes each test - longer if you can. If Prime95 throws errors, if the system crashes or BSODs, or if the CPU temp rises to dangerous levels (more than 100°C for your CPU), then stop testing and let us know what happened.

I'm quite sure already that this is a RAM issue of some sort that Safe Mode didn't fall over.

 

[CankoP]

You can disable Driver Verifier now.

None of those dumps were caused by Driver Verifier failing a third-party driver. That doesn't mean that all your third-party drivers are good however, because Driver Verifier can only test drivers when they are loaded. However, the fact that you've had 5 BSODs that are not Driver Verifier caused suggests that this isn't a driver issue.

These five dumps fail with (mostly) different bugchecks; there are two 0x1E, a 0xA, 0x4A, and a 0x139, but the common denominator in all five dumps is (again) RAM. There are three stack pointer errors, a 0xC0000005 exception, a corrupt LIST entry, and a failure during page table manipulation.

RAM is one area that Safe Mode can't fully test, because you can't run enough processes to fill it. Memtest86 runs clean, but even that can't find all RAM issues. I'm assuming that your 8GB of RAM is in just one RAM card? That prevents us trying to remove one card an run on just the other one sadly.

In that case I'm going to ask you to run Prime95. This is primarily a CPU stress testing tool, but two of the tests also stress RAM to some extent, so this should tell us whether RAM is an issue for you. Prime95 will make your CPU run hot and in a laptop that can be bad news, so the first thing I suggest you do is to give the insides of the laptop a good clean. Pay particular attention to the vents on the case, ensure they are all clear, also ensure that the finned heat exchanger right next to the fan is also clean and free of dust and fluff. ALL of the cooling is done there and you need a clean airflow through that heat exchanger.

Before you run Prime95 elevate the laptop a little (an inch or so) being careful not to block any air vents. Make sure it has a clear space around it so that hot air can escape and cool air can flow in (typically cool air is drawn in via the bottom). Download an run a temperature monitor (like CoreTemp) so you can keep a close eye on CPU temperatures.

Run each of the three Prime95 tests (small FFTs, large FFTs, and Blend) one after the other for a minimum of 30 minutes each test - longer if you can. If Prime95 throws errors, if the system crashes or BSODs, or if the CPU temp rises to dangerous levels (more than 100°C for your CPU), then stop testing and let us know what happened.

I'm quite sure already that this is a RAM issue of some sort that Safe Mode didn't fall over.

Just finished running all tests for around 30-45 minutes per test. The temperatures were normal. I experienced one crash a bit after I started the last test (Blend). Prime95 didn't throw any errors.

Here is the .dmp of the one crash that occured:

prime95 crash.rar

Compressed (zipped) Folder

1drv.ms