News I survived a scary Blue Screen of Death, the dreaded Kernel Security Check Failure. Here's how.

[Admin]

After some investigation, I found an easy fix to this perplexing Windows error.

I survived a scary Blue Screen of Death, the dreaded Kernel Security Check Failure. Here's how. : Read more

 

[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!

 

[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:
>>> [Install network driver - oracle_VBoxNetLwf]
>>> Section start 2024/01/17 23:48:30.091
<<< Section end 2024/01/17 23:48:30.617
<<< [Exit status: SUCCESS]
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.txt

This will create DriverInstalls.txt on your desktop. Read from the bottom up.

 

[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.

 

[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.

 

[Alvar "Miles" Udell]

https://learn.microsoft.com/en-us/w...ug-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.

 

[bit_user]

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.

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.

 

[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...

 

[Alvar "Miles" Udell]

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 basement 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.

 

[bit_user]

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?

uses reputable hardware and not bargain basement 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 basement" components. Also, plenty of other memory, which tells me it's not something specific to Dell server memory.

 

[Alvar "Miles" Udell]

These are questions you should ask him, ambassador.

 

[bit_user]

These are questions you should ask him, ambassador.

It doesn't really matter, I think. The main point of the article is how to debug this kind of problem, which I think it does rather well (i.e. by showing you what to look at and how).

I'm just surprised to hear the claim that GPU driver installations have a tendency to get corrupted. If true, that sounds like a story in its own right.