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.exex. 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.exex 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!