NTFS_FILE_SYSTEM (0x24)

Read your own dump before changing anything

Every blue screen with small-dump recording on leaves a file in C:\Windows\Minidump. Drop the newest one on DumpReader: it decodes the stop code and its four parameters, lists the drivers that were loaded, recovers the addresses on the crashing thread's stack and names a probable culprit with a confidence level. The file is read inside your browser and never uploaded. If the folder is empty, the guide to finding and reading a .dmp file shows how to turn recording on, so the next crash leaves evidence.

What you are looking for on an NTFS_FILE_SYSTEM report is not the stop code — you already have that — but three things around it: whether a third-party filter driver (anti-virus, backup, encryption, disk tools) is on the stack, whether a storage driver other than Microsoft's is loaded for the system disk, and whether the first parameter repeats from one crash to the next.

What the four parameters mean

The middle column is Microsoft's definition, word for word. The right-hand column is what the value is good for when all you have is a minidump.

Parameter 1 is the one worth writing down. Because it identifies a location inside NTFS's own code, two crashes with the same value failed the same internal check. If every dump shows the same parameter 1, look for one persistent cause — one damaged volume, one driver. If it changes every time, and other stop codes appear in between, the pattern points away from NTFS altogether and towards something that corrupts memory at random, which is most often RAM.

What causes it

Microsoft's bug check reference lists these, and they are worth reading in its own words because they are less certain than most forum answers:

• Disk corruption. “Corruption in the NTFS file system or bad blocks (sectors) on the hard disk can induce this error.”
• Storage drivers. “Corrupted hard drive (SATA/IDE) drivers can also adversely affect the system's ability to read and write to disk.”
• Software that watches the disk. Microsoft's resolution steps include disabling “any virus scanners, backup programs, or disk defragmenter tools that continually monitor the system” — these install file-system filter drivers that sit in the same path as NTFS.
• Memory pressure, historically. The page notes that depletion of nonpaged pool memory has also produced this stop code in the past.

Notice what is not on the list: nothing says the disk is certainly failing. A dump cannot see bad sectors at all — it records what the kernel was doing, not the state of the platters or flash cells — so the disk's health has to be checked separately, with the tools in the next section.

What to check, in order

1. 1

   Back up what matters

   If the disk is the cause, it may get worse with use, and a repair scan can move unreadable fragments of files aside. Copy anything irreplaceable to another drive before running anything that writes to this one.

2. 2

   Read the System log

   Open Event Viewer → Windows Logs → System and filter for errors and warnings from the sources disk, Ntfs and your storage controller around the time of the crash. Repeated disk errors before the blue screen are the most direct evidence you will get that the hardware is involved.

3. 3

   Check the drive's health

   Run the manufacturer's diagnostic for the drive — Microsoft's own advice for this code. It reads the drive's internal error counters, which neither Windows nor the dump can see.

4. 4

   Scan the file system

   From an administrator prompt, chkdsk C: /f repairs file-system structures; /r also looks for bad sectors and takes much longer. On the system drive both run at the next restart. Afterwards, the result is in Event Viewer under Application → Wininit, event 1001 — the chkdsk log reader explains what it changed and identifies anything it moved to FOUND.000.

5. 5

   Free some space

   Microsoft suggests keeping 10–15 % of the drive free, because Windows and applications need room for swap files and other working data.

6. 6

   Take filter drivers out of the path

   If your dump shows anti-virus, backup, encryption or disk-utility drivers on the stack, update them, or uninstall them for a few days and see whether the crashes stop. Removing one variable at a time is slower and the only way to learn which one it was.

7. 7

   Repair system files

   sfc /scannow checks and restores Windows' own files. Its log, CBS.log, is long and hard to read; the CBS.log reader lists what it actually found and fixed.

8. 8

   Driver Verifier, last

   If crashes continue and the disk is healthy, Driver Verifier (verifier) watches chosen drivers and makes a misbehaving one crash at the moment it breaks a rule, which produces a far more specific dump. Verify as few drivers as possible — it slows the system — and remember to turn it off with verifier /reset.

No dump file? Find the code in Event Viewer

After the restart, Windows records the crash twice. Event 1001 in the System log includes a line such as The bugcheck was: 0x00000024 followed by the four parameters. Event 41 from Kernel-Power records the same crash with BugcheckCode written in decimal — Microsoft's documentation notes this explicitly — so NTFS_FILE_SYSTEM appears there as 36, not 24. Either gives you the parameters, which is enough to compare crashes even when no dump was saved.

Common questions