Symptoms:
At boot logon, after signing in the end user received 0x000000a1. After attempting to use Challenge/Response, logging in to key file on USB, or logging in with an alternate user, if we continue to receive this error
NOTE: Please not it is possible to produce this error using v4 boot logon with a functioning SED. We have not developed v4 to support many SED drives, and is best to suggest to the customer to use v5 before proceeding.
Error 0xf unable to find master pin comes when attempting to deactivate using SDRecovery or HWEMNGR.
Action:
When receiving 0x000000a1, its best first to attempt to deactivate the disk using WinPE to boot the system, and attempt to deactivate using SDRecovery. Often deactivating the disk, and allowing the customer to re-install and reactivate will allow the system to work again.
If you encounter 0xf we need to confirm what the issue is. Obtain a copy of the SDRecovery.log and look for the following in the log. [2015-01-21 11:36:41.565] [2756:1396] DBG WmTcgProtocol::StartSession(0000020500000001, 0000000000000000)...
[2015-01-21 11:36:41.581] [2756:1396] DBG WmMediaImpl::PlatformSleep...
[2015-01-21 11:36:41.612] [2756:1396] DBG WmMediaImpl::PlatformSleep...
[2015-01-21 11:36:41.643] [2756:1396] DBG WmTcgProtocol::Exchange: 'TPer malfunction' (0xf).
This tells us that the issue is with the hard disk. This can happen due to physical damage, or a problem with the firmware.
If we do not see this, scoll down to Action2 for further instruction.
Action:
The customer needs to engage the device manufacturer for data recovery, and/or have the disk replaced. Before they can do this, we must obtain the hardware pins for the customer. Have then send us the hardware encryption data, and the password for the key file.
From the software drive, obtain the hwemngr internal tool and run the following command. Please not this must be run against a system with an SED.
hwemngr 0 --sedpin -k [hwe key file]
You can then enter the password, and the command will output the data like so.
SID: (0x20 bytes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Admin1(lockingSP): (0x20 bytes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
User1(lockingSP): (0x20 bytes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
User2(lockingSP): (0x20 bytes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SN: (0x20 bytes)
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Action2:
If we do not see the example in the SDRecovery.log, we must obtain additional information, to escalate the case to developement
- HWEMNGR internal log. run the following command on the customers system and obtain a copy of the log. hwemngr -lv
- A copy of the SDSpace, and MBR. Using SDRecovery to export these items
- A copy of the preboot logs.