Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Long story short: Got 1 TB HDD. Created one fullsized (non-system-)partition on that. Encrypt via TC. One time, via boot, Win presumably formats that (and maybe writes some bytes on it). I manage to restore TC-Header, now TC can mount the partition. But Windows says "Must format drive to use it." "Filesystem not detected." Anyways, I can recover nearly all data via GetDataBack from this mounted partition.

This is where I'm now. Now I just want to know: Is there a way how I can repair the partition and use it "normally" again? Or do I have to reformat, and copy back the backedup files?

TC repair said "... Filesystem is NTFS ... First NTFS startsector not readable ... Going on with second NTFS startsector ... version and status of volume cannot be detected. Aborting"

share|improve this question

closed as off-topic by Adnan, Xander, Gilles, NULLZ, Eric G Aug 16 '13 at 2:12

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions about general computing hardware and software are off-topic here, but can be asked on Super User." – Adnan, Gilles, NULLZ, Eric G
If this question can be reworded to fit the rules in the help center, please edit the question.

1 Answer 1

TrueCrypt provides a volume: a big sequence of bytes. TrueCrypt puts itself between these bytes and the physical storage medium, by applying encryption whenever the data is to be written to the disk, and decryption when it is read. TrueCrypt stops there. The meaning of these bytes is none of TrueCrypt business.

An operating system like Windows will take this bunch of bytes and organize it into an abstract set of directories and files. This requires dedicating some of the bytes to "administrative tasks", to encode the structures which tell where the file data physically is, and what are the file names, access rights, modification dates and so on. These structures are called a filesystem. NTFS is a filesystem.

In your case, Windows says: in these bytes, I see no filesystem. The TC repair tools comes to the same conclusion: there is no recognizable structure usable as a NTFS filesystem. GetDataBack can recognize shreds of a NTFS filesystem and scavenge some of the files, but GetDataBack does not pretend to repair the filesystem (in the same way that extracting reusable parts from a wrecked car is not the same as making the car functional again). All these tools work on the "big sequence of bytes" that TrueCrypt can show by decrypting that which is stored on the disk. In other words, TrueCrypt is not relevant to your situation (except maybe as the culprit).

For some reason, which is not yet elucidated, the filesystem structures are damaged, and are gone. Since TrueCrypt has no idea whatsoever about what a filesystem may be, it can be considered as a sort of extension of the hard disk, storing whole sectors, not files. It so happens that the OS, at some point, asked TrueCrypt to write down some bytes which appeared to be garbage, and to destroy the filesystem structure. TrueCrypt merely complied.

The best you can do, at that point, is salvage what you can with GetDataBack (as you say, "nearly all data") and/or exhume your last backup, then start over with a fresh format.


There are many possible reasons why this sort of problem may occur. A bug in TrueCrypt could explain it; but also a failure in the hard disk itself, including the electronic part of the disk. I also once (actually, three times) had a problem with a PCI network card which, under high load, would begin to put random noise on the PCI bus. This triggered an OS "panic" and the kernel would then do a quick unmount of the filesystems, thus writing a "clean" superblock (the top of the filesystem structure). Unfortunately, that write call would travel over the PCI bus, and the data reaching the hard disk would then be utterly mangled. This was leading to the same symptoms as what you presently observe.

A bug in the OS itself (Windows) could also be a plausible explanation. Even more probable, bad RAM: the OS works by following structures in RAM, which tell it what to do. A bad bit at the wrong value can wreck havoc to these structures and induce the kernel to write out garbage data on its disks.

The possibilities are endless. Therefore, make regular backups.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.