Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Machine crash BSOD and now second partition is marked as "RAW"

Created: 20 Dec 2012 | 6 comments

Hi,

 

I am in a real jam! - my PGP WDE encypted laptop decided to have a fit yesterday and blue screened. My machine has a 320gb HD, partitioned in two with a C: for my system/os and d: for all my data/work.

 

Upon restart, the machine booted but my d: drive is now marked as RAW and keeps prompting to format. I have followed the instructions on the symantec KB article about removing/uninstrumenting the drive via the CLI, but the d: is still unaccessible.

 

Please,Please can anyone help or advise? Is there any recovery program or method that can recover this? Sending it to a third party recovery company is not an option, due to budget cuts!

 

Thanks in advance, Kris

Comments 6 CommentsJump to latest comment

Tom Mc's picture

This Knowledge Base Article might be of help.  I hope you didn't uninstrument a drive that is encrypted - this should never be done, as it is possible the data on such drive will never again be accessible.  I would suggest using the command line use in this Knowledge Base Article to assess the status of that drive. 

When you consider your issue resolved, please click Mark As Solution on the most helpful response.

Search the Knowledge Base &

KrisButler's picture

Hi Tom,

 

I did the following: (using the support docs and some other info on the net)

1. Slaved the drive off another PGP 10.2.0 MP1 encrypted base unit.

2. From the command line , typed : pgpwde --enum

3. pgpwde -status --disk 2

4. pgpwde --recover --disk 2 --passphrase "xxxxxx" , then pgpwde --decrypt --disk 2 --passphrase "XXX"

5. Machine decrypted the drive but partition on the slaved drive still unaccessible

6. did a pgpwde --status, it said drive was not managed, then i uninstrumented it. Rebooted and still not accessible

 

7. looking on the hidden system partiton that win7 creates, i have the following files listed (among others):

Bootsect.bak

PGPWDE00

PGPWDE01

PGPWDE02

Tom Mc's picture

How many disks do you have on the machine?

If I'm understanding this, I would consider decryption of all disks/drives.  I wouldn't uninstrument anything before doing complete decryption of the machine, and verifying this with the command line usase.  Complete decryption will normally include uninstrumentation.

When you consider your issue resolved, please click Mark As Solution on the most helpful response.

Search the Knowledge Base &

KrisButler's picture

I plugged (slaved) the non working disk onto a working pgp workstation. Using the command line, I used the --enum and status commands to select the faulty disk and ensure i decrypted the correct disk.

The decryption process worked- confirmed by typing status after decryption. I then rebooted but still no joy.

 

I then managed to get symantec contact/support details from a colleague. I logged a call about 1hr ago and had a call from a support analyst. He recommended using testdisk/photorec to scan the partition that was showing as RAW.

now... what I have while this scan is running (using photorec) is 3 files currently found on the faulty partition:

 

1x .swf file @ 2.6gb

1x gpg encrypted file @ 10.8gb

1x pcap file @11.12gb

 

scan is still running, but is this good/bad or just a red herring?

sorry if the post is rambling a bit- a little stressed currently as I have work to do (most of which was on this partition that is faulty).

One thing i haven't done is do anything further to the drive/partition that is faulty - just incase i make it worse

Tom Mc's picture

Please follow through with tech support on this.

When you consider your issue resolved, please click Mark As Solution on the most helpful response.

Search the Knowledge Base &

PGP_Ben's picture

Please make sure that you upgrade all your PGP Desktop clients to version 10.2.1 MP5 or newer if you wish to prevent this problem from happening in the future. Symantec Engineering identified a problem on prior versions that leaves it succeptible to this type of corruption when adding multiple users to a secondary drive and then decrypting that system.

If/when you consider your issue resolved, please click Mark As Solution on the most helpful response.