Jump to content

Invalid Partition Table on my 500GB HDD


Recommended Posts

Hi there everyone,

I've been going crazy over the past few days trying to recover my laptop's HDD. I read the whole thread regarding a similar problem on the same HDD model:

Problem is that I have a few partitions on that HDD, but I can only access one of them. This is basically my HDD's layout:

* RECOVERY partition (came with the laptop) > Accesible

* Windows 7 x64 partition (F:) > Shown as RAW, 137GB (partition is actually larger than those 137GB)

* Ubuntu partition (+ SWAP partition) > Not showing, don't care if it gets lost

Following the steps given by jaclaz I get to find the StartSector of each partition with PTview, but I don't know how to go on from there. I have already installed Tiny Hexer (+ scripts), HDHacker and DataRescueDD.

Testdisk won't let me access the W7 partition as no LBA48 support seems to be available for this HDD.

What should I do now? What info should I post here in order to solve this issue?

Any help will be MUCH appreciated, I will definitely try to help out from now on and become part of this community.

Thanks a lot :)

Edit: Added the PTview info on the HDD, and DataRescue DD + Tiny Hexer "Open drive..." screenshots

post-361895-0-10985000-1347577701_thumb.

post-361895-0-48469700-1347578182_thumb.

post-361895-0-55825500-1347578820_thumb.

Edited by klinsmann
Link to comment
Share on other sites


You are in a "peculiar" situation.

The number of sectors actually seen for \\.\PhysicalDrive1 is 268,435,455 that nicely corresponds to 137,438,952,960 bytes.

I.e., for *any* reason the disk drive "declares itself" as being that size in TOTAL.

What I would do is to image it "as is" with DatarescueDD.

Then I would try to recover the data that actually was in this "initial" 137 Gb.

The reason WHY could be almost *anything*, but I seem to remember to have read of disks behaving similar to this, I will have a look if I can find any related info.

To proceed, you need a disk with at least 500+140 Gb.

A 640 Gb disk is probably enough :unsure:, but it's a bit "tight", best idea could be another 500 Gb hard disk + some 140/150 Gb free on another disk.

The general idea is:

  1. image the disk to a roughly 137 Gb image with DatarescueDD
  2. restore the image to a "new" 500 Gb disk
  3. fix the filesystem of the biggish NTFS partition and have back access to (hopefully) all the data physically residing on the first 137 GB

Once done that we will see if there is some form of "user doable" fix.

Please post some more info

  1. Which exact hard disk model is it?
  2. Which exact laptop is it?
  3. How/when did it happen?
  4. How are you accessing the disk currently? <- please not that IF you are using a USB to SATA or USB to IDE adapter or "external case", some (older ones) will "cut-off" at the 28 bit LBA address (strangely similar to 137 Gb :ph34r: )

jaclaz

Link to comment
Share on other sites

Let's try and answer all the questions:

You are in a "peculiar" situation.

The number of sectors actually seen for \\.\PhysicalDrive1 is 268,435,455 that nicely corresponds to 137,438,952,960 bytes.

I.e., for *any* reason the disk drive "declares itself" as being that size in TOTAL.

What I would do is to image it "as is" with DatarescueDD.

Then I would try to recover the data that actually was in this "initial" 137 Gb.

The reason WHY could be almost *anything*, but I seem to remember to have read of disks behaving similar to this, I will have a look if I can find any related info.

Image saved and I already managed to save all the necessary info on those 137 GB. I'm guessing the missing data will be located on the "ghost" sectors on that partition.

To proceed, you need a disk with at least 500+140 Gb.

A 640 Gb disk is probably enough :unsure:, but it's a bit "tight", best idea could be another 500 Gb hard disk + some 140/150 Gb free on another disk.

The general idea is:

  1. image the disk to a roughly 137 Gb image with DatarescueDD
  2. restore the image to a "new" 500 Gb disk
  3. fix the filesystem of the biggish NTFS partition and have back access to (hopefully) all the data physically residing on the first 137 GB

Once done that we will see if there is some form of "user doable" fix.

No problem about that, I have a 1TB drive I can use for this purpose (is it OK if I just use this one?).

Please post some more info

  1. Which exact hard disk model is it?
  2. Which exact laptop is it?
  3. How/when did it happen?
  4. How are you accessing the disk currently? <- please not that IF you are using a USB to SATA or USB to IDE adapter or "external case", some (older ones) will "cut-off" at the 28 bit LBA address (strangely similar to 137 Gb :ph34r: )

jaclaz

1. HDD is a Seagate ST950032 5AS (2.5" SATA drive)

2. Laptop is an ASUS-X52J (Core i5)

3. This happened last friday, I started looking for solutions on monday and so far I've managed to save 137 GB of data (which counts for about 60-70% of the vital data stored on that drive).

4. I am currently accesing the drive through a USB to SATA adapter connected to a desktop PC with Windows 7. Tried connecting the drive directly into the PC motherboard through SATA but the LBA48 issue with TestDisk was still there.

Thanks jaclaz, let me know what else you might need :rolleyes:

Link to comment
Share on other sites

No problem about that, I have a 1TB drive I can use for this purpose (is it OK if I just use this one?).

Sure, that should do nicely. (of course all data - if any - currently on the 1 Tb disk will be lost)

If you need help to dd the 137 Gb image to the disk, ask, but if you use dsfi (part of the dsfok toolkit):

http://members.ozemail.com.au/~nulifetv/freezip/freeware/

it should be easy unless the Windows 7 - for any reason - creates issues.

Be VERY careful about WHICH PhysicalDrive n to use AND be aware that the dsfi (being a complement to dsfo) uses a "reversed" logic in command line:

dsfi DESTINATION Offset Size SOURCE

i.e.

dsfi \\.\PhysicalDriven 0 0 <Path>\my137Gb.img

2. Laptop is an ASUS-X52J (Core i5)

Good, it should be a "normal" BIOS (seeing the disk as having 255x63 HS geometry) the issue would have been if the BIOS )like many HP's and Lenovo) see the disk internally connected as 240x63 (the USB connected are always seen as 255x63).

jaclaz

Link to comment
Share on other sites

No problem about that, I have a 1TB drive I can use for this purpose (is it OK if I just use this one?).

Sure, that should do nicely. (of course all data - if any - currently on the 1 Tb disk will be lost)

If you need help to dd the 137 Gb image to the disk, ask, but if you use dsfi (part of the dsfok toolkit):

http://members.ozemail.com.au/~nulifetv/freezip/freeware/

it should be easy unless the Windows 7 - for any reason - creates issues.

Be VERY careful about WHICH PhysicalDrive n to use AND be aware that the dsfi (being a complement to dsfo) uses a "reversed" logic in command line:

dsfi DESTINATION Offset Size SOURCE

i.e.

dsfi \\.\PhysicalDriven 0 0 <Path>\my137Gb.img

2. Laptop is an ASUS-X52J (Core i5)

Good, it should be a "normal" BIOS (seeing the disk as having 255x63 HS geometry) the issue would have been if the BIOS )like many HP's and Lenovo) see the disk internally connected as 240x63 (the USB connected are always seen as 255x63).

jaclaz

So basically, once this is done I should have full access to the "first" 137 GB and we'll work on how to access the rest of the data, am I right?

Link to comment
Share on other sites

So basically, once this is done I should have full access to the "first" 137 GB and we'll work on how to access the rest of the data, am I right?

Basically, yes.

The issue may be that it is possible (a number of factors are involved) that the NTFS filesystem driver will "choke" on partial data (or when you try accessing files that are not there) and force or require a NTFSCHK.

It is possible that you will need anyway to run TESTDISK on the "newly made" disk to fix the second copy of the bootsector, but I seem to remember that it won't be needed.

Once you (hopefully) got back the "main" files (the ones within the first 137 Gb imaged), and ONLY then, we will try to see what can be done on the original HD.

A guess (educated ;), but still a guess) could be that *somehow* the original disk "self-capped" to 137 Gb.

It is something that can happen "generically", I haven't been able to find substantial reports about this issue affecting particularly this specific disk model.

You can try using this:

http://blog.atola.com/restoring-factory-hard-drive-capacity/

I think that the disk must be connected "directly" (NOT through the USB converter) for this kind of tools to work.

The above is a "simplified" user friendly specific tool, a "pro" would most probably use HDAT2:

http://www.hdat2.com/

or a similar "lower level" tool, but the good thing is that the Atola tool will either work or fail completely, but shouldn't make things worse if it fails.

jaclaz

Link to comment
Share on other sites

So basically, once this is done I should have full access to the "first" 137 GB and we'll work on how to access the rest of the data, am I right?

Basically, yes.

The issue may be that it is possible (a number of factors are involved) that the NTFS filesystem driver will "choke" on partial data (or when you try accessing files that are not there) and force or require a NTFSCHK.

It is possible that you will need anyway to run TESTDISK on the "newly made" disk to fix the second copy of the bootsector, but I seem to remember that it won't be needed.

Once you (hopefully) got back the "main" files (the ones within the first 137 Gb imaged), and ONLY then, we will try to see what can be done on the original HD.

A guess (educated ;), but still a guess) could be that *somehow* the original disk "self-capped" to 137 Gb.

It is something that can happen "generically", I haven't been able to find substantial reports about this issue affecting particularly this specific disk model.

You can try using this:

http://blog.atola.com/restoring-factory-hard-drive-capacity/

I think that the disk must be connected "directly" (NOT through the USB converter) for this kind of tools to work.

The above is a "simplified" user friendly specific tool, a "pro" would most probably use HDAT2:

http://www.hdat2.com/

or a similar "lower level" tool, but the good thing is that the Atola tool will either work or fail completely, but shouldn't make things worse if it fails.

jaclaz

I will let you know how this works out, I've been quite busy over the weekend ;)

Link to comment
Share on other sites

So, I finally found the time to fully get into this and get it solved ASAP.

I imaged the disk with DataRescue DD, however the images is a .dd file. How can I turn it into a .img? I have saved almost everything in those 137 GB, but as you predicted, some partial data is damaged (a few random files are shown as corrupted).

This is how I've set up the PC for the process: a 1 TB SATA Hard Drive connected through USB, and the "corrupted" Hard Drive we are trying to save directly plugged into the MB. Is that alright?

What should I do now?

Edit: Forgot to ask, what's the safest way to know which PhysicalDrive is the 1 TB drive I'll be using with dsfi?

Edited by klinsmann
Link to comment
Share on other sites

I imaged the disk with DataRescue DD, however the images is a .dd file. How can I turn it into a .img? I have saved almost everything in those 137 GB, but as you predicted, some partial data is damaged (a few random files are shown as corrupted).

Well, what most people tend to confuse is file format with file extension. :)

What you made with datarescue.dd is a RAW (file format) image, i.e. an exact, byte-by-byte, sector-by-sector, image of the source hard disk.

You can give it *any* name, and as well *any* extension, like .dd or .img, it will still remain a RAW image.

If you prefer the extension given to a filename has two scopes:

  1. be a "mnemonic" to quickly know what file format it is (of course only useful if you give appropriate extensions)
  2. be useful for associating those files to a given program

for all it matters you could name the image mynicespreadsheet.xls (only Excel will choke :ph34r: if you attempt double clicking on the file ;)).

This is how I've set up the PC for the process: a 1 TB SATA Hard Drive connected through USB, and the "corrupted" Hard Drive we are trying to save directly plugged into the MB. Is that alright?

Which process?

If you dd the 137 Gb image to the 1 Tb disk you need NOT the original disk connected.

On the other hand if you already recovered most of the files from the "capped" hard disk or from the dd image, you may want to "skip" this part (you already have the image, so if needed you can do this later) and check just the "failed" disk with the Atola tool. :unsure:

Unless *somehow* we change something in the failed disk, the accessible data will still remain the 137 Gb you already imaged.

"Restoring" the dd image to the "new" disk is simply an approach that allows the use of CHKDSK and TESTDISK on a "full sized" space, which may (or may not) help to fix the filesystem/access the files IF you did not managed to already save them (anything beyond the image size will remain anyway "a suffusion of yellow").

Edit: Forgot to ask, what's the safest way to know which PhysicalDrive is the 1 TB drive I'll be using with dsfi?

Easiest?

Create a small partition on the disk and format it.

Open tiny hexer, FIle->Disk->Open Drive, you wil normally see something like (example):

\\.\PHYSICALDRIVE0

\\.\C: (PHYSICALDRIVE0, Partition 1)

\\.\PHYSICALDRIVE1

\\.\D: (PHYSICALDRIVE1, Partition 1)

The right PHYSICALDRIVE is the "parent" of the drive letter assigned to the newly created partition.

jaclaz

Link to comment
Share on other sites

I imaged the disk with DataRescue DD, however the images is a .dd file. How can I turn it into a .img? I have saved almost everything in those 137 GB, but as you predicted, some partial data is damaged (a few random files are shown as corrupted).

Well, what most people tend to confuse is file format with file extension. :)

What you made with datarescue.dd is a RAW (file format) image, i.e. an exact, byte-by-byte, sector-by-sector, image of the source hard disk.

You can give it *any* name, and as well *any* extension, like .dd or .img, it will still remain a RAW image.

If you prefer the extension given to a filename has two scopes:

  1. be a "mnemonic" to quickly know what file format it is (of course only useful if you give appropriate extensions)
  2. be useful for associating those files to a given program

for all it matters you could name the image mynicespreadsheet.xls (only Excel will choke :ph34r: if you attempt double clicking on the file ;)).

So that's done :)

This is how I've set up the PC for the process: a 1 TB SATA Hard Drive connected through USB, and the "corrupted" Hard Drive we are trying to save directly plugged into the MB. Is that alright?

Which process?

If you dd the 137 Gb image to the 1 Tb disk you need NOT the original disk connected.

On the other hand if you already recovered most of the files from the "capped" hard disk or from the dd image, you may want to "skip" this part (you already have the image, so if needed you can do this later) and check just the "failed" disk with the Atola tool. :unsure:

Unless *somehow* we change something in the failed disk, the accessible data will still remain the 137 Gb you already imaged.

"Restoring" the dd image to the "new" disk is simply an approach that allows the use of CHKDSK and TESTDISK on a "full sized" space, which may (or may not) help to fix the filesystem/access the files IF you did not managed to already save them (anything beyond the image size will remain anyway "a suffusion of yellow").

By "the process" I meant this whole thing. OK, so original Hard Drive is right now disconnected.

Edit: Forgot to ask, what's the safest way to know which PhysicalDrive is the 1 TB drive I'll be using with dsfi?

Easiest?

Create a small partition on the disk and format it.

Open tiny hexer, FIle->Disk->Open Drive, you wil normally see something like (example):

\\.\PHYSICALDRIVE0

\\.\C: (PHYSICALDRIVE0, Partition 1)

\\.\PHYSICALDRIVE1

\\.\D: (PHYSICALDRIVE1, Partition 1)

The right PHYSICALDRIVE is the "parent" of the drive letter assigned to the newly created partition.

jaclaz

I seem to be having an issue I did not have last time I used Tiny Hexer (check atteached image).

Thanks (as usual) jaclaz!

Edit: dsfi is denying acess when I try dsfi \\.\e: 0 0 SOURCE (SOURCE being of course the actual source file I renamed to .img)

post-361895-0-87897000-1348229903_thumb.

Edited by klinsmann
Link to comment
Share on other sites

Edit: dsfi is denying acess when I try dsfi \\.\e: 0 0 SOURCE (SOURCE being of course the actual source file I renamed to .img)

That's an actual stupid thing of Windows Vista :ph34r: and later that - probably for the first time :unsure: - turned around as a good thing :thumbup .

You imaged a DISK (or \\.\PhysicalDrive) you have to restore the image to a DISK (or \\.\PhysicalDrive) NOT to a DRIVE (or \\.\LogicalDrive).

In my example:

\\.\PHYSICALDRIVE0

\\.\C: (PHYSICALDRIVE0, Partition 1)

\\.\PHYSICALDRIVE1

\\.\D: (PHYSICALDRIVE1, Partition 1)

you use the line with the RED drive letter to identify the GREEN parent and you supply it (the parent or the GREEN BOLDED one) to dsfi....

  • DISK=PhysicalDrive=bigger container=starts at absolute sector 0 LBA=what you see in Disk ;) management in the lower pane, on the left
  • DRIVE=LogicalDrive=Primary Partition (or Logical Drive inside Extended Partition) contained inside DISK=starts at whatever sector is addressed for it in the MBR or in the EPBR=what you see in the top pane in Disk Management (and has normally a Drive ;) letter assigned or in the lower pane on the right as part of the DISK

The good MS guys made their best to confuse the matter, rest assured that you are not the first one (and unfortunately not even the last one :no: ) to fall for this misunderstanding.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Edit: dsfi is denying acess when I try dsfi \\.\e: 0 0 SOURCE (SOURCE being of course the actual source file I renamed to .img)

That's an actual stupid thing of Windows Vista :ph34r: and later that - probably for the first time :unsure: - turned around as a good thing :thumbup .

You imaged a DISK (or \\.\PhysicalDrive) you have to restore the image to a DISK (or \\.\PhysicalDrive) NOT to a DRIVE (or \\.\LogicalDrive).

In my example:

\\.\PHYSICALDRIVE0

\\.\C: (PHYSICALDRIVE0, Partition 1)

\\.\PHYSICALDRIVE1

\\.\D: (PHYSICALDRIVE1, Partition 1)

you use the line with the RED drive letter to identify the GREEN parent and you supply it (the parent or the GREEN BOLDED one) to dsfi....

  • DISK=PhysicalDrive=bigger container=starts at absolute sector 0 LBA=what you see in Disk ;) management in the lower pane, on the left
  • DRIVE=LogicalDrive=Primary Partition (or Logical Drive inside Extended Partition) contained inside DISK=starts at whatever sector is addressed for it in the MBR or in the EPBR=what you see in the top pane in Disk Management (and has normally a Drive ;) letter assigned or in the lower pane on the right as part of the DISK

The good MS guys made their best to confuse the matter, rest assured that you are not the first one (and unfortunately not even the last one :no: ) to fall for this misunderstanding.

jaclaz

Problem is Tiny Hexer is (don't know why) not showing info the way it did before (check attached image on my previous post). Any idea on how to fix that?

All I want is to find out the PHYSICALDRIVE I need to use as DESTINATION for dsfi.

Edit: Problem solved!

Edited by klinsmann
Link to comment
Share on other sites

Problem is Tiny Hexer is (don't know why) not showing info the way it did before (check attached image on my previous post). Any idea on how to fix that? :blink:

Cannot say. :unsure:

Another "queer" behaviour of Winddows 7?

All I want is to find out the PHYSICALDRIVE I need to use as DESTINATION for dsfi.

Post a screenshot of Disk Management...

jaclaz

Link to comment
Share on other sites

Problem is Tiny Hexer is (don't know why) not showing info the way it did before (check attached image on my previous post). Any idea on how to fix that? :blink:

Cannot say. :unsure:

Another "queer" behaviour of Winddows 7?

All I want is to find out the PHYSICALDRIVE I need to use as DESTINATION for dsfi.

Post a screenshot of Disk Management...

jaclaz

Managed to solve this just as you replied. dsfi working as we speak, "new" disk should be ready in 20-30 minutes :w00t:

Edited by klinsmann
Link to comment
Share on other sites

Problem is Tiny Hexer is (don't know why) not showing info the way it did before (check attached image on my previous post). Any idea on how to fix that? :blink:

Cannot say. :unsure:

Another "queer" behaviour of Winddows 7?

All I want is to find out the PHYSICALDRIVE I need to use as DESTINATION for dsfi.

Post a screenshot of Disk Management...

jaclaz

Managed to solve this just as you replied. dsfi working as we speak, "new" disk should be ready in 20-30 minutes :w00t:

So that's done! I now have the 1 TB drive with the .dd image on it. I've run CHKDSK /F on that drive, and I've managed to access the data on that drive. So far Windows 7 is letting me access the data but not letting me copy it to another drive. I've attached a screenshot of how the 1 TB drive looks like right now.

This is looking good, what's next? :angel

post-361895-0-46169700-1348242227_thumb.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...