EVENT ID 55: When Good Bits Go Bad

EVENT ID 55: When Good Bits Go Bad

  • Comments 11
  • Likes

My name is William Effinger, and I am a Senior Support Escalation Engineer with the Windows Core team at Microsoft. Some of the most common questions we get here at the storage team center around CHKDSK. If you have ever come across any event ID 55s in your system event log, this blog is for you.

What is an event ID 55? Let’s start by looking at the error:

Event Type: Error
Event Source: NTFS
Event ID: 55
Description:
The file system structure on disk is corrupt and unusable. Please run the chkdsk utility on the volume "Drive_letter:"

While the error description is direct and self-explanatory, we often receive calls from customers who want to better understand how this occurred and their subsequent options.

How did we get into this situation to begin with?

The file system does not proactively check each write (doing so would hugely impact performance, as you can imagine). NTFS instead has a logic that checks some reads for congruence. As a preventative measure, we can only suggest best practices such as keeping up to date with drivers and firmware.      

We do know, however, that the corruption that we see in the file system is due one of two things: either a hardware problem or an issue with the file system driver.

The majority of the issues we see revolve around problems with hardware. As a rule of thumb, hardware tends to corrupt unpredictably.

If you suspect hardware, the following techniques will likely help you identify the culprit:

  • Install the latest SCSIPORT/RAIDPORT update(s).
  • Remove or update filter drivers.
  • Update 3rd party storage drivers /firmware.
  • Try switching to different type of driver (raidport vs. monolithic).
  • P2V the machine and try using a different storage method (virtualized SCSI or ATAPI).
  • If all else fails, rearrange hardware into various combinations.

While extremely rare, NTFS issues can certainly happen. Unlike hardware, NTFS will leave a trail of very specific clues in the corruption leading straight to the offending code. Due to the exceptionally large install base of NTFS, opportunities for corruption have already been identified and resolved. If a software concern still remains, updating the latest version of NTFS would be a prudent course of action.

The only option left for Microsoft support is to look over your server and provide an analysis of the storage stack health. To do that, we look for filter and out of date storage drivers. Then we attempt to eliminate multi-pathing and/or contact the storage vendor suggesting updates as necessary.

Sometimes identifying the root cause of the corruption is less important than resolving the corruption itself. Event ID 55 has alerted you to the fact that there is corruption on the volume, and the only tool capable of resolving the file system corruption is CHKDSK. Unfortunately, customers are unable to use the corrupted volume while CHKDSK is repairing problems with the file system and estimating downtime is impossible. My colleague summed this up in his blog “Questions you shouldn't call Microsoft for...

If you have any event ID 55s in your system event log, it’s time to run CHKDSK. The longer you wait the worse it is likely to get.

William Effinger
Senior Support Escalation Engineer
Microsoft Enterprise Platforms Support

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Nice blog William, "NTFS instead has a logic that checks some reads for congruence", it would have been great if you would have had expaliend that logic.

  • Agred, and does this logic move forward into windows 2012?

  • Nice article. the only problem is that on my windows 2003 server it only says

    The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume . as you can see it only gives a dot and not drive letter. what are my options?

    thanks

  • This is the long version of "I Don't Know".

  • I am seeing the same problem as RobK - no drive letter listed, just a blank space and then the full stop. I ran chkntfs on both of the volumes in the server and neither were dirty.

    Has anyone found the cause / solution for this?

  • William article is great help in understanding but i want to know even after run chkdsk or chkdsk/r  with no errors, if we keep on getting the event id generated. Does that mean sth wrong?

  • I have had Error 55 on a VM's VHD which I believe resulted after a catastrophic power outage! I succeded in bringing up the VM from snapshots and have stopped it, copied out the files to a new host and imported the VM, yet on starting the VM it still gives me the Launch Startup Repair Screen. I do that it attempts to repair disk errors and restarts but ends in a blank BLACK screen. I stop and restart the VM from a boot disk and repair the installation from command propmt - hence running CHKDSK (both /f and /R) and they find no errors. Yet the VM does not load windows properly. What more can I do?

  • After this blog post was published, NTFS Event 55's (and NTFS corruption handling in general) got a major overhaul.  The NTFS Event 55 in Windows 8 / Server 2012 conveys more information and is easier to interpret.

    @Prabhash:  When NTFS reads any of its own metadata (e.g. MFT records, directory index blocks, etc.) from disk, it performs basic sanity checks to make sure it is well-structured.  If any of these checks fail, the file is considered corrupt.  But as Jeff points out, NTFS doesn't perform these checks when writing out metadata to disk, as that would be redundant and slow down performance.  NTFS also never performs checks on the contents of data files, because the contents are unstructured and NTFS doesn't know what it's supposed to look like.  In other words, NTFS is only capable of detecting metadata corruptions, not data corruptions.

  • Got a clue which disk this is referring to? volume \\?\Volume{ba575eda-a0e7-11e0-a61b-806e6f6e6963}. When I try to follow the link it returns that the link might not be valid.

  • @Mark I get the same error with the same volume label, sometimes every 10 seconds for hours. Have run the extended fix chkdsk on every volume on the machine to no avail. Have you gotten a solution?

  • [Quote]
    The file system does not proactively check each write (doing so would hugely impact performance, as you can imagine).
    [/Quote]


    Well, if that is all you can come up with, why not make this an option for any selected drive, folder, file that companies require.

    Have you any idea the amount of scaremongering this error causes ?

    At least give a more descriptive message including full file path \ volume \ disk subsystem \.folder \ file ffs

    Also, please publish in this thread a link to the latest NTFS update for affected operating systems.

    I have already implemented one and have another on the sideline should errors continue,

    My hardware suppliers have been on this case for a week now and all our log collects tell us things are A1..

    I don't care about many things, but disk failure / ignorance of event 55 can potentially affect peoples jobs.

    Restore some faith please otherwise adopt another file system if you regard business customers as your continued partners.

    Victim (dougie).
    .