vista-sp2-chkdsk..."deleting index entry...." doesn't

OK folks, this one is a head scratcher.

Got a laptop sitting in front of me with Vista sp2 64-bit.

Several weeks ago the disk developed some file system corruption according to the owner. Chkdsk ran at startup as expected and "appeared" to clear up the problems.

Windows starts and appears to run properly--except one error occurs sporadically--the Cryptographic service some times failes to load.

However. Running a chkdsk now results in about 10 entries

Deleting index entry xxxxxxx in index $I30 of file ?????
Deleting index entry xxxxxxx in index $I30 of file ?????
Deleting index entry xxxxxxx in index $I30 of file ?????
Deleting index entry xxxxxxx in index $I30 of file ?????
Deleting index entry xxxxxxx in index $I30 of file ?????
Deleting index entry xxxxxxx in index $I30 of file ?????
Deleting index entry xxxxxxx in index $I30 of file ?????
Deleting index entry xxxxxxx in index $I30 of file ?????

xxxxxxxxx and ????? are always the same files.

Followed by 10 entries that say

RECOVERING FILES..... xxxxxxxxx
RECOVERING FILES..... xxxxxxxxx
RECOVERING FILES..... xxxxxxxxx
RECOVERING FILES..... xxxxxxxxx
....

some of the files mentioned (wmplayer.exe) are not critical files, but a couple having to deal with the cryptographic service are (though the cryptographic service does start MOST of the time. Every one out of 10 boots, it does not. The files appear to be present, though.

Weird, huh?

Now, I know what "Deleting index entry xxxxxxx in index $I30 of file ?????" means--the master file table entry for that file location is incorrect, but I cannot seem to clear these errors.

Now, I know I can wipe the drive and start over...that will delete the MFT and we should be OK...but I haven't run into this before and I wonder if there is another way.

Ran chkdsk with ever conceivable /switch without success.

There are NO bad sectors on the drive; nor according to SMART are any sectors being reallocated.

Left my spinrite disk at home, but that is next up.

I have one more idea--I think that changing the partition size will cause the MFT to resize--or maybe just defragging the MFT with an industrial strength defragger will work.

Other than that, I am out of ideas at the moment. I've got a two hour drive home tonight so I will have plenty of time to think about some other ideas, but I figured I'd give you guys a head start.

I googled to no end, but those few cases where I have seen this issue, people just gave up and reinstalled.

So, two hours before I can check back....starting now....

 

You could always try to repair the MBR from the recovery console, then do a massive defrag. I like your idea of resizing a partition - that might shake things up enough to "fix" the problem. I hope something like that helps, because I read all of those various threads, too, and it's too bad that a reformat ends up being the fix.

 

ouch, was hoping for more ideas

Yes, I think a massive defrag that also defrags/move the mft might shake things up...will try Mydefrag on slow optimize first before other options.

Not sure I follow your thinking on the MBR, though.

The MBR is a partition record that occurs outside the realm of the file system, as does the partition boot record. The MFT is part of the file system.

They really shouldn't have anything to do with each other unless I am just missing what you are saying.

But, thank you for the defrag...the MFT is only in one fragment, but Mydefrag will move it to the front of the drive and moving it may yield the results I am after.

 

another tidbit for anyone who cares...

testdisk confirms that the MFT mirror is corrupt and unwriteable....which is darned odd.

will try a repair that by dropping the drive in another machine tomorrow and attempting a repair then.

 

are you sure the drive is still fine? i had it once that a drive was faulty, but only a tiny bit, and it created all sorts of similar errors like you report.

maybe cloning to another drive will
a) fix the problem
b) reveal the problem (means, cloning will fail.. which is not fun, but shows exactly where on disk the problem is, as you see how far it can clone).

for me, it was b)..

 

yes, a clone is on for the morning before I do anything scary like a partition resize with an unstable MFT mirror.

In fact, I wish I would have cloned it first--though a clone, assuming the drive is physically OK, would actually just clone the problem MFT and disk corruption.

I say wish because here is another interesting bit of info from the event logs.

While I have been running MyDefrag in industrial mode (which moves the mft as well as other hidden files), I've received numerous

"The file system structure on the disk is corrupt and unusable. Please run the chkdsk utility on the volume ...."

warnings.

OK, that is not completely unexpected given the nature of the issue. But here is the interesting parts. After a series of these--while MyDefrag is still running, I also get

The file system structure on volume C: has now been repaired.
.....
26084: Deleting an index entry from index 0x300000002513d of file 0x4000000024f4d.
27094: An index entry of index 0x300000002513d points to unused file 0x4000000024f4d.
25009: End repair on 08/05/2009 at 01:56:24:913

Now, after reading through the Windows Internals chapter on File Systems until my eyes were bleeding, this makes a little bit of sense...ntfs is after all a semi self-healing file system.

That's why you normally don't have to run chkdsk at all, or nfts will mark the volume as dirty and chkdsk will run at boot automatically in the worst case scenarios.

Normally, the file system and will self repair without chkdsk--I just never really saw it occuring in real time before. Make me kind of afraid to reboot this thing....

 

I feel like I am reading any Agatha Christie novel here. This is a real mystery. I have no suggestions beyond what you already have planned. Keep us posted.

Gary

 

s'funny--to me it is a Stephen King horror story

Resized the partition to no effect.....hmmm, what else do I have. An offline testdisk session and an attempt to rebuild the MFT mirror I think is next

 

ohmigod...I think I solved it.....got to test this.....(I'm not trying to be a tease, I just had to tell someone I'm so geeked....will post back in a while...have to reinsert the drive in the laptop and see if it works and the laptop isn't with me right now....)

 

Ok, you tease. You have us waiting with, as Robin Williams so eloquently put it, "a worm on our tounge"... baited breath.

Gary

 

OK, after torture testing this all day, the problems are gone.

You guys won't believe this, but the answer--if not the application--is so simple it makes me wonder why in the dozens of threads I've seen on this issue that someone didn't accidently stumble over the solution.

First, the corrupted MFT mirror proved to be a red herring. I was able to clear that using testdisk but the problem continued.

Now, how to fix this (for those who stumble on this in the future)

Executive summary

a)Rename the file(s)
b)Rerun chkdsk /f on affected volume
c)chkdsk will delete the index and recover orphan(s)--but here is the gasser--it recovers orphan(s) with dos file naming conventions!
d)delete the orphans
e)rename files back to original name
f) run chkdsk to confirm process succeeded...you may still get a cleaning index result, but this time without the specific file name and the "stuck" error is cleared.


Details

I tried everything to get this thing straightened out, but I and every other forum cry for help I saw focused on trying to fix the MFT. It wasn't until I walked away for a while that it occured to me that these files all had one thing in common--Windows keeps MULTIPLE copies of them (in some cases, quite a few...you guys were deprived of this piece of info because I was too lazy to type them all in)!

For example, there were 13 different copies of PresentationFontCache.exe, which is part of Net.framework, sprinkled in c:\windows\system32, c:\windows\sysWow64 and quite a few problems folders that are too long and ugly to type.

Well....that seemed very odd to me, and that is when I had a revelation.

For folks who are old enough to remember DOS (and even Windows ME, 98, 95 which sat atop it), one of the more common disk corruption issues was cross-linked files.

I believe this is a reverse cross-linked file situation.

A cross linked file occured when the old FAT(file allocation table)16 and FAT32 had two index entries pointing at the same cluster. One file existed, but the other had been over-written (at least partially). The solution to a cross linked file was to copy both files somewhere else, and then delete them, then restore the two files--half the time, the one of the files was bad, but every once in while, they were both OK, because the cross-linked file portions in a particular cluster were unimportant (maybe a blank page sitting at the end of Word document, for example).

This problem is the opposite.

Instead of two index entries pointing at two file clusters, we have one index entry shared by two (or more) files--and chkdsk doesn't know what to do.

With cross-linked files, the solution was to copy the files, then delete them, so.....why not something similar with this problem? Since you cannot edit the MFT directly, I thought, stop trying to fix an MFT by trying to do things that affect it (resize partitions, defrag the MFT)--instead, change the thing that MFT is recording wrong.

So....

a)Rename the file(s)
Notes: This is not as simple as it might seem sometimes. In my case, all six files were system files. There are a couple of ways you can do this--I actually did most of the fixes with the laptop drive in a second Vista machine. I tried an XP machine first, because it was convenient, but XP was not able to rename/access certain files. Yes, I could have changed the permissions, but I didn't want to mess with that. Changing permissions might have caused issues when the drive was reinserted in the original laptop. Vista, though, was able to access the files cleanly when the drive was in the Vista machine. For the last file, I reinserted the drive in the original laptop and changed the file name with a VISTA PE disk and it worked as well.

You really don't need to rename ALL the files...in the case of PresentationFontCache.exe I only renamed half of them--but you do need to rename the two files that are apparantly sharing the same MFT index entry.

b)Rerun chkdsk /f on affected volume
Notes: Nothing special here. If the other computer gives the volume the letter D, then run chkdsk d: /f..whatever. I ran chkdsk /r once, but it was not necessary--the /f switch worked fine.


c)chkdsk results
Note: chkdsk will delete the index and recover orphan(s)--but here is the gasser--it recovers orphan(s) with dos file naming conventions!
Notes: Didn't see that coming. For example, I renamed the six PresentationFontCache.exe files to PresentationFontCache.exe x. Upon running chkdsk /f, chkdsk deleted the index entry for PresentationFontCache.exe, then recovered and orphan file to the same directory called PRESEN~1.EXE. Cool. I thought about trying to run Windows with these old DOS 8.3 naming conventioned files--which Windows still reads just fine, but I wanted to get this done. It probably would have worked just fine...not sure if the short cuts for the one file that would use it wmplayer.exe would have been valid, though.

(yes, with windows vista 64 there are two wmplayer.exe files)

d)delete the orphans
Note: no point in having them around, though both files did peacefully co-exist in the directory -- not with Windows running (didn't try it), but Windows didn't care if there was a PresentationFontCache.exe and a PRESEN~1.EXE

e)rename files back to original name
Note: PresentationFontCache.exe x became PresentationFontCache.exe again.


f) run chkdsk to confirm process succeeded
Note: a couple of times I got a note during the chkdsk that windows was cleaning old index entries, like this:

Cleaning up 6 unused index entries from index $SII of file 0x9.

but not every time. The renamed files no longer appeared in the list of trouble entries...since I did this after each file alteration, I was able to track the progress.

I did rename two different files in the same pass, just to be sure you could, and both trouble entries cleared just as if I did one, so you need not do all files separately unless you are worried you might lose track of a renamed file.

Final Results

I dropped the drive back in the original laptop and did the last one with a Vista PE disk, then rebooted and crossed my fingers. Windows came up normally.

Ran a chkdsk /f and rebooted. Checked the logs in event viewer. All clean.

I then tested the laptop both manually and ran some torture tests and everything worked fine. Ran an extensive defrag to test read and writes, ran a few benchmarks, did a manual antivirus run...no problems. Ran one last chkdsk /f--the problem had not returned.

In fact, though I didn't think the MFT problem had been causing other issues when I got the laptop it had sporadic "EXPLORER HAS STOPPED WORKING" and "INTERNET EXPLORER HAS STOPPED WORKING" issues. At that time, I had chalked those things up to other problems. However, cleaning the MFT error also cleared these problems as they did not re-occur once through out torture testing.

Hope that doesn't bore people to much, but I hope this helps someone somewhere, someday. Nothing ever dies on the Internet. Every once in a while, I still stumble acros solutions to problems that I wrote years ago!

 

Gerry,

That is what I call perseverance!

Congrats on a job well done.

Gary

 

Fantastic job, Gerry!