--- Background ---
- Using testdisk-7.2-WIP.win64
- HDD is Maxtor DiamondMax Plus 9 120GB ATA/133
- Original OS is WinXP Pro, likely SP3 with `EFS` directories
- Image snapshot made after failure
--- Operational status ---
HDD used with single partition for many years as primary OS/disc. Transferred data to new computer and backups of most files are *probably* intact. However, confirmation is desired. HDD was booted in original or similar computer. HDD would not boot and ended in blue screen error. Upon reboot the error ```No bootable drive present``` was displayed.
--- Mistake: Snapshot of drive in initial state was not captured ---
Rather than initially booting in an enclosure and capturing a disk image, the drive was booted in a machine of similar configuration to the original. After the disk error, the machine was powered off and transferred to an external enclosure on a separate machine. This initial boot after years of storage may have damaged the MBR or boot files after initial access.
On powering up in the external enclosure and connected to a Win10 machine, the OS detected the drive as RAW and unformatted. Additionally, the drive appeared to be producing 'click of death' sounds during read operations.
In an attempt to preserve data on the drive, an image was created resulting in an `image.dd` file that was approximately the size of the original drive (120GB) and a log file is available and will be posted next. Once the image was created the original drive was powered down and all operations were attempted on a copy of the image file. As the volume contains encrypted directories which are the user directories with files, I don't believe that PhotoRec would be able to recover those files.
Both `initial scan` and `deeper scan` have revealed no correct partitions. I believe that the attempt to boot the drive caused some type of error which has destroyed MBR and partition data that TestDisk would ordinarily use to recover files. Initially loading TestDisk and providing the `image.dd` file as a parameter have shown three odd sectors when I think there should be one. I cannot tell if some partitions are supposed to be related to the above EFS directories as I do not have the technical background to understand how EFS directories were stored. The partitions are listed as ```Sys=72, Sys=74, and Netware 3.11+```. But, none of the detected values seem to make sense. Image of detected values available.
A quick search has revealed no partitions found.
A deeper search has revealed no partitions found.
--- Questions ---
Am I missing a setting to properly indicate how TestDisk should analyze the disk image?
While further disk damage is possible if repeated, is there another setting or method that would have captured a better image making recovery more likely?
Can I make a copy of the image file and force write an NTFS partition assuming the entire volume was one partition?
If the correct values for writing an NTFS partition cannot be guessed then would it be possible, even if time consuming, to script brute forcing the values in some way?
Is there a way to directly mount the image file as a virtual drive and use Windows utilities, or others, to restore the partition?
Similar to the previous question, could I write the image file directly to a virtual drive and attempt other recovery methods?
If operating from a bootdisk, restarting makes sense. But, if an image file (image.dd) is being changed is a computer reboot really required?
Within a different OS is quitting TestDisk and restarting the whole computer really required?
Or will restarting the program itself be enough?
--- Learning ---
I am far out of my depth here so this is for my own learning.
When an MBR/partition are created isn't that related to disk geometry? So, if I partitioned the same disk using a specific geometry and file system, wouldn't I get the same values each time? I'm trying to understand why if I have some known values about the disk, a single partition and file system, that I can't predict where files and structure are stored. It seems like if that were possible that TestDisk would have already done that so I want to learn what the challenges are.
Recovery of Damaged MBR on WinXP SP3 Partition
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read https://www.cgsecurity.org/testdisk.pdf
-
recuperation
- Posts: 2737
- Joined: 04 Jan 2019, 09:48
- Location: Hannover, Deutschland (Germany, Allemagne)
Re: Recovery of Damaged MBR on WinXP SP3 Partition
For confirmation just compare with your backup. Otherwise tryp to open each one up. For system files compare with a simlar XP SP3 installation.
"Approximately" is pretty useless if the end is missing. When the copy lacks the backup boot sector no partition will be found.
-On powering up in the external enclosure and connected to a Win10 machine, the OS detected the drive as RAW and unformatted. Additionally, the drive appeared to be producing 'click of death' sounds during read operations.
In an attempt to preserve data on the drive, an image was created resulting in an `image.dd` file that was approximately
?!the size of the original drive (120GB)
and a log file is available and will be posted next.
I am not aware of what odd sectors should be. You do not specify their location. This information is useless.Once the image was created the original drive was powered down and all operations were attempted on a copy of the image file. As the volume contains encrypted directories which are the user directories with files, I don't believe that PhotoRec would be able to recover those files.
Both `initial scan` and `deeper scan` have revealed no correct partitions. I believe that the attempt to boot the drive caused some type of error which has destroyed MBR and partition data that TestDisk would ordinarily use to recover files. Initially loading TestDisk and providing the `image.dd` file as a parameter have shown three odd sectors
When talking about an electronical device provide the wiring diagramm. When talking Testdisk provide the log file - very simple, telling "log is available" is not helpful at all!!when I think there should be one. I cannot tell if some partitions are supposed to be related to the above EFS directories as I do not have the technical background to understand how EFS directories were stored. The partitions are listed as ```Sys=72, Sys=74, and Netware 3.11+```.
Available to whom?
But, none of the detected values seem to make sense. Image of detected values available.
Maybe. Can't tell!
A quick search has revealed no partitions found.
A deeper search has revealed no partitions found.
--- Questions ---
Am I missing a setting to properly indicate how TestDisk should analyze the disk image?
As you did not tell how you you created your image I can't tell.While further disk damage is possible if repeated, is there another setting or method that would have captured a better image making recovery more likely?
No.Can I make a copy of the image file and force write an NTFS partition assuming the entire volume was one partition?
No. Testdisk is "brute forcing" itself.If the correct values for writing an NTFS partition cannot be guessed then would it be possible, even if time consuming, to script brute forcing the values in some way?
I don't know. Knowing how partition tables are organized there is no reason to assume to any other software could do better.Is there a way to directly mount the image file as a virtual drive and use Windows utilities, or others, to restore the partition?
Try it out.Similar to the previous question, could I write the image file directly to a virtual drive and attempt other recovery methods?
???If operating from a bootdisk, restarting makes sense.
For what purpose?But, if an image file (image.dd) is being changed is a computer reboot really required?
For what purpose?Within a different OS is quitting TestDisk and restarting the whole computer really required?
Please describe what you want to do instead of asking incomprehensible questions about Testdisk (see XY-problem).Or will restarting the program itself be enough?
You do not specify geometry when partitioning. XP 32bit (64bit does understand GPT!) writes partitions on cylinder boundaries. Yes, you would always get the same location, that is true.
--- Learning ---
I am far out of my depth here so this is for my own learning.
When an MBR/partition are created isn't that related to disk geometry? So, if I partitioned the same disk using a specific geometry and file system, wouldn't I get the same values each time?
To answer this you would have to learn how your file system operates. You successfully kept your file system a secret.
I'm trying to understand why if I have some known values about the disk, a single partition and file system, that I can't predict where files and structure are stored. It seems like if that were possible that TestDisk would have already done that so I want to learn what the challenges are.
You should rather care about your disk being possibly broken. There are lots of cases in this forum what to do but you ignored that.
You did not provide documentation. You can't be given specific information for your case.