We use Bitlocker across our organization and generally don't have any problems.  However, I have one user with a Surface Pro 3 that has been getting prompted for his Bitlocker key after he docks at his desk.  The system has been working normally otherwise.  There is nothing abnormal about the docking station and the only thing plugged into the dock currently is a network cable and the power cable.  I've found the Bitlocker-API logs within Applications and Services Logs\Microsoft\Windows\Bitlocker-API.  This will show me an Event ID 805 showing that the key was entered and the computer recovered, but I'm hoping to find a log somewhere that gives an indication on why it was tripped in the first place.

Does anyone know of this type of log, or a trail to why the bBtlocker key is being requested?

Has anyone had problems with Bitlocker prompting for the key after docking without any external drives?

Hi Ryan_Anderson,

The following events will trigger the machine to get into recovery mode.

Device Lockout feature in Windows 8, Windows RT, Windows 8.1 andWindows RT 8.1. On PCs that use either BitLocker or Device Encryption when an attack is detected the device will immediately reboot and enter into BitLocker recovery mode. To take advantage of this functionality Administrators can set the Interactive logon: Machine account lockout threshold Group Policy setting located in \Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options in the Local Group Policy Editor, or use the MaxFailedPasswordAttempts policy of Exchange ActiveSync (also configurable through Windows Intune), to limit the number of failed password attempts before the device goes into Device Lockout.
Changing the boot order to boot another drive in advance of the hard drive.
Having the CD or DVD drive before the hard drive in the BIOS boot order and then inserting or removing a CD or DVD.
Failing to boot from a network drive before booting from the hard drive.
Docking or undocking a portable computer. In some instances (depending on the computer manufacturer and the BIOS), the docking condition of the portable computer is part of the system measurement and must be consistent to validate the system status and unlock BitLocker. This means that if a portable computer is connected to its docking station when BitLocker is turned on, then it might also need to be connected to the docking station when it is unlocked. Conversely, if a portable computer is not connected to its docking station when BitLocker is turned on, then it might need to be disconnected from the docking station when it is unlocked.
Changes to the NTFS partition table on the disk including creating, deleting, or resizing a primary partition.
Entering the personal identification number (PIN) incorrectly too many times so that the anti-hammering logic of the TPM is activated. Anti-hammering logic is software or hardware methods that increase the difficulty and cost of a brute force attack on a PIN by not accepting PIN entries until after a certain amount of time has passed.
Turning off the support for reading the USB device in the pre-boot environment from the BIOS or UEFI firmware if you are using USB-based keys instead of a TPM.
Turning off, disabling, deactivating, or clearing the TPM.
Upgrading critical early startup components, such as a BIOS or UEFI firmware upgrade, causing the related boot measurements to change.
Forgetting the PIN when PIN authentication has been enabled.
Updating option ROM firmware.
Upgrading TPM firmware.
Adding or removing hardware; for example, inserting a new card in the computer, including some PCMIA wireless cards.
Removing, inserting, or completely depleting the charge on a smart battery on a portable computer.
Changes to the master boot record on the disk.
Changes to the boot manager on the disk.
Hiding the TPM from the operating system. Some BIOS or UEFI settings can be used to prevent the enumeration of the TPM to the operating system. When implemented, this option can make the TPM hidden from the operating system. When the TPM is hidden, BIOS and UEFI secure startup are disabled, and the TPM does not respond to commands from any software.

Using a different keyboard that does not correctly enter the PIN or whose keyboard map does not match the keyboard map assumed by the pre-boot environment. This can prevent the entry of enhanced PINs.
Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile. For example, including PCR[1] would result in BitLocker measuring most changes to BIOS settings, causing BitLocker to enter recovery mode even when non-boot critical BIOS settings change.
Note
Some computers have BIOS settings that skip measurements to certain PCRs, such as PCR[2]. Changing this setting in the BIOS would cause BitLocker to enter recovery mode because the PCR measurement will be different.
  Moving the BitLocker-protected drive into a new computer.
Upgrading the motherboard to a new one with a new TPM.
Losing the USB flash drive containing the startup key when startup key authentication has been enabled.
Failing the TPM self-test.
Having a BIOS, UEFI firmware, or an option ROM component that is not compliant with the relevant Trusted Computing Group standards for a client computer. For example, a non-compliant implementation may record volatile data (such as time) in the TPM measurements, causing different measurements on each startup and causing BitLocker to start in recovery mode.
Changing the usage authorization for the storage root key of the TPM to a non-zero value.

Note
The BitLocker TPM initialization process sets the usage authorization value to zero, so another user or process must explicitly have changed this value.
Disabling the code integrity check or enabling test signing on Windows Boot Manager (Bootmgr).
Pressing the F8 or F10 key during the boot process.
Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards.
Using a BIOS hot key during the boot process to change the boot order to something other than the hard drive.

Here is a link for reference:

BitLocker Recovery Guide

https://technet.microsoft.com/en-us/library/dn383583.aspx?f=255&MSPPError=-2147217396

Best regards

Hi Ryan_Anderson,

The following events will trigger the machine to get into recovery mode. We could get the Bitlocker log here :Applications and Services Logs\Microsoft\Windows\BitLocker-API\Management or \Windows logs\System . But I am afraid the triggers won`t be recorded here.

Device Lockout feature in Windows 8, Windows RT, Windows 8.1 andWindows RT 8.1. On PCs that use either BitLocker or Device Encryption when an attack is detected the device will immediately reboot and enter into BitLocker recovery mode. To take advantage of this functionality Administrators can set the Interactive logon: Machine account lockout threshold Group Policy setting located in \Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options in the Local Group Policy Editor, or use the MaxFailedPasswordAttempts policy of Exchange ActiveSync (also configurable through Windows Intune), to limit the number of failed password attempts before the device goes into Device Lockout.
Changing the boot order to boot another drive in advance of the hard drive.
Having the CD or DVD drive before the hard drive in the BIOS boot order and then inserting or removing a CD or DVD.
Failing to boot from a network drive before booting from the hard drive.
Docking or undocking a portable computer. In some instances (depending on the computer manufacturer and the BIOS), the docking condition of the portable computer is part of the system measurement and must be consistent to validate the system status and unlock BitLocker. This means that if a portable computer is connected to its docking station when BitLocker is turned on, then it might also need to be connected to the docking station when it is unlocked. Conversely, if a portable computer is not connected to its docking station when BitLocker is turned on, then it might need to be disconnected from the docking station when it is unlocked.
Changes to the NTFS partition table on the disk including creating, deleting, or resizing a primary partition.
Entering the personal identification number (PIN) incorrectly too many times so that the anti-hammering logic of the TPM is activated. Anti-hammering logic is software or hardware methods that increase the difficulty and cost of a brute force attack on a PIN by not accepting PIN entries until after a certain amount of time has passed.
Turning off the support for reading the USB device in the pre-boot environment from the BIOS or UEFI firmware if you are using USB-based keys instead of a TPM.
Turning off, disabling, deactivating, or clearing the TPM.
Upgrading critical early startup components, such as a BIOS or UEFI firmware upgrade, causing the related boot measurements to change.
Forgetting the PIN when PIN authentication has been enabled.
Updating option ROM firmware.
Upgrading TPM firmware.
Adding or removing hardware; for example, inserting a new card in the computer, including some PCMIA wireless cards.
Removing, inserting, or completely depleting the charge on a smart battery on a portable computer.
Changes to the master boot record on the disk.
Changes to the boot manager on the disk.
Hiding the TPM from the operating system. Some BIOS or UEFI settings can be used to prevent the enumeration of the TPM to the operating system. When implemented, this option can make the TPM hidden from the operating system. When the TPM is hidden, BIOS and UEFI secure startup are disabled, and the TPM does not respond to commands from any software.

Using a different keyboard that does not correctly enter the PIN or whose keyboard map does not match the keyboard map assumed by the pre-boot environment. This can prevent the entry of enhanced PINs.
Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile. For example, including PCR[1] would result in BitLocker measuring most changes to BIOS settings, causing BitLocker to enter recovery mode even when non-boot critical BIOS settings change.
Note
Some computers have BIOS settings that skip measurements to certain PCRs, such as PCR[2]. Changing this setting in the BIOS would cause BitLocker to enter recovery mode because the PCR measurement will be different.
  Moving the BitLocker-protected drive into a new computer.
Upgrading the motherboard to a new one with a new TPM.
Losing the USB flash drive containing the startup key when startup key authentication has been enabled.
Failing the TPM self-test.
Having a BIOS, UEFI firmware, or an option ROM component that is not compliant with the relevant Trusted Computing Group standards for a client computer. For example, a non-compliant implementation may record volatile data (such as time) in the TPM measurements, causing different measurements on each startup and causing BitLocker to start in recovery mode.
Changing the usage authorization for the storage root key of the TPM to a non-zero value.

Note
The BitLocker TPM initialization process sets the usage authorization value to zero, so another user or process must explicitly have changed this value.
Disabling the code integrity check or enabling test signing on Windows Boot Manager (Bootmgr).
Pressing the F8 or F10 key during the boot process.
Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards.
Using a BIOS hot key during the boot process to change the boot order to something other than the hard drive.

Here is a link for reference:

BitLocker Recovery Guide

https://technet.microsoft.com/en-us/library/dn383583.aspx?f=255&MSPPError=-2147217396

Best regards

Go into the BIOS and select the HDD as the primary boot device. 
If your boot order changes when docked vs undocked this can basically cause BitLocker to decide that the hard drive is not connected to the same hardware and will require the Recovery Key. Changing the BIOS boot order to always boot from the system hard disk should help prevent the prompting for the recovery key.