Windows doesn't recognize a partition as NTFS but recovery tools do

Question

Today a computer of mine with Windows Vista can't boot any more. The message "Windows is starting" shows up and a few seconds later it reboots automatically.
So I took the HDD out and plugged it on another computer with Windows 7. This is what the Disk Management shows:
i.e. the partition has the correct size, but it says "RAW" instead of "NTFS".

---

Then I installed a tool called "EasyUS Partition Recovery" and it shows this:
i.e. it correctly detects the partition as NTFS with its correct size and used space.

This tool doesn't let me do anything with that partition because it doesn't see any problem with it.

---

Then I installed another tool called "DiskInternals Partition Recovery" and it also recognizes the partition as NTFS:

This tool allows me to mount that partition as a virtual drive letter (without doing any recovery process). When I do this I can see all my files. The entire content of the partition is there, there doesn't seem to be any problem with the partition whatsoever.

But, unfortunately, Windows doesn't detect that there's an NTFS file system in that partition, so I guess there must be so sort of minor corruption in the partition format or something. But the tools I have tried so far don't detect any problem.

What would be an appropriate tool to use in this case that can fix whatever problem is causing Windows to fail to detect it as NTFS?

Answer 1

Windows Vista dates from 2006, and I assume that the disk is just about of that age as well. Such an event should serve as an alarm of that perhaps this disk is experiencing problems and is nearing its end of life.

What I would suggest :

• Use DiskInternals Partition Recovery to mount the partition
• Copy everything from the partition to a backup partition on another disk. This will also serve as backup in case the disk totally fails.
• Format the partition as NTFS using slow (not quick) format
• Copy back the files to the partition.

In the future, be very suspicious of this disk and keep backups.

Answer 2

What would be an appropriate tool to use in this case that can fix whatever problem is causing Windows to fail to detect it as NTFS?

There is no tool that fixes any NTFS file system problems. There is Testdisk which allows to fix certain well defined issues which do not require (much) interpretation.

Duplicate the partition into a file using ddrescue. Use the map file feature, keep the map file and a screenshot or terminal dump of the result screen.

You can then try out if Testdisk solves your problem.

But those are only quick fixes. The first thing to do is always to check the SMART parameters using the smartmontools command smartctl -a /dev/sdX > smartstuff.txt. Replace "X" by the relevant disk letter. That does not take time and provides you with valuable information. Your further steps should depend on the outcome of the SMART report.

The cleanest way (when SMART gives no reason to worry) is to then read out the files, quick format the disk and copy the files onto the freshly formatted file system. A full format is not necessary unless you are interested in the number of sectors that may have been reallocated on that occasion. That would require you to reread the SMART parameters and compare them with the figures from the first run.

This way is cleaner than running chkdsk on the partition once Windows may recognize it again.

Answer 3

The question presumes that if a data recovery tool can 'work' with a volume, Windows should be able to do so as well. It ignores the point that data recovery tools are designed to work with partitions that Windows can no longer access.

But idea of file recovery tools is that they can accept partial data and can ignore corrupt file system meta data where Windows expects the file system to be intact.

The idea can be simply demonstrated by for example assume the first 100 records of the $MFT being corrupt: Windows will not be able to work with such a file system, while a file recovery tool simply parses the rest of the 500000 $MFT records and will thus be able to show an almost complete file system. As an example .. :

.. this file recovery tool detected a chunk of MFT records that starts at the 24th record which suggests 0 - 23 are missing. Windows could never mount such a file system and designate it as RAW while the file recovery tool happily reconstructs a nearly complete folder tree.

In addition to that, a file recovery tool may simply designate a volume as NTFS just because the partition table does so. The RAW file system that Windows shows is not because it can not read the partition table and reach that same conclusion, it is due to it having tried 'mounting' the file system and having failed during that process.

You're basically comparing apples to oranges.

---

Important: RAW file system can be result of inability to access key sectors which in turn can be the result of a physical issue with the drive. This should always be investigated first. Assume the worst first, then go from there.

If there are any signs of physical issues then:

• Avoid in place repairs
• Avoid scanning the drive using file recovery tools

Instead clone/image the drive using a tool like ddrescue or HDDSuperClone

---

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.

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, for example the NTTS boot sector points to first cluster of the $MFT and provides parameters such as cluster size which we need to convert the cluster address to an actual LBA address.
• Windows then parses the $MFT

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

So, 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, or 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:

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

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.

Verify if the entry you want to repair resolves to a file system! Select the entry and click 'Open Volume'. If DMDE does not resolve the directory tree then repairing the entry is of little use. You'll be repairing a volume that you will not be able to access after the repair.

So, after 'Open Volume' you should see a directory tree sort of as you expect it to be:

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.