6

(Similar to: Drive removed while accessing, filesystem is corrupt, can it be fixed?, but with the added complexity that the drive had BitLocker on...)

Hi, I am facing the following problem with an 8GB PNY Attaché USB 2.0 stick which had BitLocker encryption on.

Last week, I was in a rush to leave work and catch my train so I attempted to "Safely Remove Hardware and Eject Media" on a Windows 7 laptop while I was still accessing the aforementioned drive with DjVu. If I remember correctly, I did close the application, after viewing the warning advising me against removing the USB, and while I was shutting down the work laptop, I removed the drive. Apparently, this is what happened (according to the event viewer log entries):

Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards.

DETAIL -
8 user registry handles leaked from \Registry\User\:
Process 4224 (\Device\HarddiskVolume2\Windows\System32\wbem\WmiPrvSE.exe) has opened key \REGISTRY\USER\Software\Xerox\PrinterDriver\V5.0\NamedSettings\UNIV
Process 4224 (\Device\HarddiskVolume2\Windows\System32\wbem\WmiPrvSE.exe) has opened key \REGISTRY\USER\Software\Xerox\PrinterDriver\V5.0\ApplicationDefaults
Process 4224 (\Device\HarddiskVolume2\Windows\System32\wbem\WmiPrvSE.exe) has opened key \REGISTRY\USER\Software\Xerox\PrinterDriver\V5.0\ApplicationDefaults
Process 1268 (\Device\HarddiskVolume2\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Process 1268 (\Device\HarddiskVolume2\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings
Process 4224 (\Device\HarddiskVolume2\Windows\System32\wbem\WmiPrvSE.exe) has opened key \REGISTRY\USER\Software\Xerox\PrinterDriver\V5.0\NamedSettings
Process 4224 (\Device\HarddiskVolume2\Windows\System32\wbem\WmiPrvSE.exe) has opened key \REGISTRY\USER\Software\Xerox\PrinterDriver\V5.0\NamedSettings
Process 4224 (\Device\HarddiskVolume2\Windows\System32\wbem\WmiPrvSE.exe) has opened key \REGISTRY\USER\Software\Xerox\PrinterDriver\V5.0\ApplicationDefaults\UNIV
Device action request for device 'USB\VID_154B&PID_0048\AAAB025100000314' was vetoed by 'STORAGE\Volume\_??_USBSTOR#Disk&Ven_PNY&Prod_USB_2.0_FD&Rev_8192#AAAB025100000314&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}' with veto type 5.

The following morning I wanted to copy some files off of the stick and tried to use it on my Windows 8.1 laptop at home; it took a long time to bring up the window informing me that this was as BitLocker-encrypted USB key, so, again, I (stupidly) removed it.

The event viewer entries were as follows:

The driver detected a controller error on \Device\Harddisk1\DR2.
The driver \Driver\WUDFRd failed to load for the device WpdBusEnumRoot\UMB\2&37c186b&0&STORAGE#VOLUME#_??_USBSTOR#DISK&VEN_PNY&PROD_USB_2.0_FD&REV_8192#AAAB025100000314&0#.

As I was doing that, the window finally came up for a brief instant. When I re-inserted it, I got the all-too familiar dreaded "You need to format…" window.

When I clicked on "Cancel", I was informed that the "Location is not available": Disk Management didn't help either – the USB is now "RAW"

I used repair-bde and this is what I came up with:

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>repair-bde G: F: -pw -F
BitLocker Drive Encryption: Repair Tool version 6.3.9600
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Enter the password to unlock this volume:
Beginning scan for BitLocker metadata.

Scanning boot sectors for pointer to metadata: 100%
Scanning sector boundaries for metadata: 100%
Finished scanning for BitLocker metadata.
LOG INFO: 0x0000002a
Valid metadata at offset 35762176 found at scan level 4.
LOG INFO: 0x0000002b
Successfully created repair context.
Beginning decryption.
Decrypting: 100% Complete.
Finished decryption.

ACTION REQUIRED: Run 'chkdsk F: /f' before viewing decrypted data.

C:\WINDOWS\system32>chkdsk F: /f
The type of the file system is NTFS.
The first NTFS boot sector is unreadable or corrupt.
Reading second NTFS boot sector instead.
Unable to determine volume version and state. CHKDSK aborted.

Interestingly enough, when I attempt to use a "wrong" password, it complained about it (something to do with the LOG INFO…). Using repair-bde with an ".img" file didn't work either – although I did not see any warning or error messages:

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>repair-bde G: F:\recover.img -pw -force
BitLocker Drive Encryption: Repair Tool version 6.3.9600
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Enter the password to unlock this volume:
Beginning scan for BitLocker metadata.

Scanning boot sectors for pointer to metadata: 100%
Scanning sector boundaries for metadata: 100%
Finished scanning for BitLocker metadata.
LOG INFO: 0x0000002a
Valid metadata at offset 35729920 found at scan level 4.
LOG INFO: 0x0000002b
Successfully created repair context.
Beginning decryption.
Decrypting: 100% Complete.
Finished decryption.

The size of the resulting *.img file is 7.46 GB (8,011,390,464 bytes), but as you probably guessed, it doesn't open with 7-Zip, WinRar, or, of course, with Windows Explorer; it's a corrupted archive.

I even tried to salvage the disk contents using a ddrescue on an Ubuntu 14.04 machine (as per the instructions at (iBoyd) » Recovering Data from a Failing Bitlocker Hard Drive – no luck either, although, once again, there were no error messages:

user@laptop:~$ sudo ddrescue /dev/sdc /dev/sdb ~/Downloads/rescue.log -r -1 -a 10000 -d --force
[sudo] password for user:


GNU ddrescue 1.17
Press Ctrl-C to interrupt
rescued: 8019 MB, errsize: 0 B, current rate: 21522 kB/s
ipos: 7356 MB, errors: 0, average rate: 4450 kB/s
opos: 7356 MB, time since last successful read: 0 s
Finished

I then tried test disk but, once again, nothing came up:

Sat May 3 00:28:38 2014
Command line: TestDisk

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
CGSecurity - Data recovery: TestDisk & PhotoRec
OS: Linux, kernel 3.13.0-24-generic (#46-Ubuntu SMP Thu Apr 10 19:11:08 UTC 2014) x86_64
Compiler: GCC 4.8
Compilation date: 2013-10-29T01:29:29
ext2fs lib: 1.42.9, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none
/dev/sda: LBA, HPA, LBA48, DCO support
/dev/sda: size 976773168 sectors
/dev/sda: user_max 976773168 sectors
/dev/sda: native_max 976773168 sectors
/dev/sda: dco 976773168 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - 1 sectors, sector size=512
Hard disk list
Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512 - Hitachi HTS725050A9A364,
Disk /dev/sdb - 8019 MB / 7648 MiB - CHS 974 255 63, sector size=512 - PNY USB 2.0 FD, FW:8192

Partition table type (auto): Intel
Disk /dev/sdb - 8019 MB / 7648 MiB - PNY USB 2.0 FD
Partition table type: Intel

Analyse Disk /dev/sdb - 8019 MB / 7648 MiB - CHS 974 255 63
Geometry from i386 MBR: head=255 sector=63
check_part_i386 failed for partition type 07
get_geometry_from_list_part_aux head=255 nbr=2
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=16 nbr=1
get_geometry_from_list_part_aux head=32 nbr=1
get_geometry_from_list_part_aux head=64 nbr=1
get_geometry_from_list_part_aux head=128 nbr=1
get_geometry_from_list_part_aux head=240 nbr=1
get_geometry_from_list_part_aux head=255 nbr=2
Current partition structure:
Invalid NTFS or EXFAT boot
1 * HPFS - NTFS 0 1 1 973 254 63 15647247
1 * HPFS - NTFS 0 1 1 973 254 63 15647247

search_part()
Disk /dev/sdb - 8019 MB / 7648 MiB - CHS 974 255 63

Results
Can't open backup.log file: No such file or directory
interface_load
Change partition type:
HPFS - NTFS 0 0 1 973 254 63 15647310

interface_write()

No partition found or selected for recovery
NTFS signature is missing.
NTFS signature is missing.
simulate write!

write_mbr_i386: starting...
write_all_log_i386: starting...
No extended partition

Interface Advanced
Geometry from i386 MBR: head=255 sector=63
check_part_i386 failed for partition type 07
get_geometry_from_list_part_aux head=255 nbr=2
get_geometry_from_list_part_aux head=8 nbr=1
get_geometry_from_list_part_aux head=16 nbr=1
get_geometry_from_list_part_aux head=32 nbr=1
get_geometry_from_list_part_aux head=64 nbr=1
get_geometry_from_list_part_aux head=128 nbr=1
get_geometry_from_list_part_aux head=240 nbr=1
get_geometry_from_list_part_aux head=255 nbr=2
1 * HPFS - NTFS 0 1 1 973 254 63 15647247

1 * HPFS - NTFS 0 1 1 973 254 63 15647247
Can't open filesystem. Filesystem seems damaged.
New options :
Dump : Yes
Align partition: Yes
Expert mode : Yes

TestDisk exited normally.

I've tried a number of demo/trial version of commercial packages but without success. I also looked at WinHex – whose output didn't look very promising when compared to a "healthy" BitLocker-enabled USB key.

Any chance I can salvage this disk? Many thanks in advance for your help!

  • 2
    There isn't anything you can do the volume is now corrupt because of your actions. Since its encrypted file recover is not possible. – Ramhound May 3 '14 at 15:51
  • 1
    +1 for doing the proper research, but I unfortunately can't help – Canadian Luke May 3 '14 at 18:03
1

I guess this isn't really an answer. However, I hope it will nevertheless be helpful to others.

Sadly, I think you've learned a rather harsh lesson regarding the use of encrypted drives, especially removable ones.

All encrypted drives whether removable or not are more sensitive to corruption issues. This makes it even more important to ensure that you have the data backed up. Clearly, the backup also needs to be encrypted and again this means that you should keep several copies of backups. The realistic minimum for backups is THREE. These should be kept in different locations.

For home use, I keep data on local PC's, copied on the NAS (the NAS drive data is duplicated within the NAS, not really a robust backup but convenient if a local disk fails) and copied to a secure cloud backup such as CrashPlan.

No form of removable media can be considered robust. Flash based memory sticks are as liable to faile as any other removable media. I don't know what the exact stats are but my own experience is that a memory stick is just as likely to fail as a hard drive, rather less than an old-fashioned floppy disk. CD's and DVD's are very variable in their reliability with some failing after a couple of years of storage, others lasting a decade or more.

Sorry about the lack of a real answer but I think this is always worth repeating so that more people understand the need for good backup processes.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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