KERNEL_SECURITY_CHECK_FAILURE: Driver or Memory

The name of this stop code misleads people twice. It is not about security in the sense of malware, and it is not about the kernel being at fault. Windows validates the integrity of certain internal structures, one of those validations failed, and the system stopped rather than continue with state it knows is wrong.

That is a system working as designed. The question is what damaged the structure.

The Two Causes

A driver writing outside its bounds. Kernel-mode drivers share an address space with the rest of the kernel. A driver with a pointer error writes into memory belonging to something else, and that something else fails its integrity check when next used.

Faulty memory. A bad region of physical memory corrupts whatever is stored there. Which structure fails depends entirely on what happened to be in that region, so the crash appears somewhere different each time.

Both produce this stop code, and telling them apart is the whole diagnostic task.

Telling Them Apart

Several dumps matter more than one. A single dump names one module and that module may be the victim rather than the cause. A pattern across dumps is what distinguishes them.

Start with the Memory Diagnostic

It is quick, it requires no tools, and it eliminates a whole category.

The built-in Windows Memory Diagnostic runs at boot before the operating system loads, so it can test regions that are in use during normal operation. It reports afterwards, and the result is also written to the event log.

A single reported error is enough. Memory faults are not intermittent in the sense of being sometimes harmless; a region that fails a test is a region that will corrupt something.

Where the machine has several memory modules, testing them individually narrows it to one, which is worth doing before replacing all of them.

Read the Dumps

The dump names the bugcheck parameters and attempts to attribute the fault. For this stop code the first parameter identifies the specific check that failed, which occasionally points directly at the type of corruption.

Reading a memory dump covers opening one and configuring symbols. The important discipline here is to collect several dumps before concluding anything, because the difference between “the same driver every time” and “a different module every time” is the diagnosis.

Confirm dumps are actually being written before waiting for the next crash. A machine configured to write none leaves nothing to read.

Rolling Back a Driver

If the crashes began after a specific driver installed, Device Manager offers a rollback to the previous version. It is reversible and it is the cheapest available test.

Graphics, storage and network drivers are the usual candidates, being the ones that do the most kernel-mode work. Virtualisation and security software also install kernel drivers and belong on the list.

Obtain replacement drivers from the hardware manufacturer rather than through a general search.

Driver Verifier

When a driver is suspected but no dump names one, Verifier applies extra checks to selected drivers so that a violation causes an immediate, attributable crash instead of damage that surfaces later somewhere else.

The dumps it produces are far more direct, because the fault is caught at the point of the violation.

It works by crashing the machine deliberately. A system with a badly behaved driver may become unable to boot normally while Verifier is enabled, and the way back is to disable it from Safe Mode. Confirm you can reach Safe Mode before turning it on; see safe mode.

Enable it for unsigned and third-party drivers rather than for all drivers, which reduces the disruption and targets the likely culprits. Turn it off as soon as the answer is found, because the additional checking carries a performance cost.

When It Is Neither

Corrupt system files can produce integrity failures too, and the repair sequence in chkdsk, SFC and DISM is worth running when other symptoms accompany the crashes: updates failing, features misbehaving, applications refusing to start.

Overclocked memory or processor settings are a genuine cause and an easy one to overlook, because the machine appeared stable for months. Returning those to default values is a quick test.

What People Get Wrong About This

The first mistake is reading the word security as malware and spending the investigation on scans.

The second is acting on a single dump. One dump names one module, and that module is often the one that discovered the damage rather than the one that caused it.

A third is enabling Driver Verifier with no plan for recovering a machine that will not boot.

A fourth is skipping the memory diagnostic because the memory is new. New modules fail, and the test costs one reboot.

And the last is reinstalling Windows. A reinstall removes installed applications and, depending on the option chosen, the files on the system volume, and it does nothing at all about faulty memory, which will produce identical crashes on a fresh installation.

A Working Order

Confirm dumps are being written. Run the memory diagnostic, because it is quick and decisive. Collect several dumps and look for a pattern rather than a name. Roll back any driver that changed recently. Then, if a driver is still suspected but unnamed, use Verifier with a route back to Safe Mode already established.