Irritating. It's not seeing the free space after Recovery HD. What version of Mac OS X?
In past cases like this, by relocating the Recovery HD partition elsewhere, so that the free space butts up against the Mac OS X volume, I've been able to get 'diskutil resize' to reclaim that free space. This is not difficult to do by command line, but does take some patience to go through the whole thing. It's also possible to move/resize the Windows partition instead, to reclaim those 73MB. Or some combination thereof. Or just ignore it. Again, it's not hurting anything. iPartition is a 3rd party GUI app that might be able to do this for you, but with some hand holding it is possible to do this with free tools.
In any case, I think your priority is to get Windows booting so I'll deal with that now and you can report back if it works or not. This command will get you into interactive edit mode for fdisk:
sudo fdisk -e /dev/disk0
First column are commands to enter for fdisk, and second column describes commands. <enter> means press the return or enter key.
p <enter> displays the MBR contents
flag 4 <enter> sets the boot flag on 4th partition
p <enter> note the * next to the 4th partition
quit <enter> writes change, quits fdisk
Reboot. Hold down the option key at the start up chime and see if a Windows disk icon now appears and if you can boot Windows. Report back.
Ok before your last response, I installed rEFIt to try and resync the MBR for the Windows partition. This brought back the menu item for booting to Windows, but doesn't boot up, just gets "A disk read error occurred" which I would normally associate with a missing or corrupt MBR.
I'm running Mountain Lion, and the problem occurred after doing an in-place normal upgrade from Lion. I suspect it re-inserted the recovery partition which bumped the Bootcamp partition to number 4 from 3.
I don't really care about the missing free space, as you suspected, just getting the Windows partition going again would be excellent.
Here are the outputs from the previous disk commands in case the rEFIt install (and subsequent uninstall) changed anything.
sudo gpt -r -vv show disk0
gpt show: disk0: mediasize=500107862016; sectorsize=512; blocks=976773168
gpt show: disk0: Suspicious MBR at sector 0
gpt show: disk0: Pri GPT at sector 1
gpt show: disk0: Sec GPT at sector 976773167
start size index contents
0 1 MBR
1 1 Pri GPT header
2 32 Pri GPT table
40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B
409640 742851896 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC
743261536 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC
898164736 78608384 4 GPT part - EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
976773135 32 Sec GPT table
976773167 1 Sec GPT header
sudo fdisk /dev/disk0
isk: /dev/disk0 geometry: 60801/255/63 [976773168 sectors]
#: id cyl hd sec - cyl hd sec [ start - size]
1: EE 1023 254 63 - 1023 254 63 [ 1 - 409639] <Unknown ID>
2: AF 1023 254 63 - 1023 254 63 [ 409640 - 742851896] HFS+
3: AB 1023 254 63 - 1023 254 63 [ 743261536 - 1269536] Darwin Boot
*4: 07 1023 254 63 - 1023 254 63 [ 898164736 - 78608384] HPFS/QNX/AUX
sudo fdisk -e /dev/disk0
fdisk: could not open MBR file /usr/standalone/i386/boot0: No such file or directory
Enter 'help' for information
I just realised that I could still run the fdisk commands after that error. Partition 4 is marked as bootable, but I ran the flag 4 command anyway and double-checked. Windows is an option when holding down Alt, and I'm going through Win7 startup repair to see if it can fix the MBR on the Bootcamp partition.
Good idea. The GPT and MBR table look correct now.
The way BIOS operating systems boot, they blindly read the first 440 bytes of sector 0 and execute that code. Since it's such a tiny bit of code, all it does is point to another set of sectors on disk, read them in and execute. It's call chain loading, and is part of bootloading. So chances are one of these pieces of the chain is corrupt, and needs to be repaired.
The Windows partition is pretty much hosed. Repairing didn't work, and when I tried Paragon NTFS to try and access the drive, most of the files were missing. Not sure if the files were actually missing, or whether they just don't show up in finder with the Paragon software if restricted NTFS permissions are set on the directories.
Thanks a lot for all your help though Chris. I'm now armed with a much better understanding of how OS X treats partitions. Hopefully won't end up in this mess again *fingers crossed*.
Which repair failed? Fixing the bootloader or did chkdsk fail on repairing the NTFS volume? It's very disconcerting that this could be mucked up beyond repair due to a simple OS upgrade, which should not touch the MBR or Windows volume at all, let alone doing any kind of partition changes without informing the user.
My Windows 7 is back. I had it named .Windows (so as to not have the partition always appear on the desktop under SL). So, I accessed it via Parallels and removed the period. It now appears via Bootcamp.
However, unlike SL, that partition does not appear on the ML sidebar directory, which will be something of a pain, as I cannot open it via the Mac desktop unlike in SL. Disk Utility lists it as Partition 4; Paragon NTFS doesn't see it, either.
Replying to my own post: the problem of it not mounting on the desktop was some old Paragon NTFS garbage. Once I got rid of that using the instructions on the link below, it's working again.
I still have the preference panel for some reason.
I've deleted it, but had to go one by one to delete all the Paragon files, as the uninstaller Paragon provides doesn't work. The support instructions on line are atrocious, and also don't work. Files to delete: http://superuser.com/questions/101015/how-to-uninstall-paragon-ntfs-trial
Currently using Tuxera NTFS, which seems to be working fine.
FYI, the Paragon culprit that screwed things up is the Paragon file ufsd.fs
Paragon should stick to making crappy Windows software.
Running the bootsect /fixmbr, then bootsect /fixboot got the partition to the point where it would just show a blinking cursor up the top left when trying to boot to the windows partition. Moving on, I tried performing a Startup Repair from the Windows DVD which initially took about 3 hours and said to reboot. Still got the blinking cursor up the top left. Second try at running Startup Repair, it said it couldn't repair the installation.
I now really regret upgrading without doing a bit more reading first. Seems that installing lion to an external drive would have been a much better option in hindsight. I honestly didn't expect an in-place upgrade to ML to totally hose the partition, though after doing a lot more reading on the matter, I would have learned that it's a lot more finnicky than I thought.
Luckily there were only a few files on the partition that weren't backed up.
had the same problem.
I ended up creating an image copy of the partition using testdisk, reinstalling windows 7 and software and then retrieving all the data files from the image using GetDataBack for NTFS.
I tried fixing boot sector, but I think that somehow the start of the Bootcamp partition was overwritten by Mountain Lion recovery partition and couldn't be restored. I didn't loose any data thanks to GetDataBack which did a good job of loading the image and displaying all the files in the folders. I tried a few other recovery software packages that didn't display the files as neatly.
As an aside, I had a network backup, but it was quicker to copy the files from the image that was on an attached usb drive than copy the files over the network.
All in all took a long time and I would recommend being very careful with upgrading to Mountain Lion if you have bootcamp.
I'm awfully suspicious. There's no good reason why any Mac OS X upgrade would make any kind of modification to the MBR or GPT, let alone to the contents of a Microsoft basic data partition. If this were reproducible, it would be a significant bug find. I wish it were easier to VM Mac OS X for testing purposes.
I wonder if some incompatibility with Mountain Lion and Paragon NTFS could possibly have cause some sort of corruption within the NTFS volume, shortly after your upgrade. Speculation. But I'd sooner believe this than Apple's installer munging either the MBR or the Windows volume.
I'd check this out. Option 2 looks promising and is more involved than what you've tried so far. I think your partition 4 disk will still be C: but I'm not sure. There may be a command to list volumes.