Event ID 55 and 137: NTFS corruption appears on SAN and iSCSI volumes

Fix it now

Event ID 55 is NTFS saying the file system structure on the disk is corrupt and unusable and asking you to run chkdsk. On SAN or iSCSI storage the media is almost never the problem: a write was acknowledged and never landed. Stop writing to the volume, scan it online, and find the storage event that caused it.

fsutil dirty query X:
chkdsk X: /scan
Repair-Volume -DriveLetter X -Scan

1. Move or shut down anything writing to the volume first. If it holds a clustered role or virtual machines, get them off before you touch the file system.
2. Look for Event ID 98 next to the 55. It names the volume and tells you plainly that it needs to be taken offline for a full chkdsk, which means an online scan is no longer enough.
3. Where an offline pass is needed, schedule it: chkdsk X: /f for the repair, or chkdsk /f /r where you also want bad sectors located and readable information recovered.
4. Read the System log for the same window. Microsoft groups 55 and 98 with events 129, 153 and 157 for a reason: the storage event is usually the cause and the NTFS event the consequence.
5. Take a backup or storage snapshot of the volume as it stands before any offline repair.

On a clustered disk or a Cluster Shared Volume, put the resource into maintenance mode first and run the repair from the coordinator node, not from wherever you happen to be logged on.

If the scan is clean, the dirty flag is clear and the storage events have stopped, you can stop here. The next section explains how a healthy disk produces a corrupt file system.

Why it happens

NTFS keeps a journal so that a crash leaves the file system consistent: metadata changes are written to the log before they are applied, and the log is replayed on mount. That guarantee rests on one assumption – when the storage says a write is durable, it is durable. Break the assumption and the journal becomes fiction.

There are ordinary ways to break it on shared storage. A path fails mid-write and the array acknowledges data it never committed. A thin-provisioned LUN runs out of real capacity while the host still believes it has space. A controller cache is enabled without the power protection it assumes and the server loses power. In each case the disk surface is perfect and the structure on top of it is not.

This is why the two events matter in a specific order. Event 55 says the structure is corrupt and unusable and asks for chkdsk. Event 98 goes further: it names the volume and its device path and states that it needs to be taken offline for a full chkdsk, telling you to run CHKDSK /F locally or REPAIR-VOLUME <drive:> locally or remotely from PowerShell. A 55 without a 98 may still be repairable online; a 98 is the point at which it is not.

Full reference

Repair commands and what each one costs

Which events Microsoft groups with these

Microsoft’s own data corruption guidance lists 50, 55, 98 and 140 as the NTFS corruption indicators, and puts the storage events beside them. Reading the file system event alone, without the storage events from the same window, is how a path problem gets treated as a disk problem.

A full offline repair takes the volume out of service for as long as it takes – on a file server with millions of small files, hours – and it can discard data it cannot reconcile. Back up or snapshot the volume as it stands before you start. On a clustered disk or CSV, suspend the resource so the volume is in maintenance mode, and repair only from the coordinator node.

Repairing in the right order

1. Stop the writes. Move roles and virtual machines off, or shut them down.
2. Take a backup or storage snapshot of the volume in its damaged state.
3. Run the online scan and read what it reports.
4. Fix the storage-side cause, if the System log shows one.
5. Run the offline pass only if the scan or an event 98 says it is needed, in a window sized for the file count rather than the volume size.
6. Re-run the scan afterwards and confirm the dirty flag is clear.
7. Restore anything the repair detached or discarded, from a backup taken before the damage.

When the volume is clean and the events keep coming

• Check whether the same LUN is presented to more than one host without cluster arbitration. Two servers writing to one unshared LUN produce exactly this pattern.
• Check the array’s own event log for the same window; it may record a controller failover the host only saw as latency.
• Confirm the volume is not being snapshotted by two products at once, which shows up as intermittent damage on an otherwise healthy path.
• If the volume is a CSV, look for events 5120 and 5142 in the FailoverClustering log. A CSV that lost its path mid-write is the storage story behind the NTFS one.

Every code this article covers

Confirm the fix worked

1. fsutil dirty query X: reports the volume is no longer flagged.
2. chkdsk X: /scan completes with no damage found.
3. A week passes with no new Ntfs events on that volume.
4. No storage resets, path losses or pool capacity warnings appear in the same period.
5. A test restore from backup of a file on that volume opens correctly, proving the backup taken before the repair is usable.

Questions people ask about this