disk / Ntfs Storage and filesystem error events - which ones mean a dying drive
Search any storage event ID and you will be told your drive is failing. Usually it is not. Most of these record something that was detected and handled - a retry that succeeded, an error the drive's own correction fixed, or in one notorious case a routine health check reporting that everything is fine. Four of them genuinely justify replacing hardware. This page separates them.
What you are looking at
In Event Viewer the matching entries look like this:
Log Name: System
Source: disk
Event ID: 153
Level: Warning
The IO operation at logical block address 0x1a2b3c for Disk 0 (PDO name: \Device\0000003a) was retried.Log Name: System
Source: Microsoft-Windows-Ntfs
Event ID: 98
Level: Information
Volume C: (\Device\HarddiskVolume3) is healthy. No action is needed.What the error actually means
One structural fact explains most of the confusion. The disk, storahci, stornvme and volmgr providers all draw their messages from the same kernel resource file. These are not per-driver event IDs - they are the generic kernel I/O error codes.
So a given ID means the same thing no matter which provider logged it. The provider name only tells you which layer of the storage stack noticed. Asking what the storahci events are is a category error: they are the disk events with a different name attached.
This matters more here than anywhere else on the site. Filtering the System log by Id=153 without naming a provider returns mostly Microsoft-Windows-Kernel-Boot telemetry, which has nothing to do with storage. On a typical machine the great majority of ID-153 hits are unrelated.
The same collision exists for IDs 7, 11, 51, 55, 98 and 140. Always scope by provider.
Reading the parameters
The events you will actually meet. Severity is what Windows itself assigns, and it is not always what you would expect.
| Parameter | What it holds |
|---|---|
| disk 52 - Warning | "...has predicted that it will fail. Immediately back up your data and replace your hard disk drive." This is SMART speaking through the event log, and it is the one unambiguous replace-the-drive event in the entire set. Note it is only a Warning, which is why it gets missed. |
| disk 7 / 31 - Error | "The device has a bad block" / "The file on device contains a bad disk block." Genuine media damage. Modern drives remap bad blocks silently, so what matters is whether the count is growing, not whether any exist at all. |
| disk 154 - Error | "The IO operation... failed due to a hardware error." The I/O did not recover. This one is missing from almost every published list of storage events, and it is the counterpart that actually indicates failure. |
| disk 153 - Warning | "The IO operation... was retried." A timeout that was retried successfully. A latency signal, not a media-integrity signal. Isolated ones are normal. |
| disk 129 - Warning | "Reset to device was issued." The storage port timed out and reset the unit; outstanding requests were retried. Same family as 153, one layer up the stack. |
| disk 11 - Error | "The driver detected a controller error." Not the platter. Cable, port, power supply and driver are all likelier than the drive itself. |
| disk 51 - Warning | "An error was detected during a paging operation." Ambiguous by design, and Microsoft documents outright benign cases - blank optical media with a USB device attached, for one. |
| disk 33 - Warning | "Data was recovered using error correction code." This is success. Correction worked and nothing was lost. Logged as a warning, read as a disaster. |
| disk 155 - Warning | An I/O took longer than the expected maximum. Performance information only, not a fault. |
| Ntfs 55 - Error | "A corruption was discovered in the file system structure." Real corruption. The modern wording differs from the older "run the chkdsk utility" text still widely quoted. |
| Ntfs 98 - Information | Usually good news. See the box below - this is the most misreported event in the set. |
| Ntfs 140 - Warning | "The system failed to flush data to the transaction log." Unusually rich payload: it names the physical device manufacturer, model, revision and serial number, which makes it the best event here for attributing a fault to a specific drive in a multi-disk machine. Known to fire benignly on read-only or offline volumes, so corroborate before acting. |
What actually triggers it
Search it and you will be told it indicates corruption and that you should run chkdsk. Microsoft's own troubleshooting article lists it among events that indicate data corruption or disk errors.
It is an Information-level event carrying a variable status string, and on a healthy machine that string reads "is healthy. No action is needed." On one test system, all eighty logged instances said exactly that.
Read the status text rather than reacting to the ID. Go looking for Event 98 expecting bad news and you will find dozens of routine health reports and conclude your drive is dying.
What causes the events that do matter:
| Cause | How often | Detail |
|---|---|---|
| A drive at end of life | Common | Produces Event 52 when SMART crosses its own threshold, and growing counts of 7 and 154. This is the case everyone assumes they have, and sometimes they are right. |
| Cabling, port or backplane | Common | Produces 11, 129, 153 and 51 - the timeout and controller family. A loose SATA cable generates exactly the pattern people mistake for a dying disk. |
| Storage driver or firmware | Common | Outdated controller drivers and SSD firmware cause timeouts and retries. Firmware fixes for drives dropping off the bus are real and shipped regularly. |
| Overload | Occasional | Microsoft's current guidance frames Event 153 primarily as a throughput problem, prescribing controller and queue remedies rather than drive replacement. |
| Power management | Occasional | Aggressive link power management and drive spin-down produce timeouts on wake that look exactly like faults. |
| Virtualization artefacts | Occasional | Inside a VM, or on a host running backups, these events frequently come from the virtual disk layer rather than any physical device. Mounted-then-unmounted virtual disks generate them routinely and harmlessly. |
Narrowing it down
Collect the events with correct scoping, then sort them into recovered and not-recovered.
Collect the storage events properly
Scope by provider, because the ID collisions here are severe:
$xpath = @"
*[System[
Provider[@Name='disk' or @Name='storahci' or @Name='stornvme' or @Name='volmgr']
and (EventID=7 or EventID=9 or EventID=11 or EventID=51 or EventID=52
or EventID=129 or EventID=153 or EventID=154 or EventID=157)
]]
"@
Get-WinEvent -LogName System -FilterXPath $xpath -EA SilentlyContinue |
Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
Format-Table -AutoSize -WrapAny Event 52 ends the investigation - back up now and replace the drive. Otherwise sort what you have: 7, 31 and 154 are the media-damage family; 11, 51, 129 and 153 are the path-and-timeout family. They lead to very different places.
Decode a 153 rather than counting them
Event 153's binary payload carries the SCSI status, SRB status and operation code at byte offsets 29, 30 and 31. That tells you why it timed out:
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='disk'; Id=153} -EA SilentlyContinue |
ForEach-Object {
$b = ($_.Properties | Where-Object { $_.Value -is [byte[]] }).Value
[pscustomobject]@{
Time = $_.TimeCreated
Scsi = '0x{0:X2}' -f $b[29]
Srb = '0x{0:X2}' -f $b[30]
Op = '0x{0:X2}' -f $b[31]
}
} | Format-Table -AutoSizeSRB 0x09 or 0x0B means the request was sent and nothing answered in time. 0x0E means the device was reset and the request replayed. 0x04 points at controller, cable or drive. 0x08 or 0x0A mean the device was not there - which on a machine running backups is a virtual disk being unmounted, and entirely benign. Operation 0x28 is a read, 0x2A a write.
Check drive health directly, and be careful how
Read SMART with CrystalDiskInfo, or from an elevated PowerShell:
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, HealthStatus, OperationalStatus
Get-PhysicalDisk | Get-StorageReliabilityCounter |
Select-Object DeviceId, Wear, Temperature, ReadErrorsUncorrected, WriteErrorsUncorrected, PowerOnHoursUncorrected read or write errors corroborate the media-damage events.
The widely-copied MSStorageDriver_FailurePredictStatus query is an ATA-era interface. On a modern NVMe system the class exists but returns zero instances - which reads as "no problem found" when it actually means "not implemented". Use the commands above, or vendor tooling.
Establish whether the fault follows the drive or the port
Move the disk to a different cable, port or controller and watch whether the events move with it.
The strongest single discriminator available. Events that follow the disk indict the disk. Events that stay with the port never were about the disk at all - and this test settles in an afternoon what log-reading cannot settle at all.
Fixes, cheapest first
What to do depends entirely on which family you are in.
If you have Event 52: back up now
SMART has crossed its own failure threshold. This is not a judgement call and not a signal to investigate further - copy your data off, then replace the drive.
Everything else on this page is diagnosis. This one is a deadline.
Check cabling and connections
The correct first move for Events 11, 129, 153 and 51. Power down fully and unplug at the wall, then reseat both ends of the data cable and the power connector, or reseat the M.2 drive and its screw. Try a different port and a different cable.
Unremarkable, and it resolves a real share of what gets diagnosed as drive failure.
Update storage drivers and firmware
Install the chipset package from your board or system vendor rather than relying on Windows Update, and check the drive maker's tool for a firmware update. Fixes for drives timing out or dropping off the bus are genuine and shipped regularly.
Watch outBack up before flashing drive firmware, run it on mains power, and do not interrupt it.
Check the filesystem
For Ntfs 55, start with a read-only scan:
chkdsk C: /scanIf it reports problems, schedule the repair with
chkdsk C: /f /r.Watch outIf SMART already indicates a failing drive, back up before running
/r. A full surface scan on a dying disk can push it over the edge, and the backup matters more than the repair.Reduce load and power management
Appropriate when 153s are frequent but the drive is healthy. Disable aggressive link power management in the power plan, remove third-party disk utilities and filter drivers you do not need, and consider whether the workload is simply saturating the storage path.
When it is the hardware, not Windows
Replace the drive if any one of these is true:
- Event 52 - SMART has predicted failure. Non-negotiable.
- Events 7 or 31 growing over time, corroborated by rising uncorrected error counts.
- Event 154, especially repeating at similar block addresses.
- Event 55 returning after a successful
chkdsk /f /r- the filesystem keeps re-corrupting, so the media is not holding writes. - The events follow the drive when you move it to a different port or cable.
Do not replace a drive on 153, 129, 51, 11 or 155 alone. Those indict the path - cable, backplane, controller, driver, firmware, power management, or simply too much load. A drive returned as faulty on the strength of a few retry events comes back marked no-fault-found, and you will have lost weeks.
Frequently asked
I have hundreds of Event 153s. Is my SSD dying?
Probably not, and Microsoft's current guidance frames this event as a throughput problem before a hardware one. Event 153 means an I/O did not complete in time and was retried successfully - the data got through. It is a latency signal.
That said, do not dismiss it either. Microsoft's own engineering write-up on this event says frequent retries indicate a storage performance issue that should be corrected. Decode the SRB byte to find out why they are timing out, and check cabling before suspecting the drive.
What is the difference between Event 153 and Event 154?
Recovery. 153 means the operation was retried and succeeded; 154 means it failed with a hardware error and was not recovered. That is the whole distinction, and it is why 154 is the one worth acting on.
Almost every published list of storage event IDs includes 153 and omits 154 entirely - which means the event that actually indicates failure is missing from the guides people rely on.
Event 11 says controller error. Is that the drive?
The message says controller, and it means it literally - the error was detected in the path rather than on the media. Cable, port, backplane, power supply and driver are all likelier than the drive. Check the physical connection first, then move the drive to a different port to see whether the event follows it.
Ntfs 98 keeps appearing. Should I be worried?
Read what it actually says. Event 98 is Information-level with a variable status string, and the overwhelmingly common value is that the volume is healthy and no action is needed. It is a routine periodic health report.
Guides that list it as a corruption indicator - including Microsoft's own troubleshooting article - are wrong as a general claim. The genuine corruption event is Ntfs 55.
These events only appear during my nightly backup. Does that mean anything?
It probably means they are artefacts of the backup rather than faults. Backup software mounts and unmounts virtual disks, and the storage stack logs timeouts and no-device conditions when that happens. Decoding a 153's SRB byte settles it: 0x08 or 0x0A mean the device was not present, which is exactly what an unmounted virtual disk looks like.
Do these events map onto specific SMART attributes?
Not in any documented way. Mappings you find online between Windows event IDs and SMART attribute numbers are inference. Event 52 is the only event here that is a direct SMART assertion, and even that does not tell you which attribute crossed its threshold - read the drive's SMART data with a proper tool for that.
Related errors
- 0x0000007AKERNEL_DATA_INPAGE_ERRORWindows couldn't read data back from disk. Parameter 2 usually names the exact cause.
- 0x00000024NTFS_FILE_SYSTEMA fault inside the NTFS driver. Almost always the disk under it, not the driver.
- GuideFinding Your Crash History: Event Viewer, Reliability Monitor and PowerShellBuild a timeline of every crash the machine recorded. The pattern beats any single dump.