0x0000007A KERNEL_DATA_INPAGE_ERROR

Windows tried to fetch a page of kernel data from the paging file and the read failed. This is one of the most diagnosable stop codes there is, because the second parameter carries an I/O status code, and Microsoft documents what the common values mean - bad sectors, defective cabling, a controller that cannot see the disk. Read that one value and you usually have your answer.

Updated 2026-07-28Stop errorAlso written: 0x7A, KERNEL DATA INPAGE ERROR, kernel_data_inpage_error

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: KERNEL_DATA_INPAGE_ERROR

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0x0000007a (0x0000000000000001, 0xffffffffc000009c, 0xffffa50c1d2e4080, 0xfffff8036c1a5180).

What the error actually means

Not everything in kernel memory stays resident. Pageable kernel data gets written out to the paging file when memory is tight and read back on demand. That read is normally invisible and reliable.

Bugcheck 0x7A means the read failed. Windows asked the storage stack for a page it needed, and the storage stack came back with an error rather than data. There is no way to continue without that page, so the machine stops.

Because the failure happens at the boundary between memory and disk, the cause can live on either side - but the storage subsystem returns a status code explaining why the read failed, and Windows passes it straight through in parameter 2. That makes this stop code unusually direct.

Reading the parameters

The parameters have three different interpretations depending on parameter 1, which is unusual. In every case, parameter 2 is the error status - and that is the value that matters.

ParameterWhat it holds
When 1 is 1, 2 or 3 and 3 is zeroParameter 1 is the lock type held. Parameter 2 is the error status, usually an I/O status code. Parameter 3 is the current process if the lock type is 1, otherwise zero. Parameter 4 is the virtual address that could not be paged in.
When 1 is 3 or 4 and 3 is not zeroParameter 1 is the lock type. Parameter 2 is the error status. Parameter 3 is the address of the InPageSupport structure. Parameter 4 is the faulting address.
OtherwiseParameter 1 is the address of the page table entry, parameter 2 the error status, parameter 3 the PTE contents, and parameter 4 the faulting address.
Parameter 2 - the one to readAn NTSTATUS value describing why the read failed. The common values are documented and each points somewhere specific - see the table below.

What actually triggers it

Rather than guess, read the status code. Microsoft documents what these mean, and they map almost directly onto causes.

CauseHow oftenDetail
0xC000009C - STATUS_DEVICE_DATA_ERRORCommonBad blocks on the disk. The drive could not read the sector holding that page. Along with 0xC000016A, this is the most frequent status here and it points squarely at the storage device.
0xC000016A - STATUS_DISK_OPERATION_FAILEDCommonAlso bad blocks. Same interpretation and same response as 0xC000009C.
0xC000009D - STATUS_DEVICE_NOT_CONNECTEDCommonDefective or loose cabling, a termination problem, or the controller simply not seeing the disk. Genuinely worth checking physically before anything else - this one is often a cable rather than a fault.
0xC0000185 - STATUS_IO_DEVICE_ERROROccasionalMicrosoft describes this as improper termination or defective cabling, or two devices trying to use the same IRQ. Historically a SCSI-era diagnosis, but the cabling half still applies.
0xC000000E - STATUS_NO_SUCH_DEVICEOccasionalA hardware failure or an incorrect drive configuration. Microsoft advises checking cables and running the drive maker's diagnostic utility.
0xC000009A - STATUS_INSUFFICIENT_RESOURCESOccasionalA lack of non-paged pool resources. Notably not a storage problem - this one points at a driver leaking pool memory, which is a completely different investigation.
Failing RAMOccasionalMicrosoft names defective storage hardware or failing memory as another common cause. Memory can corrupt the page after it arrives, or corrupt the structures describing where it should come from.
MalwareRareMicrosoft notes a virus infection can cause this bugcheck, and specifically recommends a scan that examines the Master Boot Record.

Narrowing it down

One step does most of the work here.

Read parameter 2

Pull it from the bugcheck event in the System log, or from !analyze -v. It will be an NTSTATUS value starting 0xC0.

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} |
  Where-Object { $_.Message -match '0x0000007a' } |
  Select-Object TimeCreated, Message |
  Format-List
What it tells you

Match it against the table above. 0xC000009C or 0xC000016A means bad sectors - a drive problem. 0xC000009D means the controller lost sight of the drive - check cabling first. 0xC000009A means a pool resource shortage, which is a driver problem and nothing to do with the disk at all.

Check drive health

Read SMART attributes with CrystalDiskInfo. On a hard drive look at reallocated, pending and uncorrectable sector counts. On an SSD look at percentage used, available spare and media errors.

What it tells you

Any non-zero pending or uncorrectable sector count corroborates a bad-block status code and makes the drive the answer. A perfectly healthy drive with a cabling status code shifts attention to the physical connection.

Check what the log says just before

Filter the System log around the crash for disk, Ntfs and storahci entries - event IDs 7, 51, 55 and 98 in particular.

What it tells you

Storage errors immediately preceding the bugcheck confirm the subsystem and often name the specific device. Microsoft's guidance says errors occurring right before the bug check should be examined.

Fixes, cheapest first

Let the status code choose which of these you do first.

  1. Reseat cables and connections

    Effort: 15 minutes · Risk: Low

    Do this first if the status code is 0xC000009D, 0xC0000185 or 0xC000000E - all three point at connection rather than media.

    1. Power down fully and unplug at the wall.
    2. Reseat both ends of the SATA data cable and the power connector, or reseat the M.2 drive and its screw.
    3. Try a different SATA port and a different cable.
    4. Microsoft also suggests reseating adapter cards and cleaning their contacts - relevant if the drive is on an add-in controller.
  2. Scan and repair the disk

    Effort: 30 minutes to hours · Risk: Low

    For bad-block status codes, this is the documented response. Microsoft notes that Autochk may run automatically after a restart and attempt to map the bad sector out of use. If it does not, run it manually:

    chkdsk C: /f /r

    It requires a restart and the /r surface scan takes a long time. From the recovery environment, chkdsk /r works too - confirm drive letters with diskpart and list volume first.

    Watch out

    Back up before running /r on a drive you suspect is failing. A full surface scan on a dying disk can push it over the edge, and the backup matters more than the repair.

  3. Test the memory

    Effort: Overnight · Risk: None

    Microsoft's guidance names failing RAM as a common cause alongside storage, and specifically recommends running the memory scanner. Disable XMP or EXPO first, then run MemTest86 from USB for at least four passes.

  4. Rebuild the page file

    Effort: 15 minutes · Risk: Low

    Since the failure is a read from the paging file, a corrupt page file is directly in scope.

    1. System Properties, Advanced, Performance Settings, Advanced, Virtual memory, Change.
    2. Clear automatic management, select No paging file, apply, reboot.
    3. Return, set System managed size, apply, reboot again.
  5. Hunt a pool leak when the status is 0xC000009A

    Effort: Several hours · Risk: Medium

    This status is the odd one out - it means non-paged pool ran short, which is a driver leaking memory rather than a disk problem. Driver Verifier with Pool Tracking enabled identifies the culprit. See the Driver Verifier guide.

    Chasing the disk on this status code wastes days, which is exactly why reading parameter 2 first matters.

    Watch out

    Verifier deliberately increases crashes and can cause a boot loop. Run verifier /bootmode resetonbootfail before enabling any checks - it makes Verifier disable itself automatically if the machine fails to start, which removes most of the risk. Your manual exit is Safe Mode followed by verifier /reset. Full settings and the escape route are in the Driver Verifier guide.

  6. Update firmware and check for malware

    Effort: 45 minutes · Risk: Medium for firmware

    Update the drive's firmware if the vendor has a newer release. Microsoft also recommends a virus scan that checks the Master Boot Record, and confirming the latest Windows updates are installed.

When it is the hardware, not Windows

This code leans hardware, and usually storage specifically:

If the status code says bad blocks and SMART agrees, the priority is copying data off rather than repairing in place. Bad sectors do not heal - chkdsk maps them out of use, which buys working time but does not fix the underlying degradation. Treat a confirmed bad-block diagnosis as a deadline rather than a repair.

Frequently asked

Is this always a failing hard drive?

No, and the status code tells you. 0xC000009C and 0xC000016A genuinely mean bad sectors. 0xC000009D means the controller lost the drive, which is very often a cable. 0xC000009A means a pool shortage and has nothing to do with storage at all. Failing memory produces this too. Reading parameter 2 takes thirty seconds and prevents a lot of wasted effort.

How is this different from PAGE_FAULT_IN_NONPAGED_AREA?

0x50 means something referenced memory that was supposed to be permanently resident and was not there - the data should never have needed fetching. 0x7A means data that was legitimately paged out could not be read back. The first points at memory or a driver using freed memory; the second points at the path between memory and disk. Both can be caused by bad RAM, but 0x7A implicates storage far more often.

It happens when I open large files. Does that narrow it?

Somewhat. Heavy memory pressure forces more paging, which means more reads from the paging file and more chances to hit a bad sector. So a workload correlation points at storage or memory rather than exonerating them. If a specific file reproduces it, the bad sectors may be in that file's region or in the part of the page file it forces into use.

Can I just move the page file to another drive?

It can stop the crashes, and as a diagnostic it is informative - if moving the page file to a different disk resolves it, the original disk is at fault. As a fix it is poor, because the failing drive still holds your Windows installation and your data, and it will keep degrading. Use it to confirm the diagnosis, then replace the drive.