All NTFS volumes on drive turning inaccessible at the same time

Question

On Windows 10 I was browsing one of three NTFS partitions on an external USB drive. After a reboot none of the NTFS volumes on the drive are accessible, as in "can't even run chkdsk/damaged file system/partitions are raw"-inaccessible. Each resided on its own primary partition.

My level: I don't know enough about internal (NTFS) file system structures to reason my way to what happened.

What I did before it happened

1. Browsed to a directory I didn't have access to. Explorer offered to grant permanent access. I accepted. (I did this twice)
2. I expected a 1 second operation, but it was taking forever (recursive, apparently)
3. I failed to abort the operation by safely ejecting the drive, because Windows refused to eject it during alleged use.
4. I asked Windows to reboot the machine, safe in the knowledge that it wouldn't do so before it was deemed safe, and that at worst I'd be left with a directory tree that I wouldn't have complete access to.
5. Windows rebooted the machine in an orderly fashion. I did not force anything. In fact I was just hitting "Cancel" on the shutdown screen in order to inspect which app was preventing the shutdown when it simply proceeded with the reboot.

After the reboot all NTFS volumes on the drive had damaged file system structures according to Windows.

1. Whatever I tried (rebooting, restarting the USB hdd dock, reseating the drive) I couldn't get them to read. Chkdsk refused to run from the explorer gui due to the drive being inaccessible.
2. Connected the drive to internal SATA in another machine...
3. ...and when starting Win 10 on that machine it immediately wanted to run chkdsk on the new drive, which then took more than an hour.
4. The NTFS volumes are still not accessible in Windows (one is still raw, and the other two are 0 B size NTFS). The NTFS volumes are readable in Linux, but pretty much every single file has been moved into found.000.
5. A non-NTFS ext volume on an extended partition on the same drive mounted and read just fine in Linux as far as I could tell.
6. SMART data was all fine. Short self test ran with no complaints.
7. The USB HDD dock has worked fine with the drive for years. There's no apparent defect in this dock after this incident either, but I'll use internal SATA going forward in this Q, just to be safe.

This gives rise to more than one question in my head:

1. On the one hand I don't understand how Windows managed to destroy all three NTFS volumes at once — I wasn't even interacting with or writing to the other two! Is there a plausible explanation for this? If I could understand that better then I could make more informed decisions about Windows/NTFS/USB drives in the future. I'm hoping this falls under the "please explain this to me" qualifier for questions on this site.

2. On the other hand, after reading some recovery answers here, I wouldn't mind knowing whether there's any point in...

   1. ...trying to make the volumes readable in Windows (or to just be content with that they can be read in Linux)? I would be more confident in knowing that Windows thinks the volumes are actually readable.

   2. ...attempting any more involved recovery on the two volumes that became readable in Linux after chkdsk moved all files to found.000. I'm guessing "no" since chkdsk has performed writes when rescuing files?

   3. ...attempting applicable recovery on the "raw" volume assuming it was touched by chkdsk but still remained raw? I'm unfamiliar with the exact operations chkdsk performs while trying to fix a file system.

About backups

With this question I'm attempting to understand the circumstances of my problem, partly to avoid it in the future. I'm aware of the importance of backups and will be looking at what was/wasn't backed up in parallel with this Q. With this I'm hoping that we can focus on the part of the problem that's not related to backups.

---

Update, DMDE

Update, DMDE 2

I did a full scan on the first partition.

After reading about the various columns in the DMDE help it was still difficult to interpret the values. For instance, what does "Files", the %-bar graphs and "Start LBA" mean here? Intuitively everything but a start LBA at 2048 seems suspicious, but the field doesn't seem to be defined in the help so it's hard to say:

Looking closer it seems to maybe be zeroing in on a small NTFS disk image that was stored on the partition, meant for a 32 GB USB stick. That certainly would explain things about these column values and clear up some confusion. A head's up for future readers — things simply weren't complicated enough.

Answer 1

Problem is chkdsk ran and 'repaired' the file system to a 'consistent state'. However to achieve this it sacrificed the directory structure etc. and moved all files to found.000 folders. NEVER run chkdsk to recover data!

If your data is valuable, it's best to skip DIY attempts and consult with a data recovery professional.

Found.000 folders:

It is often possible to recover files from these using so called 'chk recovery tools'. You'll find plenty using Google, often free and they all do the same simple thing, namely check if file header is a known type. IOW if first 3 bytes are 0xFF,D8,FF then simply rename the file to .JPG rather than .CHK.

Recover filenames and folder structure:

Due to the way file system work, the files 'deleted' by chkdsk are simply file system transactions. It makes sense to try a file recovery tool and try if it can recover files including filenames and folder structures.

RAW file system:

A (according to Windows) RAW file system is any file system which Windows can not determine. So this may be a foreign file system which is 100% valid but it simply doesn't know or a file system that is corrupt.

File system corruption knows many forms, causes and whatnot, so RAW file system is basically a 'catch-all' that tells us nothing specific. One flipped bit at the 'right' place is all that's needed while it can also be true that a significant part of the file system is corrupt.

DMDE is a tool that can help us get some additional info, see what we're dealing with. I'll ignore file systems Windows will not recognize anyway.

DMDE does some quick checks: It checks partition entry (E), boot sector (B), backup boot sector (C) and file system (F).

To determine the file system Windows needs to 'walk' a chain of structures: Partition entry points to boot sector, boot sector points to file system structures. If chain breaks the file system can not be determined.

RAW file system can theoretically be caused by any of those:

If E does NOT point to valid boot sector (B) OS will be looking at non boot sector > unrecognized = RAW file system.

If boot sector is corrupt (B) Windows may not find correct pointer to rest of file system. F will not be found.

If E and B are intact and valid DMDE should be able to locate MFT structure (assuming NTFS), if not F is absent, if it appears corrupt F is red.

E, B, F can be absent (not found) or red (contain nonsense, for example uneven cluster size).

In this example:

E (partition entry), B (boot sector), C (backup boot sector) are okay, both the MFT and MFT mirror are not found/corrupt (xx).

In-place Repair:

DMDE offers some repair options, examples:

For example IF B is absent or red while C is present and green you can repair the boot sector using it's backup.

If B, C and F are present while E is absent you can add the partition to partition table.

I advise you first create a disk image, a sector by sector backup of the drive!!

To make repairs, tick 'advanced mode' first. Now right click menu for an item has an 'Edit' item. None of these repairs make sense after chkdsk was run.

File Recovery alternative

This is the safest approach!! For any volume you can try option 'Open Volume' and DMDE will try parsing the file system as-is.

'Full Scan' will ignore existing file system and build a virtual file system. Many tools exist that offer similar functionality, I am simply using DMDE as an example to illustrate multiple roads to recovery of your data.