How to disable to bitlocker?

• Press the Windows key on your keyboard and open "Control Panel" by searching for it.
• Now select "Device Encryption" under "Control Panel" to open "Bitlocker" settings.
• Now, click on the "turn off auto-unlock" option.

If Bitlocker encryption is enabled, the storage location of the content present in the encrypted drive of the imaging computer cannot be identified. Hence, decrypting the contents of the bitlocker encrypted drive is essential for efficient imaging.

You can use the following methods to remove bitlocker encryption in Windows 10, Windows 11, and all other Windows operating systems:

Ensure that you have logged onto Admin user account to turn off bitlocker encryption. Follow the steps given below to turn off bitlocker encryption using Command Prompt.

Ensure that you have administrator credentials to remove bitlocker encryption. Follow the steps given below to remove bitlocker encryption in GUI mode,

You can ensure if the BitLocker encryption is removed by checking if the Bitlocker lock icon is removed in the particular drive and by accessing the particular drive. You can repeat the same steps to disable Bitllocker Encryption in other drives.

To disable Bitlocker encryption in Windows Powershell mode, Windows Power shell must be installed in your system. If not download & install proper Windows Powershell version from Microsoft website. Also check the Powershell System requirements before proceeding installation.

Note: If the partition with the operating system contains any automatic unlocking keys, the cmdlet to disable bitlocker encryption will not work. You can use the Clear-BitLockerAutoUnlock cmdlet in Powershell window to remove all automatic unlocking keys to disable BitLocker for the partition.

Press Windows Start button. Type bitlocker. Click Manage BitLocker to enter the BitLocker Drive Encryption menu. Select Turn off BitLocker to proceed with decryption.

BitLocker drive encryption provides offline data and operating system protection by ensuring that the drive is not tampered with while the operating system is offline. BitLocker drive encryption uses a TPM, either discrete or firmware, that supports the Static Root of Trust Measurement as defined by the Trusted Computing Group.

BitLocker drive encryption uses a system partition separate from the Windows partition. The BitLocker system partition must meet the following requirements.

For more information see System and utility partitions, and Hard drives and partitions.

BitLocker automatic device encryption uses BitLocker drive encryption technology to automatically encrypt internal drives after the user completes the Out Of Box Experience (OOBE) on Modern Standby or HSTI-compliant hardware.

BitLocker automatic device encryption is enabled when:

The following tests must pass before Windows 10 will enable Automatic BitLocker device encryption. If you want to create hardware that supports this capability, you must verify that your device passes these tests.

When the requirements as listed above are met, System Information indicates the system supports BitLocker automatic device encryption. This functionality is available in Windows 10, version 1703 or after. Here's how to check System Information.

In addition to running HLK tests, OEMs need to test firmware updates with BitLocker turned on. To prevent devices from starting recovery unnecessarily, follow these guidelines to apply firmware updates:

The firmware update should require the device to suspend Bitlocker only for a short time, and the device should restart as soon as possible. BitLocker can be suspended programmatically just before shutting down by using the DisableKeyProtectors method in Windows Management Instrumentation (WMI).

This System Information status in Device Encryption Support means Windows detected at least one potential external DMA capable bus or device that may expose a DMA threat.

To resolve this issue, contact the IHV(s) to determine if this device has no external DMA ports. If confirmed by the IHVs that the bus or device only has internal DMA, then the OEM can add this to the allowed list.

To add a bus or device to the allowed list, you need to add a value to a registry key. To do this, you need to take the ownership of the AllowedBuses registry key first. Follow these steps:

Then, under the AllowedBuses key, add string (REG_SZ) name/value pairs for each flagged DMA capable bus that is determined to be safe:

Ensure the IDs match the output from the HLK test. For example, if you have a safe device with a friendly name of “Contoso PCI Express Root Port”, vendor ID 1022 and Device ID 157C, you would create a Registry entry named Contoso PCI Express Root Port as REG_SZ data type in: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DmaSecurity\AllowedBuses

Where the value = "PCI\VEN_1022&DEV_157C"

OEMs can choose to disable device encryption and instead implement their own encryption technology on a device. To disable BitLocker automatic device encryption, you can use an Unattend file and set PreventDeviceEncryption to True.

Alternately, you can update the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker registry key:

Value: PreventDeviceEncryption equal to True (1).

Triage is much simpler when you know the following pieces of information about the device under test:

This info is recommended but not required to perform triage.

BitLocker HLK issues are usually related to one of the following: misinterpreting test results, or PCR7 binding issues.

An HLK test consists of multiple test steps. Some test steps may fail without impacting the success/failure of the overall test. See here for more information about interpreting the results page. If some test steps have failed but the overall test passes (as indicated by a green check next to the test name), stop here. The test ran successfully and there is no more action needed on your part.

Triaging steps:

A common BitLocker issue that is specific to the two PCR7 tests is a failure to bind to PCR7.

Triaging steps:

BitLocker expects certain static root of trust measurements static root of trust measurements in PCR7, and any variation in these measurements often prohibits binding to PCR7. The following values should be measured (in order, and without extraneous measurements in between) into PCR7:

Common issues with the measured boot log:

Some measured boot issues, such as running with UEFI debug mode on, may be remedied by the tester. Other issues may require an errata, in which case you should reach out to the Microsoft Support team for guidance.