After a power outage my laptop fails to boot. I investigated the matter with a bunch of disk utilities and live CDs. The data is intact, and I made a backup copy of it. Nevertheless I'd like to restore the disk functioning, including booting of course, with as minimal efforts as possible. I know many experts suggest to recreate partitions anew, restore operating system anew, and reinstall software anew. This is hardly doable in my case (I don't even have all distribution kits). This is why I'd like to edit corrupted partition table in-place, and I need an advice which part exactly is problematic.

The disk contains 2 volumes: one is primary partition and the other is a logical drive in extended partition.

When I boot the laptop from a live CD, Windows sees both drives, but the logical drive in the extended partition is inaccessible.

diskpart's command list volume shows that the volume fs flag is RAW instead of NTFS. The odd thing is that disk utilities which I used to restore data (including DMDE) see this volume as NTFS and read data from it without problems.

Here is the output of diskpart:

enter image description here

And here's what DMDE shows:

enter image description here

The question is which raw bytes and how should I edit in the table (I can use DMDE for direct disk edition, for example) to make the volume proper NTFS accessible from Windows?

I'm not sure which other details may be important and ready to provide them upon request.


The only one real answer among the linked ones suggests using TestDisk. First, I must say that this utility is very picky about OS - it does not run on any WinPE based live CD I tried. Finally I managed to run it on [almost] fully fledged Win7 live CD. Here is what it shows (please note NTFS in the logical volume in the extended partition):

enter image description here

and (please note FAT32 this time):

enter image description here

I need to recover the largest volume from here. It's displayed as FAT32 under TestDisk (DMDE shown NTFS). P command does not produce a readable list of files for this volume. I tried the T command to change type to NTFS, but this did not solve the problem: P still lists a garbage ("file system may be damaged"). Yet I see the full filesystem under DMDE and saved it using r.saver utility.

I ran a deeper search:

enter image description here

and found:

enter image description here

The Deleted NTFS volume is the actual drive with my data. Then I changed its from 'D' to 'L' and did Write changes to the disk and reboot.

enter image description here

The drive is still inaccessible, but now if I run DMDE it complains that MBR records require a disk of at least 625153410 LBA (320GB), but the disk is 625142448 LBA (320GB).

From my experience either TestDisk is incapable of doing the job in my case, or I need more detailed instructions what exactly to fix using TestDisk.

Thanks in advance.

As a small remark I must say that TestDisk is buggy: i made a backup of the partition table by corresponding TestDisk's command, then changed the table and wrote it to the disk; then discovered that the changes did not help and decided to rollback the changes from the backup - as a result I got completely different and incorrect partition table. The only thing that saved me from a fiasco was that I made another backup using dmde, which restored the structure as expected.

  • I don't find linked answers useful or complete, so would be glad to see more specific and detailed answer. – Stan Sep 28 '15 at 17:06
  • I'd like to start a bounty but this option is missing after someone marked my question as a duplicate. Is there a way to remedy this? – Stan Sep 29 '15 at 11:16
  • Wait another day, can't start a bounty until two days after asking – random Sep 29 '15 at 19:02

The problem is solved (with support of some technical gurus sharing their knowledge in social media), and I'm posting most important details as the answer.

From the very beginning it was my misunderstanding that RAW flag is equal to physically written 0 in corresponding partition. The fact is that 0 means empty partition record, that is no partition at all, whereas RAW is a special logical flag denoting some problems in partition. Thus, diskparts "message" in this case was that while the "inaccessible" partition is logically "healthy", its underlying hard drive may contain some defects.

In the era of SMART hard disks the defects are logged internally in each disk and can be fixed (if they're not fatal).

So, first I used HDDScan to read SMART information. Here is what I got:

enter image description here

Please note that pending error count is 3. These errors should be fixed.

For that purpose, one should find out which sectors exactly produce these errors, specifically scan disk surface for reading errors. In my case, Victoria utility was used (the utility's UI is in English, but the site is unfortunately in Russian).

enter image description here

As a result, I got the 3 block addresses with damaged sectors.

Next, one of the methods to repair the blocks should be applied (specific method may vary depending from hard disk manufacturer). In my case it was sufficient to try to write some data into the damaged blocks. SMART disk is smart enough to remap damaged blocks to some other reserved space if write operation fails. The easiest way to perform the write command - copy a region of blocks to itself. You may use your preferred tool for it, I used dmde (Tools -> Copy sectors). As far as the bad blocks was localized near each other in my case, I ran the copy command only once: the starting block of Source and Destination was set the same (somewhat before the first bad sector) and number of sectors to copy was set large enough to cover the region with all 3 bad blocks. Since this is a copy to itself, it does not change valid blocks. The bad blocks are filled with zeros. Their original data is lost anyway. If the bad blocks do not contain critical data, the restored disk may probably run all programs well.

After the copy command execution I checked the SMART information once again and made sure that error count is 0. If it would be not, something went wrong and should be investigated in depth.

The last thing to do is to run chkdsk d: /F (where d is your drive letter) to fix logical errors in the physically restored partition.

After all this done, I managed to get the problematic NTFS partition back (the RAW flag is gone, and it's listed as NTFS again), in-place, and almost without data loss - at least Windows is booting as before.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.