0x00000024 NTFS_FILE_SYSTEM
The stop code names ntfs.sys, the driver that lets Windows read and write NTFS volumes, and people reasonably conclude the driver is broken. It very rarely is. ntfs.sys is the component that notices when the disk beneath it returns something impossible, which makes it the messenger far more often than the culprit.
What you are looking at
Your PC ran into a problem and needs to restart.
Stop code: NTFS_FILE_SYSTEM
What failed: ntfs.sys
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: 0x00000024 (0x00000000001904fb, 0xffffb80f2c1a4530, 0xffffb80f2c1a3d70, 0xfffff80369a1c2b4).What the error actually means
NTFS is a structured filesystem: a master file table, allocation bitmaps, directory indexes, a journal, all consistent with each other by design. The driver reads those structures constantly and validates what it finds.
When it reads something that cannot be true - a record pointing outside the volume, an index that contradicts the bitmap, data that fails its own checks - the driver has no safe way to continue. Proceeding would mean writing user data based on bookkeeping it knows is wrong.
So it bugchecks. The name on the screen is the component that detected the impossibility, not the component that created it. Microsoft's own cause section leads with disk corruption, bad sectors, and corrupted storage drivers - not with a fault in NTFS itself.
Reading the parameters
Parameter 1 encodes where in the driver's own source the check failed, which is more useful to Microsoft than to you. Parameters 2 and 3 are the actionable ones, when present.
| Parameter | What it holds |
|---|---|
| 1 | Source file and line number information. The high 16 bits - the first four hex digits after 0x - identify the source file by an internal identifier; the low 16 bits identify the line. Not publicly decodable, but worth recording: a consistent value across crashes means the same internal check is failing every time, which is a coherent single fault rather than random corruption. |
| 2 | If NtfsExceptionFilter is on the stack, the address of the exception record. |
| 3 | If NtfsExceptionFilter is on the stack, the address of the context record. Microsoft's documented debugging route is .cxr with this address followed by kb, which reconstructs a usable stack trace. |
| 4 | Reserved. |
What actually triggers it
Storage-dominated, with one non-obvious cause that catches people out.
| Cause | How often | Detail |
|---|---|---|
| Bad sectors on the drive | Common | Microsoft names bad blocks directly. If the sectors holding filesystem metadata cannot be read reliably, the driver gets back nonsense and stops. This is the leading explanation. |
| NTFS structure corruption | Common | Damage to the master file table or index structures, usually from an unclean shutdown, a failing drive, or an interrupted write. Sometimes repairable with chkdsk, sometimes not. |
| Corrupted storage controller drivers | Occasional | Microsoft notes that corrupted SATA or IDE drivers can adversely affect the system's ability to read and write, causing this error. A driver returning bad data looks identical to a disk returning bad data. |
| Filter drivers that monitor the filesystem continuously | Occasional | Microsoft's resolution guidance says to try disabling virus scanners, backup programs and disk defragmenter tools that continually monitor the system. These sit directly in the I/O path and a misbehaving one produces exactly this. |
| Non-paged pool depletion | Occasional | The one people miss. Microsoft notes that if non-paged pool memory is completely depleted this error can stop the system, and that during indexing a very low pool level lets another driver requiring pool trigger it too. That is a driver leaking memory, not a disk problem at all - and it has a completely different fix. |
| Failing RAM | Occasional | Corrupted metadata in memory produces the same detection. Worth testing when the disk checks out clean. |
Narrowing it down
Check the disk first, but keep the pool case in mind if the disk is healthy.
Check drive health before anything else
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.
Any non-zero pending or uncorrectable count makes the drive the answer. A clean bill of health moves the investigation to filter drivers and pool exhaustion.
Look for storage errors preceding the crash
Microsoft's guidance says to check Event Viewer for hard drive messages that might pinpoint the device or driver. Filter the System log around each crash for disk, Ntfs and storahci - event IDs 7, 51, 55 and 98 in particular.
Storage errors immediately before the bugcheck confirm the subsystem and often name the specific device. A completely clean log before the crash is more consistent with the pool or filter-driver cases.
Check free space and pool usage
Microsoft recommends 10 to 15 percent free space on the system volume. Also check whether non-paged pool is being consumed - open Task Manager, Performance, Memory, and look at the paged and non-paged pool figures, or use Resource Monitor.
A non-paged pool figure that grows steadily and never falls back is a driver leak, and it points at the pool depletion case rather than the disk. That reframes the whole investigation - see the Driver Verifier fix below rather than chkdsk.
Record parameter 1 across crashes
Take the first parameter from each bugcheck event.
The same value every time means the same internal check is failing - a consistent, specific fault. Values that vary suggest more general corruption, which favours failing hardware over a single damaged structure.
Fixes, cheapest first
Disk first, unless the pool figures pointed elsewhere.
Scan and repair the filesystem
Start with a read-only scan, which is safe on a running system:
chkdsk C: /scanIf it reports problems, schedule a full repair:
chkdsk C: /f /rThat requires a restart, and the
/rsurface scan takes a long time.Watch outIf SMART already indicates a failing drive, back up before running
/r. A surface scan on a dying disk can push it over, and the backup matters more than the repair.Disable software that monitors the filesystem
Microsoft's guidance names this explicitly. Temporarily disable or uninstall third-party anti-virus, continuous backup software, and any third-party defragmenter or disk optimiser that runs in the background.
Use the vendor's dedicated removal tool for anti-virus rather than the standard uninstaller - these products routinely leave filter drivers behind that the uninstaller misses, and the filter driver is the part that matters here.
Check and update storage drivers
Since Microsoft names corrupted storage controller drivers as a cause, check what is actually driving your controller in Device Manager under IDE ATA/ATAPI controllers.
Update the chipset package from your board vendor. Also check for SSD firmware updates - firmware bugs that corrupt data under specific conditions are real and are fixed this way.
Free up disk space
Microsoft suggests keeping 10 to 15 percent of the system volume free. A nearly full volume constrains the page file and leaves the filesystem little room to work. Cheap to fix and removes a variable.
Verify system files
Run
sfc /scannow, thenDISM /Online /Cleanup-Image /RestoreHealth, thensfc /scannowonce more.Find a pool leak with Driver Verifier
If non-paged pool usage climbs steadily and the disk is healthy, a driver is leaking allocations. Driver Verifier with Pool Tracking enabled identifies it. Microsoft names Verifier in this bugcheck's resolution guidance.
Settings and the boot-fail safety flag are in the Driver Verifier guide.
Watch outChasing the disk when the actual problem is pool exhaustion wastes days, which is why the two-minute pool check in triage is worth doing first.
Verifier deliberately increases crashes and can cause a boot loop. Run
verifier /bootmode resetonbootfailbefore 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 byverifier /reset. Full settings and the escape route are in the Driver Verifier guide.Test the memory
Worth doing when the drive is healthy and no filter driver is implicated. Disable XMP or EXPO, then run MemTest86 for at least four passes - see the memory testing guide.
When it is the hardware, not Windows
Signals that the drive is failing rather than the filesystem merely being damaged:
- SMART reports reallocated, pending or uncorrectable sectors.
chkdskfinds and fixes errors, and they return within days.- The machine freezes for seconds during file operations, outside of crashes.
- Files that were readable become unreadable over time.
- Other storage-related stop codes appear too - 0x7A, 0xEF, 0x7B.
- A clean Windows install onto the same drive develops the same problem.
Filesystem corruption on a healthy drive is a one-off event with a cause - an unclean shutdown, an interrupted write - and chkdsk genuinely fixes it. Filesystem corruption that keeps coming back is a symptom, not the disease. If you have run chkdsk three times and it keeps finding new errors, stop repairing and start copying data off.
Frequently asked
Can I just replace ntfs.sys?
You can restore it with sfc /scannow, and it is worth ruling out - but a genuinely corrupt ntfs.sys is uncommon, and replacing it will not help if the disk beneath it is returning bad data. The driver is doing its job by refusing to continue with impossible filesystem structures. Check the drive first; the file itself is rarely the problem.
How is this different from KERNEL_DATA_INPAGE_ERROR?
Different detection points on the same path. 0x7A means a read from the paging file failed outright and carries an I/O status code naming why. 0x24 means the read succeeded but what came back was not valid NTFS. Both usually indicate a storage problem, and seeing both on one machine is a strong combined signal for a failing drive.
The disk is healthy and chkdsk finds nothing. What now?
Two directions. Check non-paged pool usage over time - if it climbs and never recovers, a driver is leaking and that is Microsoft's documented alternative cause, with a completely different fix. And disable third-party anti-virus, backup and defragmentation software, which Microsoft's guidance names specifically because they sit in the filesystem I/O path. If both come back clean, test the memory.
Should I convert to a different filesystem?
No. NTFS is not the problem, and Windows requires it for the system volume anyway. This bugcheck reflects something underneath the filesystem failing, or something layered on top interfering - neither of which changes by using a different format. If the drive is failing, replace the drive.
Related errors
- 0x0000007AKERNEL_DATA_INPAGE_ERRORWindows couldn't read data back from disk. Parameter 2 usually names the exact cause.
- 0x000000F4CRITICAL_OBJECT_TERMINATIONA process or thread Windows needs has exited. Parameter 3 names which one.
- 0x0000007BINACCESSIBLE_BOOT_DEVICEWindows couldn't reach its own boot drive. Check UEFI storage mode before anything else.