Restore somewhat broken volume on the disk in-place?

Question

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:

And here's what DMDE shows:

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.

Update

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):

and (please note FAT32 this time):

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:

and found:

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.

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.}

Answer 1

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:

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).

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.