I'm Rod Smith, the author of gdisk. Chris Murphy e-mailed me about this thread, so I'm replying.
The easy (but expensive) solution is to do as Chris suggests: Send the drive off to a specialist data-recovery firm. Unfortunately, I don't have any recommendations, since I've never dealt with such firms myself.
If you can't afford that or if you want to try to do more yourself, I have an idea of what you could do:
If you're very lucky, Windows will become bootable again, or at the very least, you'll be able to use Windows recovery tools on a bootable CD or USB drive to view the contents of the partition, back up your critical data, and repair the installation.
I do have another idea for more radical data recovery methods, but the procedure is very risky and involves enough decision points that trying to describe it in a Web forum is not practical. Basically, it involves using TestDisk on a Linux emergency disc to recover your lost partition, even if it's been moved or resized.
I'll also say this: I don't know what caused the problem, but I suspect one of two things:
Good luck with your recovery!
The easy (but expensive) solution is to do as Chris suggests: Send the drive off to a specialist data-recovery firm. Unfortunately, I don't have any recommendations, since I've never dealt with such firms myself.
If you can't afford that or if you want to try to do more yourself, I have an idea of what you could do:
- Do a low-level backup of the disk. You'll need a spare disk that's at least as large as the one you've got. In OS X, the command "sudo dd if=/dev/disk0 of=/dev/disk1" will do the trick -- but be sure to specify the correct disk devices! Your disk is currently /dev/disk0, but its number could change when you attach another disk, depending on how you do it. If you get the if= (input) and of= (output) options wrong, your backup attempt will destroy all your data, beyond any hope of recovery. Thus, this step is very dangerous -- but it's also an important means of recovery should things go badly wrong in subsequent steps.
- Make a hardcopy printout of the gdisk output you've posted to this thread. This will help you recover should you accidentally trash your partitions.
- Launch gdisk on your disk.
- Delete the two clearly bogus partitions 61 and 62 by using the "d" command.
- Type "r" to enter the recovery & transformation menu.
- Type "h" to create a new hybrid MBR. Tell it to enter only partition #4, to place the 0xEE partition first, to give it a type code of 07 (which should be the default), to set the bootable flag, and to not create an additional protective partition.
- Type "w" to save your changes.
If you're very lucky, Windows will become bootable again, or at the very least, you'll be able to use Windows recovery tools on a bootable CD or USB drive to view the contents of the partition, back up your critical data, and repair the installation.
I do have another idea for more radical data recovery methods, but the procedure is very risky and involves enough decision points that trying to describe it in a Web forum is not practical. Basically, it involves using TestDisk on a Linux emergency disc to recover your lost partition, even if it's been moved or resized.
I'll also say this: I don't know what caused the problem, but I suspect one of two things:
- There may have been multiple problems over time that led up to the catastrophic failure. I say this because you've got damage to both the start of the disk and to the end of the disk. Very few simple errors would cause such a pattern, and most of those that would are bugs in GPT partitioning tools, which you didn't mention using. Many tools and OSes ignore problems to the backup GPT data, so that problem could have sat there for a long time without your noticing it.
- One of the few things that might write to the start and end of the disk that is not a GPT tool is various types of low-level software for BIOS computers, such as boot loaders, disk encryption software, and viruses. These programs may try to install themselves in the MBR and the area immediately after it (where the primary GPT data resides), and perhaps in unpartitioned space at the end of the disk (where the GPT backup data resides). (Note that these areas are "unpartitioned" in the MBR scheme, but they are allocated in GPT. Windows only uses the MBR side of a hybrid MBR disk, though, so such programs would ignore the GPT allocations.) Thus, if you were installing such a program -- even unknowingly, as would be the case for a virus -- that might explain the problem. It could also explain the crash, if the installer did something wrong. If this explanation is correct, it's important that you identify the offending software as soon as you recover your system. Removing it, if it's permanently installed itself, could be tricky, since such a removal might just damage your partition table again. If it was in the process of installing itself and it didn't complete the job, then deleting the installer and whatever files it installed should be adequate protection.
Good luck with your recovery!