Home > Uncategorized > Windows 10 installation problems with Truecrypt – Overwriting the Partition

Windows 10 installation problems with Truecrypt – Overwriting the Partition

I had my data drive on the SATA SSD, which typically turns up first as disk 0 in most disk-level tools like imaging and installation programs, and my system drive in the mSATA SSD, as disk 1. Both are 256GB.

Disk 0 was encrypted at a partition level with Truecrypt, which would typically make a drive or partition look unmountable and like garbage. My system would boot on disk 1 partition 1, and then I would automount the truecrypted partition on disk 0 partition 0

It appears what happened, was that when I was in the basic disk configuration screen at the start of Win10 fresh installation, although I formatted disk 1 partition 1 (the old C:), it also turned disk 0 partition 0 (the Truecrypt data) into a system partition. From what I understand of System partitions, this includes overwriting the first sectors of the partition with new boot files, like boot.ini. I would expect that on Truecrypt volume, this would spell disaster, as it might overwrite important Truecrypt initialisation data, like the master key

I saw that D0P0 was definitely a system partition now, and I don’t remember it being so before. A check of previous disk imaging notes, although part-obscured, suggest that the Truecrypt volume was NOT system-formatted – just as a primary partition.

2015-08-15 21_26_08-Home Shared - Microsoft OneNote Online



The fact it’s the only RAW partition (ie. Can’t be identified as NTFS because it’s encrypted), suggests that’s the truecrypt volume. As you can see, it’s not SYSTEM from this screenshot taken a while before I upgraded.

So – the first few sectors of my Truecrypt data volume are screwed. When I had tried mounting it using Truecrypt in Windows 10, it gave an error along the lines of “The host volume/file is in used and cannot be mounted”. At first I had assumed it was a Windows 10 error, so I restored my old Win7 image and tried mounting it from that, but got exactly the same error.

OK – so, next was to try to recover the data volume. I discovered that the way to do this was with the Truecrypt ISO, that you may remember it badgering you to create every time you encrypted a volume, and maybe you did, maybe you didn’t! I tried checking the archived Truecrypt site, but the fact is that this ISO is only available from the software installed on your machine, when you encrypt the partition.

Some tools are common to any Truecrypt ISO, like restoring the bootloader, but some are specific to your specific ISO file for that volume, such as restoring the master key.

I looked at creating a boot USB to mount the ISO file without having to burn a DVD, but that looked very hard compared to the alternative, so I plugged a USB DVD drive in, and burnt the DVD.

When booting from that DVD, it booted successfully into the Truecrypt rescue app. It gave four options, including restoring the MBR, Master key, and so on. I tried each of those, but none worked. Interestingly, they only identified one drive/partition to select from to fix – it wasn’t clear if that was the one I had originally installed in it, or not.

Also, I suspected the master key was not the same anyway. I had copies of the recovery ISO generated when I encrypted the C: drive every time I rebuild or restored my Windows installation, but the D: drive that I was trying to recover had been encrypted many iterations ago, and reattached each time. Hence it was likely specific to a recovery ISO that had long since been lost.

In any case, the recovery didn’t work, and the partition remained inaccessible.

At this point, I gave up – I could have perhaps tried hacking around with the boot sector and MBR, but I didn’t have time to learn all that. I hoped I had a full working backup on my local NAS from Crashplan, and, in the worst case, a copy of my main document folders in Spideroak too, which I use to Sync.

It turned out Crashplan seems to have worked as advertised – I restored from the image on my NAS, which took 1 hour to re-sync the block information to my PC, and then 8 hours to restore all the data over a 1Gbps ethernet connection. I’ve tested some VMware copies and some documents, and so far everything seems to have been there. I highly recommend Crashplan as a fallback for all such issues.

I’ve since played around with various other issues, such as Win10 being corrupted and Office2013 failing to work with it. At some point I’ll rebuild with the system entirely, when I have time.

Categories: Uncategorized
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: