Bug Report: BitLocker Drive Default Shell Verb Not Resetting After Command-Line Lock and GUI Unlock

Product/Component: Windows 11 (File Explorer / BitLocker Shell Extension)

Version: Windows 11 (Applicable to modern versions, e.g., 22H2, 23H2)

Severity: Medium (Functional inconsistency in user experience/UI state management)

1. Summary

When a BitLocker-encrypted data drive is manually locked using the manage-bde -lock command after it was previously unlocked, the File Explorer Shell Extension fails to correctly update the drive's default double-click action (shell verb) upon subsequent successful GUI (Graphical User Interface) unlock.

The default action remains stuck on the "Unlock Drive" verb, even though the drive is fully accessible, instead of reverting to the correct default action, "Open."

2. Steps to Reproduce

1. Ensure a fixed data drive (e.g., E:) is encrypted with BitLocker and is currently in the Unlocked state.
2. Open an Elevated Command Prompt or PowerShell window.
3. Execute the command to manually lock the drive: DOS

      manage-bde -lock E:
   

   (Replace E: with the appropriate drive letter.)
4. Verify that the drive now shows the correct Locked BitLocker icon (yellow padlock) in File Explorer.
5. Unlock the drive via the File Explorer GUI (double-click the drive icon and enter the password/key).
6. Verify that the drive is now accessible and shows the correct Unlocked icon.
7. Right-click the drive and check the top/default action.

3. Expected Result

After the successful unlock (Step 6), the drive's default double-click action and the top-most right-click menu action should revert to the standard "Open" action, allowing the user to browse the drive contents with a double-click.

4. Actual Result (The Bug)

After the successful unlock (Step 6), the drive's default double-click action remains set to the "Unlock Drive" action, or a related BitLocker verb.

• Double-clicking the drive attempts to re-run the unlock process, often resulting in a prompt saying the drive is "already unlocked" or similar error, rather than opening the drive content.
• The correct "Open" action is still present in the right-click menu, but it is not set as the default (double-click) action.

5. Root Cause Observation

This issue suggests an asymmetry in how the BitLocker Shell Extension handles state transitions:

• Initial Unlock (e.g., System Startup): Successfully transitions from Locked → Unlocked, and correctly sets the default shell verb to "Open".
• Command-Line Lock: The forced lock (manage-bde -lock) successfully changes the underlying BitLocker state but appears to put the Shell Extension into an inconsistent UI context.
• Subsequent GUI Unlock: The unlock operation successfully changes the drive status back to Unlocked but fails to re-run the crucial logic that switches the default shell verb back from "Unlock Drive" to "Open".