0

So I was trying to create a bootable USB to reinstall Windows for a friend, but mistakenly started partitioning the wrong disk (probably the dumbest mistake I could have made).

This disk is a 1 TB WD Black in NTFS format, hooked up as my D: drive to Windows for a variety of photos, documents, movies and game installs – the basic home stuff.  There was about 400 GB of files on the drive (i.e., it was about 40% full).

The following sequence of events occurred:

diskpart
select disk 1 // wrong disk number
clean
create partition primary
select partition 1
active
format fs=ntfs // note the missing 'quick' argument

It then ran to about 3% when I realized my mistake.  So I hit Ctrl+C to cancel the formatting.

In Windows' disk management tool the drive now shows up as healthy, active, primary NTFS partition that is 100% free and 931 GB capacity.

So after some googling, I downloaded TestDisk. I tried analyzing and then the deeper analysis of the drive, which just came back with 1 available partition that is fully empty. The only files found were within the "System Volume Information" folder. It didn't seem to be able to restore any MFT copies or lost partitions, but I'm not an expert with these things so maybe I did something wrong – I wasn't sure exactly what guides and steps to follow since I did more than a simple diskpart clean.

After all that failed me, I attempted running PhotoRec to see if any files could be found. That also failed with 0 files found.

I'm out of ideas now, but from my (limited) knowledge, at most 3% of the drive was re-written in the format, so the rest of the drive should have intact data that can be recovered. What more can I try?

Update: Using Frhed, a hex editor, to load up the partition gave "A disk read error occurred...BOOTMGR is compressed" (image below). Trying to scroll through the sectors everything shows 0 – but without a boot sector, it can't be read so is this reliable?

Update 2: according to this question on Tom's Hardware forum, using Ctrl+C to interrupt the command doesn't actually stop the formatting, it runs in a separate process in the background. Since I didn't immediately reboot my PC it has indeed overwritten the entire disk. Thanks for all the help, I wouldn't have needed to ask this question if I had known this sooner.

Hex editor output

Ward D.S.
  • 103
  • 3
  • (1) One of the cardinal rules of recovering information from a corrupted / compromised storage volume (e.g., disk) is ***don’t write to it** until you’re done, and you’re ready to give up and just erase it.* (I’m surprised that the linked thread doesn’t mention this.) So I believe that running a `diskpart` command like `clean` again has very little chance of being helpful and a high probability of being harmful. … (Cont’d) – Scott - Слава Україні Oct 21 '18 at 18:15
  • (Cont’d) …  (2) In case [Xen2050’s comment (on their answer)](https://superuser.com/q/1368631/150988#comment2059490_1368655) isn’t clear — the “A disk read error occurred” text that you’re seeing is part of *the data in sector 0* — it’s ***not*** an error message from Frhed.  I have removed it from your title because that is very misleading. … (Cont’d) – Scott - Слава Україні Oct 21 '18 at 18:15
  • (Cont’d) …  (3) You don’t need a boot sector to be able to read from a disk. But, in fact, I believe that that screenshot you show ***is*** a boot sector. In any case, the fact that you could read that suggests that you are successfully reading from the disk (and that, sadly, the disk has a lot of zeroes in it). As Xen2050 (somewhat unclearly) suggests, if you jump to sector 86000000 (≈ 44 GB; i.e., approximately 4% of the way into the disk), you should start seeing some real data. – Scott - Слава Україні Oct 21 '18 at 18:15
  • Thanks for this Scott. I can actually not fathom what I did that overwrote my data but like was suggested I skipped around and went to various parts of the drive withFrhed and it's all 0. The only thing I can think of is that the formatting command never actually ended but rather continued in the background, or one of the things I did with TestDisk was completely wrong and overwrote my data? I'm actually stumped here because the "don't write to it" was very obvious to me also and I was quite hopeful initially that I'd get my files back - until all the recommended tools failed me... – Ward D.S. Oct 21 '18 at 19:00

1 Answers1

1

How may partitions were originally there? If only one, then it's size may not have changed, and testdisk wouldn't find any other partitions (but it might've possibly found some files to undelete - did you check for files?).

PhotoRec definitely should have found some files to undelete, unless they were very small and all managed to get overwritten in that first 3%... was it definitely reading the correct drive, and was looking for all filetypes? If not, you might've only been searching for 1 or 2 filetypes and it just didn't find any.

TestDisk and PhotoRec both have great webpages with documentation like TestDisk Step by Step to recover lost partitions and repair damaged FAT/NTFS boot sector.

(I do like to use a GUI like gparted to see what's going to be overwritten first, and try keeping other drives disconnected or at least asleep to avoid these types of problems, and backups are important too)

Xen2050
  • 13,643
  • 4
  • 24
  • 42
  • Hey, there was just the single partition, so you're correct that the partition size did not change. I will continue scanning with Testdisk and PhotoRec. There was about 400 GB of files on the drive. Do you think it would make sense to `diskpart clean` again so TestDisk has an unpartitioned drive to work on? – Ward D.S. Oct 21 '18 at 11:07
  • If the partition's in the same place as original, it shouldn't change or help anything by clearing and creating it again, or leaving it cleared. Photorec should find something, you could take a look at the drive yourself with a hex editor (I like bless, it quickly "scrolls" through a large device/file) or read random spots with `dd ... skip=... | hd | less` and see what's really there, like all zeros everywhere would be unusual. Overwriting the entire drive should've been as slow as writing to the entire drive – Xen2050 Oct 21 '18 at 11:56
  • Added a comment with the hexeditor's output. I will google for this and see if I can fix that and if it would enable the tools to find more from the drive. – Ward D.S. Oct 21 '18 at 14:33
  • The "A disk read error occurred..." message only shows up in the text/ASCII output when reading the disk, right? So it's just what's written there, unless there are other system/error messages? Should be more readable data (something besides zeros) 10% or 25% or 50% into the disk, if there PhotoRec should've found something... – Xen2050 Oct 21 '18 at 15:03
  • Yea so the hexeditor just gives me 0's everywhere that isn't at the start or at the very end (last and first sectors are similar, with the error message from my screencap in the ASCII output). How I managed to overwrite everything with zeroes is beyond me. Ctrl-C should have cancelled the formatting and I was careful with TestDisk to not do anything that would write to the drive, the only long-term operations ran were analysis and deeper analysis. I was hopeful these tools would work but apparently I messed up badly enough to overwrite my data fully. Thank you for the help. – Ward D.S. Oct 22 '18 at 10:52