Blue is one of my favorite colors, but when it takes over my entire screen, I start to panic . . . and for good reason. The Windows Blue Screen of Death (BSOD) appears suddenly when your computer crashes and leaves you with two gripping questions: "why did this happen" and "will it happen again?"
Last week, my computer hit me with the blue screen of death shown at the top of this page, a Kernel Security Check Failure, and my monitor wasn't the only one wearing a frown. I got this BSOD twice, both times when I started playing a video in my browser.
The first time, I actually had some weird wavy lines in my web browser before it happened. The second time, which occurred a couple of days later, everything was cool but I had just started playing something on Netflix when it hit me. I was using Windows 10, but this same BSOD can occur on Windows 11 as well.
Solving Kernel Security Check Failure BSOD
I started to think that this is not a fluke and I need to do something to remedy the situation so I followed the steps one usually takes when trying to fix a Windows BSOD. First, I searched for the specific error "Kernel Security Check Failure," and I did not find any official documentation from Microsoft, but rather a series of forum posts on answers.microsoft.com and other forums and social media.
Unfortunately, it seems that this error could be caused by a lot of different things, which range from hardware failure to corrupt files to bad drivers or even malware. So I tried a few different things before settling on a solution.
1. Boot into Safe Mode
The good news is that my computer wasn't bricked. It rebooted and let me resume doing things as normal. However, I had to act quickly to solve the problem, because I didn't want to be plagued with more BSODs.
The best place to do your research and diagnosis is in Windows Safe mode. Safe mode runs Windows with minimal drivers and apps preloaded so a crash is less likely.
Stay On the Cutting Edge: Get the Tom's Hardware Newsletter
Get Tom's Hardware's best news and in-depth reviews, straight to your inbox.
If you're going to download software or read about your problem on websites while you try to fix it, it's best to choose Safe Mode with Networking, which allows you to get online and browse the web.
There are a few ways to boot into safe mode, but the simplest is tosearch for and launch "system configuration" from the Windows search menu. Select "Safe boot" and Network on the Boot tab, then click OK. Restart the computer.
You'll know you're in Safe Mode because your background will be black, and the words "safe mode" will be watermarked on the screen's corners. The one drawback to this method of launching Safe Mode is that, in order to prevent the PC from booting into Safe Mode in the future, you need to go back to System Configuration and select "Normal startup" on the General tab.
Other ways to launch Safe mode: launch Advanced Startup from the Settings menu, or hit F8 on booting (if it's possible to hit it fast enough).
2. Scan for Malware
Because the word "security" is in the BSOD, Kernel Security Check Failure, the first thing I tried was scanning for malware. I use Microsoft's built-in Windows Security application as my anti-virus app, and I used it to do a quick scan, but it didn't find anything.
I also downloaded and installed a trial version of Malware Bytes, which is also available in a free version. I find that Malware Bytes can pick up some malware which is not technically viruses that Windows Security misses.
I ran a Malware Bytes scan and it didn't find anything significant (a couple of older files in my downloads folder were flagged, but these were data files and nothing I had edited or installed). So I determined that malware was not the cause of my Kernel Security Check Failure BSOD.
3. Scan for Disk Corruption and Corrupt Files
This is low-hanging fruit that may or may not solve your problem. If your computer has corrupted files that could be causing a BSOD. On the other hand, if your computer just had a BSOD, some files could register as corrupted as a result of the BSOD crash rather than the cause of it.
So it's good practice to do these scans, but if they find and fix errors, this is not necessarily the end of your woes. I launched an elevated command prompt (running CMD as Administrator) and ran the following commands.
chkdsk c:sfc /scannowMy system didn't really find anything. SFC /scannow did claim to fix some corrupted files, but it does that almost every time I run it, even if I haven't had a BSOD.
I also tried DISM, which detects problems with the windows image.
DISM /Online /Cleanup-Image /CheckHealthIt didn't detect any errors in my case. However, if it had, I could follow up with the following command, which is supposed to fix them.
DISM /Online /Cleanup-Image /RestoreHealth4. Check Recent Updates, Software Installs and Drivers
If you just started getting BSODs, there's a good chance the problem was caused by something you recently installed: an app, a driver, a Windows update or even a peripheral.
First, I checked my list of apps, sorted by date of install to see if there was anything suspicious on the list. You can get there by navigating to Settings->Apps & features and sorting by install date.
Nothing on the app install list stood out to me. Next, I checked my Windows update history, available under Settings->Windows Update->View update history, but all of the updates were from a month ago and the BSODs had only just started. Note that the screenshot below shows three updates I did after I fixed the BSOD problem.
Checking driver dates is a little more difficult because I don't know of any Windows menu that makes it easy to see all drive installs sorted by date. You can go to Device Manager, right click on individual devices such as the graphics card, select properties and then look for the Driver Date under the Driver tab.
However, this process isn't perfect because the date here is the release date for that driver, not the date that you installed it.
Another way to check driver dates is to look at any utility software you have. So, if you have GeForce Experience for your Nvidia graphics card, that will also have the driver date and version displayed.
Whatever the case, I didn't see any new drivers with dates that were within the last week or so before the BSODs started.
5. Check Bluescreen View
My next step was to run Bluescreen View, a free utility from NirSoft which reads your minidump files -- the log files that Windows generates when it gets a BSOD -- and helps you understand them. The top pane of the BlueScreenView window shows the name of the dump file and the exact crash time while the bottom pane shows a list of system files (dll, sys, exe) that were in use.
I loaded up Bluescreen View and, lo and behold, I saw two files in the bottom pane highlighted in red to show that they failed: ntoskrnl.exe and dxgkrnl.sys. I googled these files to learn more about what they do.
Ntoskrnl, is a big part of the OS but apparently it fails when there are memory issues, which could be due to a driver or due to a physical fault in memory. Dxgkrnl.sys is related to the graphics card -- the dxg stands for DirectX graphics -- so it suggests a problem with the GPU.
I decided that the problem was likely related to my graphics card, an Nvidia RTX 3090 Ti I have used without issue for a long time. Its driver date was December 8, 2023, which was more than a month before my BSOD, which made it seem like the driver could not be the issue.
6. Uninstall and Reinstall Graphics Driver (in my case)
Despite the fact that the graphics driver had been working successfully in my system for about a month, I decided to try completely removing and reinstalling it. Perhaps something had caused the driver to be corrupted recently. The idea of the problem being graphics related made sense to me, because the crashes occurred when I had started watching videos and, right before the first BSOD, weird wavy pink and gray lines were appearing on every web page I visited in Chrome browser.
To uninstall a graphics driver properly, you need to completely remove it using a free tool called DDU (Display Driver Uninstaller). Simply using Windows' built-in uninstall tools will leave remnants of the driver behind which could remain in place even after you reinstall.
We have a complete guide to uninstalling graphics drivers using DDU elsewhere. However, in short, what you need to do is download DDU , install it and launch it. Then select GPUfrom the Device type menu and click Clean and restart.
Your computer will then complete the uninstall process and restart. From there, you can download and reinstall the drivers.
In my case, I found that using DDU to uninstall my graphics driver and then using Nvidia GeForce experience to install it fresh was the solution to my problems. Since doing the reinstall, I haven't experienced a single BSOD (and no wavy lines either). I have no idea how my graphics driver became corrupted, but this reinstall seems to have fixed it. Note that the driver that GeForce Experience reinstalled was the same exact version (December 8th) that I had before.
If you experience a Kernel Security Check Failure BSOD, the cause of your problem may not be the same as mine. It could be something other than your graphics driver. That's why it's important to follow a process like the one I did. For more help, check out our article on how to fix a Blue a Screen of Death, which explains how to diagnose any BSOD, not just a Kernel Security Check Failure.
Avram Piltch
Avram Piltch is Tom's Hardware's editor-in-chief. When he's not playing with the latest gadgets at work or putting on VR helmets at trade shows, you'll find him rooting his phone, taking apart his PC or coding plugins. With his technical knowledge and passion for testing, Avram developed many real-world benchmarks, including our laptop battery test.
More about windows
Latest
11 CommentsComment from the forums
PEnns Thank you Avram!
Although I believe I never had a single BSOD (pure luck?), it's good to have this article ready, just in case!
Reply
gardenman From the article:
Checking driver dates is a little more difficult because I don't know of any Windows menu that makes it easy to see all drive installs sorted by date.
The following is a log file of driver installs and dates:
C:\Windows\inf\setupapi.dev.log
Read from the bottom up.In the log file you will find the following 4 example lines for each driver:
>>> >>> Section start 2024/01/17 23:48:30.091
<<< Section end 2024/01/17 23:48:30.617
<<< This shows that I installed a VirtualBox (VBoxNetLwf) driver about 3 days ago.After a little research, I determined you can display only those lines (per driver) using the following in Command Prompt:
findstr "<<< >>>" C:\Windows\inf\setupapi.dev.log
And if you want to save only those lines to a text file, simply direct the output to a file like this:
findstr "<<< >>>" C:\Windows\inf\setupapi.dev.log > %userprofile%\Desktop\DriverInstalls.txtThis will create DriverInstalls.txt on your desktop. Read from the bottom up.Reply
yeyibi What I hate from sfc /scannow and DISM, is that for every problem you have, somebody at microsoft tells you to run those commands, even when they do not address the problem at all, and them MS considers the problem "solved", and closed.
Then Google makes it the default answer, blocking real solutions.It's like some bot or lazy MS employee uses it to pretend that he did his work.
Reply
bit_user Ntoskrnl, is a big part of the OS but apparently it fails when there are memory issues, which could be due to a driver or due to a physical fault in memory.
You should do an overnight memtest run, before you dismiss bad RAM as a possible cause.
That makes a lot more sense to me than simply reinstalling the driver, as you admit you still don't understand how doing so would actually fix the problem.
Reply
Alvar "Miles" Udell https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x139--kernel-security-check-failure
Common causes of list entry corruption include:
A driver has corrupted a kernel synchronization object, such as a KEVENT (for example double initializing a KEVENT while a thread was still waiting on that same KEVENT, or allowing a stack-based KEVENT to go out of scope while another thread was using that KEVENT). This type of bug check typically occurs in nt!Ke* or nt!Ki* code. It can happen when a thread finishes waiting on a synchronization object or when code attempts to put a synchronization object in the signaled state. Usually, the synchronization object being signaled is the one that has been corrupted. Sometimes, Driver Verifier with special pool can help track down the culprit (if the corrupted synchronization object is in a pool block that has already been freed).
A driver has corrupted a periodic KTIMER. This type of bug check typically occurs in nt!Ke* or nt!Ki* code and involves signaling a timer, or inserting or removing a timer from a timer table. The timer being manipulated may be the corrupted one, but it might be necessary to inspect the timer table with !timer (or manually walking the timer list links) to identify which timer has been corrupted. Sometimes, Driver Verifier with special pool can help track down the culprit (if the corrupted KTIMER is in a pool block that has already been freed).
A driver has mismanaged an internal LIST_ENTRY-style linked list. A typical example would be calling RemoveEntryList twice on the same list entry without reinserting the list entry between the two RemoveEntryList calls. Other variations are possible, such as double inserting an entry into the same list.
A driver has freed a data structure that contains a LIST_ENTRY without removing the data structure from its corresponding list, causing corruption to be detected later when the list is examined after the old pool block has been reused.
A driver has used a LIST_ENTRY-style list in a concurrent fashion without proper synchronization, resulting in a torn update to the list.Since this is a driver-linked BSOD, I think the first thing I'd do is check for updated GPU drivers since the problem ocurred twice when the GPU was in use, and if none were available, then reinstall the current GPU drivers if they had functioned properly for a time since files can get corrupted relatively easily.
For nVidia GPUs this is an easy process of clicking "reinstall driver" in the GeForce Experience's Driver tab. DDU not required.
Reply
bit_user Alvar Miles Udell said:
Since this is a driver-linked BSOD, I think the first thing I'd do is check for updated GPU drivers since the problem ocurred twice when the GPU was in use,He said the reinstalled driver was the same version as before - no update was available.
Alvar Miles Udell said:
if none were available, then reinstall the current GPU drivers if they had functioned properly for a time since files can get corrupted relatively easily.This doesn't make sense to me. You should not have files getting randomly corrupted. If so, then you've got bigger problems to troubleshoot & solve.
Reply
Gillerer In order to "survive" any BSOD, all you have to do is not rely on Windows as the OS for your life support equipment...
Reply
Alvar "Miles" Udell bit_user said:
He said the reinstalled driver was the same version as before - no update was available.This doesn't make sense to me. You should not have files getting randomly corrupted. If so, then you've got bigger problems to troubleshoot & solve.
It happens, as it happened with the author of this article who is TH's editor-in-chief who is presumably not overclocking or doing questionable things, uses reputable hardware and not bargain basem*nt no name brand components, and takes proper precautions against power surges with a line-interactive UPS.
It could be caused by a hardware issue or situation that will never happen again, or it could have been caused by playing a video in an internet browser, presumably Chrome or Firefox given his abject hatred of Edge, leading to issues that would be impossible to replicate but a reinstallation of the drivers cleared up, or it could just be Windows 10 being Windows 10 or even an issue with the initial driver installation that didn't rear its head until now.
Reply
bit_user Alvar Miles Udell said:
It happens, as it happened with the author of this article who is TH's editor-in-chief who is presumably not overclocking or doing questionable things,I'm not convinced. He said he upgraded the driver and then had two bluescreens less than a month later. How long did he wait, after reinstalling the driver, before declaring victory? Could it be that he just hasn't had enough runtime to hit the next bluescreen?
Alvar Miles Udell said:
uses reputable hardware and not bargain basem*nt no name brand components, and takes proper precautions against power surges with a line-interactive UPS.That doesn't rule out the possibility of bad RAM. I've seen Dell-branded server RAM go bad, plenty enough times to know that it can happen in non- "bargain basem*nt" components. Also, plenty of other memory, which tells me it's not something specific to Dell server memory.
Reply
Alvar "Miles" Udell These are questions you should ask him, ambassador.
Reply
