[possible solution] fixboot command overwrites partitions with FAT12

[xtknight]

(HOWTO: recover from your NTFS partition being converted to a FAT12 one by the Windows XP recovery console fixboot command.)

What a long fun day... So my Windows wouldn't boot, and I decided to use the fixmbr and fixboot functions to rewrite the boot loader. Long story short, the fixboot command overwrote my NTFS drive C with a FAT12 (FAT16?) boot sector. When I ran chkdsk on C:, it thought it was FAT12, and it found nothing but one log file on the hard disk. I lost 180 gigs of data to the fixboot command, and it 'changed' that partition into a 10MB FAT12 one somehow. It ceased to mount in Linux. Well, it did, kind of: http://xtknight.atothosting.com/Screenshot.png

I decided to backup the FAT12 512 byte boot record to a local file (you know, just in case) with a Linux command like this:

# dd if=/dev/sda1 of=/home/user/sda1boot bs=512 count=1

Now I overwrote the boot record with zeroes to cleanse out the FAT12 stuff.

# dd if=/dev/zero of=/dev/sda1 bs=512 count=1

I then came across a free utility that could be run under MSDOS that would do various data recovery things. http://www.cgsecurity.org/wiki/TestDisk

I tried the Linux version, and much to my dismay, it crashed. However the MS-DOS one worked well (use a Win98 startup disk and put it on there). Once I started that program, I selected my hard disk, and the so-called "NTFS" partition that I lost, went to advanced, and used the Search MFT function. I let it go for a while, and no more than ten minutes later it came up with some information that was supposedly the MFT. I hit 'list files', and voila! My files were back. I chose the Write option to write it to the partition. After I rebooted, I could read my partition just fine and all files were intact.

MS truly isn't lying when they say you shouldn't use fixboot too often. But I didn't know it would overwrite my partition with FAT12 stuff. :roll:

Anyway, as far as I can tell, I can access all files now. Whether you need to overwrite your boot record with nulls, I'm not sure, but all I can say is the thing works now.

 

[Smilin]

I think you perhaps you've done some short circuit troubleshooting here. Fixboot will not overwrite an NTFS boot sector with fat12. Something else has happened.


How did you get into a no boot state to begin with? I would suspect that had something to do with it. For the future, grab someone saavy with diskprobe (or wing it yourself - nothing to lose!) and have them fix the disk.

If your boot sector is shot, there is a duplicate copy in the last sector of the partition. See the partition table for the location, or search each sector for "NTFS" at offset 3. If sector 0 is shot, be sure the last two bytes are 55AA then run a fixmbr to put the code back in place then rebuild the partition table by hand (start and stop sectors will be locations of boot sector+backup). Be sure the partition type is 07 (ntfs).

Also, it's not Fixboot that MS warns you about, it's fdisk/mbr. There is some whitespace between the end of your MBR and the start of the partition table. fdisk/mbr locates the spot to stop whitespace filling by counting back from the end of sector marker. If it is missing your partiton table gets zeroed out.


As for your "Windows wouldn't boot" original problem, this may help you figured what happened:

When windows won't boot as far as ntoskrnl.exe these are the errors that will get thrown:
1. "Invalid partition table", "Error loading OS", "Missing OS" are all errors that indicate a problem with your boot sector or partition table. This also means your MBR is intact.
2. "Ntldr Missing" - Means what it says, but also means your boot sector was read properly.
3. "Missing NTOSKRNL.exe", "Missing or corrupt system" - Problems with boot.ini or system files/registry hives. - Also means that your boot sector is intact.

 

[xtknight]

Not sure of the reliability, but this site (Under Problems Involving the Boot Sector) does say it will overwrite with FAT12 in some cases:
http://bootmaster.filerecovery.biz/appnote3.html

In rather rare cases both the boot sector and its backup are corrupted. Sometimes this situation is complicated by the presence of a FAT12 boot sector in the place of the NTFS boot sector. The presence of the FAT12 boot sector is a "feature" of FIXBOOT. It writes the FAT12 boot sector into place, apparently, when the partition is damaged in a way that prevents it from reliably writing an NTFS boot sector. At any rate, the boot sector must be rebuilt from scratch, regardless of whether or not the FAT12 boot sector is present.

My MFT and backup MFT were both damaged. When I tried the 'errors=recover' option using the Linux ntfs kernel module it mentioned my backup MFT had been damaged. My friend (who also had a Linux/WinXP dual boot) had his drive also turn into FAT16, and he lost all his data (but thankfully he backed it up right before doing that). I think if GRUB is on there, Windows for some reason rewrites FAT16 (or FAT12?) to it. It was actually FAT12 but the drive list command in the recovery console showed it as FAT16. The first time I ran it, Fixboot said my boot record was corrupt, so it wrote a new one. That's when my drive was turned into a 10MB FAT12. I have the first 512 bytes of that partition saved when it was corrupted. It started like this. The serial number had also been blanked out to 0000-0000 after running chkdsk on the 10MB partition. That parition contained a single log file of chkdsk which just said it had fixed errors.

?<?MSDOS5.0
Q
?)NO NAME FAT12 3???{?? ?..........

After it had been repaired it looks like this:

NTFS ????&r..........

I'm not sure what originally happened to my Windows, but I think I had a mishap when trying to rewrite the GRUB boot loader. I wrote it to the boot sector, instead of the MBR, overwriting XP's boot sector. (XP boot sector is chainloaded from GRUB). The reason I had to rewrite it was because my SUSE Linux overwrote the boot sector with its own GRUB which was missing my Ubuntu Linux entry. So I figured, using Ubuntu's GRUB which already had SUSE listed in its entries was the easiest thing to do.

When my Windows did not boot, GRUB just came right back up after briefly showing a black screen with boot code like 'chainloader (hd0,0)...boot...'. I think the MS boot loader had been wiped completely by my previous GRUB reinstallation attempts. Confident that it would be fixed, at that point I did fixmbr, and upon boot it said Ntldr missing. So then I tried fixboot, on all the paritions and fixmbr on all the partitions desperate to write a boot sector somewhere. Even after all that, GRUB was gone, but Ntldr was still missing.

 

[Smilin]

Yeah, looking back at several tens of thousands of MS cases involving fixboot I can't see a single one that involves a mysterious conversion to FAT12.

I see one case where the boot sector was flagged as FAT12 but every other parameter (sectors, hidden sectors etc) was bogus as well indicating overall corruption. The backup boot sector was intact. If fixboot had done something funny it would have done it to both
copies.

So, I call shenanigans on that article although the boot code decompile is nice.


Also, since you were bumping into an NTLDR missing I should further clarify my above statement:

2. "Ntldr Missing" - Means what it says, but also means your boot sector was read properly. It could also mean your partition table has the wrong partition flagged as active (80h) and you are looking for the right thing in the wrong place.


Overall that's a pretty cool article you found. It sums up a lot of info you usually have to go several places to find. Shenanigans on the FAT12 thing though.

 

[xtknight]

I used to have my Linux /boot mount set as active. The XP boot sector stayed on /dev/sda1 (hd(0,0) in grub) so it just chainloaded that. I assume that is how it worked. Now that my hd(0,0) has a GRUB boot loader on it I'm not sure how to but the XP one back and I really don't want to use fixboot again after what just happened. Well fixboot didn't damage a couple other partitions so would copying the boot sector from the first 440 bytes of those partitions work?

Device Boot Start End Blocks Id System
/dev/sda1 * 1 23441 188289801 7 HPFS/NTFS
/dev/sda2 29156 30515 10924200 f W95 Ext'd (LBA)
/dev/sda3 23442 29155 45897705 83 Linux
/dev/sda5 29156 29792 5116671 7 HPFS/NTFS
/dev/sda6 30301 30515 1726956 83 Linux
/dev/sda7 29793 30300 4080478+ 82 Linux swap / Solaris

I'm stuck between a rock and a hard place. I do need to get Windows working for school, and somehow without having my partition turn to FAT12.

Is there a sure-fire way to get the Windows boot-sector back on there? It doesn't matter what I do as long as I don't lose any data (documents). I don't care if I have to destroy the GRUB bootloader because it is much easier to replace (now I know to write it to the MBR, not over hd(0,0)!). If I set the Windows boot sector as active, then type fixmbr \Device\Harddisk0 (/dev/sda in Linux), will it correctly write a boot record there? Do I also need a boot sector? Would I write the boot sector on /dev/sda1 (or \Device\Harddisk0\Partition0)? Can I write the boot sector somewhere else (like Partition0 on Harddisk1) instead and have the MBR on Harddisk0 point to it? It just a matter of what is in the boot.ini, right? disk,rdisk, etc...

I noticed the fixboot/fixmbr commands were rather 'flaky'. I gave it a parameter of a hard disk and it says it wrote it to that physical device with no parition listed. And fixmbr will say it wrote something to whatever parameter you gave it as long as the first part (physical device) is correct. It will say it wrote it to a partition. It's just odd...

My goals at this point:

- First get working XP master boot record on (hd0) (not sure if this is needed).
- Get working XP boot sector somewhere that can boot Windows from (hd0,0).
- Rewrite Ubuntu GRUB boot loader to master boot record on (hd0) and use chainloader hd(x,x) (depending on boot sector location) for Windows.

Thanks for the help.

 

[xtknight]

Update: I got it. I used the XP install CD (I reinstalled) and it restored the master boot record and boot loader. It also detected my old Windows. But for some reason the RPC server on my old XP fails to start so the whole system is virtually malfunctioning. I don't know why that happened, but something must have gotten corrupted. After all that I installed the Ubuntu GRUB loader only to the master boot record at hd0 and everything worked OK. Both Windows and Linux can be started now.

 

[Smilin]

Ok, so assuming this mess is the result of corruption it's possibly all over the disk. Now that sector 0 and your boot sector are good, chkdsk /f the drive (chkdsk /p if doing in recovery console). Check the event logs for winlogon events with the chkdsk results. As long as it doesn't have the phrase "unrecoverable errors" it was able to fix the filesystem.

Once that is done we need to make sure your system files didn't take any damage. Try these in order:
1. Have your install media and a service pack CD handy (if you didn't install with slipstreamed media) and run "sfc /scannow".
2. Roll back to a previous system restore point.
3. Run a full repair/inplace upgrade. If you can boot to gui, just pop the CD in and "upgrade", or boot to the XP CD, enter to setup, r to repair detected install.

 

[Thad]

I'm having exactly the same problem, though I believe the diagnostics I've run have said FAT16. Memo to Smilin: a hell of a lot of people have this problem; I understand a healthy amount of skepticism in any tech support situation but it might behoove you in the future to spend ten seconds on Google before you declare a problem doesn't exist.

In my case, I was trying to upgrade my grandmother's computer from Win98 to XP. The machine hung on reboot. I went into Recovery Console and ran fixboot, after which my drive showed up as a 10MB FAT partition with only one file on it, bootex.log. A boot into Knoppix showed a full complement of files, but all displayed with gibberish names.

I'm hitting Google and setting up a new version of UBCD4Win; hopefully I can get it fixed.

Anyway, point is, it's a real -- and, judging by the Google results, common -- problem.

Thanks for the thread, gents; hopefully it'll do me some good.

(An aside: I have never had a Windows upgrade go smoothly. Every single iteration -- 95, 98, XP -- has hosed my system. Well, all right, the ME upgrade worked just fine, but came with the serious disadvantage of putting ME on my computer. ...Anyway. I should know better by now. I should have just backed up Grandma's E-Mail to a CD and done a clean install.)

 

[xtknight]

Thad: well that's good to hear (well not your problem, but at least I'm not alone). Hopefully you can fix yours by testdisk (free) as well. Might have to use MS-DOS on a Win98 startup disk because doing it under my Linux caused a segfault during 'search MFT'. It found my MFT within 10 minutes (thank the heavens) and rewriting the MBR fixed everything, save for the first 10MB of it that were overwritten by that FAT12 partition. This is even when it said my MFT ($Mft) and MFT backup ($Mftmirr) were damaged prior to 'search MFT'.

Here is the exact 512 byte boot sector of sda1 after fixboot reported 'corrupted MBR' and tried to fix it: http://xtknight.atothosting.com/images/bootbuild-sda1-fat12.png
Recovery console chkdsk reported Serial Number 0000-0000 and the drive listings continued to say FAT16.

I assure you the partition was a properly readable and mountable NTFS partition prior to the fixboot command. I think I did mention I did the fixboot command multiple times on all the partitions (it's a habit of mine) after doing fixmbr. The other NTFS partitions are perfectly fine though.

Mounted with vfat module: http://xtknight.atothosting.com/Screenshot.png
In the recovery console, all that was listed was a bootex.log.

In the contents one of the (very small) garbled files I recognized an API function name but the rest were probably just gibberish. They were just remnants of what was on the disk.

Here is the proper boot sector of sda1 after testdisk's 'Search MFT'/rewrite MBR function: http://xtknight.atothosting.com/images/bootbuild-sda1-ntfs.png

From what I can tell I lost very little but Windows XP32 no longer operates correctly so perhaps something got lost. I probably lost the first 10 MB of that partition.

Linux fdisk still identified the partition as NTFS when the boot sector said fat12, I'm guessing since it reads from the partition table instead of the boot sector?

I'm just going to reinstall my Windows 32 since that RPC error is near impossible to fix. Not too worried about it at the moment because I can use MS Word for school on WinXP x64. I will try chkdsk /p next time I get a chance but the regular chkdsk didn't find any problems if I remember correctly. It said in the event log that it fixed something on the NTFS partitions which (so I've read) XP attempts automatically at every boot-up.

I'll add "possible solution" to the title so hopefully it can help anyone who Googles it.

We could always disassemble 'fixboot' and search for 'FAT12' and see what comes up. I really don't think it's a bug (well, not completely). FAT12 was likely arbitrarily typed (it's not just a single ID code like a partition FS type), it's the first 5 bytes of the boot sector. I'm going to go off on a limb here, but I suppose it could also be a string array addressed by the wrong variable ("FAT16" may be just one string-size away from "NTFS").

Somewhere along the way (I believe after fixing mbr then attempting to start Windows with that FAT16 partition), XP32 had some weird error on boot-up. I don't have a perfect recollection of it, but there was no error alias (not "IRQL_LESS_THAN_OR_EQUAL", etc), it was just 0x00000084, or something like that. That's if I remember correctly...but I don't think it was "unmountable boot volume".

 

[wirelessenabled]

TestDisk worked for me when I lost the partition table on my data drive. Click, click and the disk comes back with all the data.

Thanks for the link.

 

[Smilin]

Originally posted by: Thad
I'm having exactly the same problem, though I believe the diagnostics I've run have said FAT16. Memo to Smilin: a hell of a lot of people have this problem; I understand a healthy amount of skepticism in any tech support situation but it might behoove you in the future to spend ten seconds on Google before you declare a problem doesn't exist.

Yeah, I did some googling on it but more importantly I checked every case that anyone has opened with Microsoft on the issue. In every case when root cause was found fixboot had nothing to do with it. There was only one instance of a "converted" fat12 partition and that had so much corruption associated with it anything could have happened.

I'm glad you guys are getting it sorted out but I think fixboot is a red herring.