I have got the same problem. Testdisk report that Boot sector is not OK, but the backup of Boot Sector is OK. I have restored the Boot Sector from backup, and booted. Now Windows can see the memory card that was affected, but I get only one file called USBC. A file recovery program told me I have different FAT copies. But I wasn't sure if I want to use "experimental" option of FAT fix in Testdisk, because there is no option to backup the FATs first. What should I do? Or, how at least I can backup the FATs, so if the fix fails, I can restore to the previous state to try something else?
Ryan: sorry for the delay. I was in a middle of a holiday trip when you posted, and I didn't notice it earlier. The easiest way to backup the contents is to create an image of the whole device. Note that I mean "device" not just "volume" (partition, etc). If you have any access to any linux, there's a `dd` command that will be able to literally copy everything byte-by-byte from raw device like /dev/sda to a file, or later copy it from the file to the device. It can take some time and it will create "backups" (or rather, dumps) with no compression, so be sure to have enough free space. Regarding USBC file - it means that the restore failed. Either a wrong backup was chosen, or the backup was damaged, too, or maybe everything went well and it's "just" the real partition that is damaged. Any of it could have happened if you tried repairing the drive with other tools before running TestDisk. You 'd best have taken a whole-device dump/backup even before running testdisk, just in case. Now as it is, the best thing (except for taking a backup, late but still), I'd check with hexeditor or any other raw drive analyzer to see what are the actual contents of the device. The "USBC" file is not a file. It is a header of a section. From my experience, seeing USBC as a file usually means that this section has been misplaced during repair, and it's usually +1 or -1 sector off from the place it should be. The section sometimes gets duplicated, too. However, in all such cases, the actual correct contents of the drive were still there, and after I reconstructed the contents of that sector, everything started working well. I think I described all I knew and done.. sorry, it's hard to remember now
I have simmilar problems with my nh92, i tried to repair ntfs tables, worked once, then win7 or any other windows OS asked me to format the disk - which was out of question(had very important data on nh92).
I used ubuntu and opened it without any problems. Works on ubuntu all the time, doesn't work on any WinOS(here and there I get it to work on windows7, but it seems that it is random luck - usualy when the rainbows are outside my window and unicorns run around).
Interesting analysis, very helpful. I ran into a similar issue and ended up implementing it in my software. Would love to see variations on the issue, so share images if you can and prod me.
Just happened to me, Boot sector destroyed on my SD Card, just by pluging it in. I could recover my data using recovery software, BUT this is in no way an acceptable solution. Somehow, Somewhere, Someone F-ed up big time with this low level stuff :)
Used a Hama SD Card adapter and a exFAT formated 256GB SandDisk Pro SD Card. On the SD Card was a (i think) bootable partition with the Magic Lantern Firmware used to enhance Canon Cameras with RAW Video.
I pluged this into my HP Z820 Workstation with Windows 10 x64 (version 1909) which had at the same time some extremely large 20 TB Lacie Raid harddisk attached with USB-3. This harddisk definitely uses the SCSI over USB Protocol. I noticed fanciness before, when this disk is attached (other Disk sometimes would not show up at all, unless I disconnected the SCSI over USB disk...then the other USB Disk, which was previously not detected at all by Windows started to show up again).
There must be a root cause, somewhere in the realms of the SCSI over USB in combination with bootable ExFAT partitions. So far I wasn't able to restore my bootable SD Card with testdisk and the like. I could recover my footage, and to the recovery software...the partitions apears to be completely fine....unfortunatelly I can only recover data with the software...theres no option to restore the bootable partition.
8 comments:
I have got the same problem. Testdisk report that Boot sector is not OK, but the backup of Boot Sector is OK. I have restored the Boot Sector from backup, and booted. Now Windows can see the memory card that was affected, but I get only one file called USBC.
A file recovery program told me I have different FAT copies. But I wasn't sure if I want to use "experimental" option of FAT fix in Testdisk, because there is no option to backup the FATs first. What should I do? Or, how at least I can backup the FATs, so if the fix fails, I can restore to the previous state to try something else?
Ryan: sorry for the delay. I was in a middle of a holiday trip when you posted, and I didn't notice it earlier. The easiest way to backup the contents is to create an image of the whole device. Note that I mean "device" not just "volume" (partition, etc). If you have any access to any linux, there's a `dd` command that will be able to literally copy everything byte-by-byte from raw device like /dev/sda to a file, or later copy it from the file to the device. It can take some time and it will create "backups" (or rather, dumps) with no compression, so be sure to have enough free space. Regarding USBC file - it means that the restore failed. Either a wrong backup was chosen, or the backup was damaged, too, or maybe everything went well and it's "just" the real partition that is damaged. Any of it could have happened if you tried repairing the drive with other tools before running TestDisk. You 'd best have taken a whole-device dump/backup even before running testdisk, just in case. Now as it is, the best thing (except for taking a backup, late but still), I'd check with hexeditor or any other raw drive analyzer to see what are the actual contents of the device. The "USBC" file is not a file. It is a header of a section. From my experience, seeing USBC as a file usually means that this section has been misplaced during repair, and it's usually +1 or -1 sector off from the place it should be. The section sometimes gets duplicated, too. However, in all such cases, the actual correct contents of the drive were still there, and after I reconstructed the contents of that sector, everything started working well. I think I described all I knew and done.. sorry, it's hard to remember now
"The BootSector that was damaged was at offset 0x7E00 so at sector 0x3E".
Here is error. Sector at offset 0x7E00 has LBA number 0x3F.
I have simmilar problems with my nh92, i tried to repair ntfs tables, worked once, then win7 or any other windows OS asked me to format the disk - which was out of question(had very important data on nh92).
I used ubuntu and opened it without any problems. Works on ubuntu all the time, doesn't work on any WinOS(here and there I get it to work on windows7, but it seems that it is random luck - usualy when the rainbows are outside my window and unicorns run around).
I think this bug is happens in windows xp sp3 and windows 7. Not in windows xp sp1, win2k and any linux. But this should be checked out.
Interesting analysis, very helpful.
I ran into a similar issue and ended up implementing it in my software.
Would love to see variations on the issue, so share images if you can and prod me.
Just happened to me, Boot sector destroyed on my SD Card, just by pluging it in.
I could recover my data using recovery software, BUT this is in no way an acceptable solution.
Somehow, Somewhere, Someone F-ed up big time with this low level stuff :)
Used a Hama SD Card adapter and a exFAT formated 256GB SandDisk Pro SD Card.
On the SD Card was a (i think) bootable partition with the Magic Lantern Firmware used to enhance Canon Cameras with RAW Video.
I pluged this into my HP Z820 Workstation with Windows 10 x64 (version 1909) which had at the same time some extremely large 20 TB Lacie Raid harddisk attached with USB-3. This harddisk definitely uses the SCSI over USB Protocol. I noticed fanciness before, when this disk is attached (other Disk sometimes would not show up at all, unless I disconnected the SCSI over USB disk...then the other USB Disk, which was previously not detected at all by Windows started to show up again).
There must be a root cause, somewhere in the realms of the SCSI over USB in combination with bootable ExFAT partitions. So far I wasn't able to restore my bootable SD Card with testdisk and the like. I could recover my footage, and to the recovery software...the partitions apears to be completely fine....unfortunatelly I can only recover data with the software...theres no option to restore the bootable partition.
Post a Comment