I've run into this problem a few times over tha past couple weeks. We will have a machine (xp) that is performing constant reboots. Unfortunately despite KB73714, we are not able to get into safe mode to try and fix windows. So the tech will load up eetech (version 184.108.40.2066 for both eetech and the eepc version), authenticate with the .xml file and authorize with the code of the day which both show as successful. They verify that the key is valid by checking the workspace, loading it from disk and using the key against it and it checks out fine. Once they've verified the key is correct they try to open the A43 file manager to check the contents of the drive or move the contents to a backup but the drive displays as if it is still encrypted. They see the volume name (System volume: C:) but when they click on it, nothing appears in the viewer window and there is no drop down for the drive. It's as if the drive has not been authenticated, despite it having been performed and eetech is still up and authorized/authenticated.
Typically what happens next is the tech will try to initiate a "remove ee" which will fail, followed by a force decrypt which also fails and then the drive is pretty much unworkable (which is usually when I hear about it). Fortunately we have one on deck that has not had anything else done to it (other than the above steps).
Has anyone seen/fixed this issue before?
If the disk information has been broken, you won't be able to mount the drive - that's a test to add into your process tree. You need to differentiate between EEPC issues and Windows issues - if EEPC works and Windows is broken, then you don't need the XML file, you should be authenticating to PBFS directly.
I imagine the times it does not work, the disk information is broken and the force decrypt is using the wrong values. That's the most common mistake.
How would I determine if the disk information is broken? I had the person check the disk info in eetech and it seemed legit to me, saw the type (ntfs) as well as the drive letter and starting sector (2048) it was shown as bootable as well. As far as I can tell with eetech the drive info looks ok.
I had him try to run a chkdsk from the winpe 3.0 after authenticating and he stated he received:
"Unable to determine volume version and state. chkdsk aborted"
The problem seems to be that if it is not an encryption issue (which it doesn't seem to be), we can't get into safe mode (as mentioned above we cannot get into it) to fix windows, and we can't get it to boot up in regular windows mode because the machine immediately reboots on the windows splash screen. We also can't browse the file system in eetech to maybe fix it from there (or backup the data). So we're kind of stuck.
I'm worried that if we try to decrypt the drive and error out, I'll end up with another unusable drive, and end up having to format it and lose the data.
Also, preboot is not enabled on this machine (yes I know the risks, etc.)
I just wish I knew what was causing this.on 6/13/13 2:22:29 PM CDT
as you say, check it in EETech - it will tell you if it's valid or not. If you have all the region information etc and the crypto details then it should work fine.
I'm admittedly nervous about doing this, we had one yesterday with very similar issues, key/code show correct info, workspace confirms, yet we can't see any info in the file manager. We try to decrypt and it errors out and once this happens, even a force decrypt won't get the drive in a working state (it errors out as well). We end up with a raw disk with no useable data.
I just wasn't sure if this was as common as we are seeing lately.
Unfortunately they couldn't give me any of the error messages at the time on Monday, I will have them try today with this machine and I'll record them and deliver the results. Thanks Safeboot!
I've seen the "blank A43" even though key has been confirmed as correct (via Workspace load first sector of partition and then decrypt in memory) several times. In EEPC 5.x, the Restore EEPC MBR followed by a reboot of WinTech (now called EETech) would usually fix it. If restoring the MBR does not result in visible files in A43, the issue is very likely to be a damaged Master File Table (MFT). You need special software to rebuild the MFT.
Since EETech 6/7 does not (yet) support Restore EEPC, you can do a decyprt (force if necessary) and then restore the (pre-encryption) MBR. Again, if this doesn't make the files visible, the disk's logical structure has been corrupted.