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.
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.
did you record the error messages by any chance?
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.