Anavem
Languagefr
WarningBitLocker

0x8031000A

FVE_E_IN_REBOOT_PENDING

The drive encryption operation cannot be completed because a restart is required.

Hex code

0x8031000A

Decimal

-2144272374

Severity

Warning

Category

BitLocker

Description

FVE_E_IN_REBOOT_PENDING (hex code 0x8031000A, decimal -2144272374) is a Windows warning-level error code in the BitLocker Errors family. Microsoft surfaces this code through the Win32 API, the Common Language Runtime, the kernel, the event log, PowerShell, command-line tools (sfc, dism, gpupdate, sc), and Windows-side applications such as Outlook, Teams, Office, and System Center.

The drive encryption operation cannot be completed because a restart is required.

This page documents what triggers 0x8031000A, the most common scenarios where it appears, the likely root causes, and a step-by-step troubleshooting workflow you can run against affected endpoints. It is intended for system administrators, MSP technicians, helpdesk engineers, and anyone diagnosing Windows behavior in a managed environment.

In-depth explanation

This is a warning-severity code. The operation did not necessarily fail; Windows may have completed it with side effects, conflicts, or a state that requires user attention. It is normally safe to retry, but should still be logged so repeated occurrences can be triaged.

It is part of the FVE / BitLocker error space. It surfaces in manage-bde, the BitLocker recovery flow, or the Microsoft-Windows-BitLocker-API event log.

The code can be looked up programmatically in PowerShell with [ComponentModel.Win32Exception]::new(-2144272374).Message (for Win32 / NTSTATUS codes that map cleanly), or with net helpmsg <decimal> for the legacy decimal range. For HRESULT-style codes, decode the facility and code with err.exe from the SDK or via the WinDbg !error command.

Common causes

  • TPM owner password mismatch or PCR values changed (BIOS / Secure Boot toggled).
  • Recovery key not escrowed in AD / Azure AD / Intune — retrieve from MyAccount portal if user-protector exists.
  • Boot configuration (BCD) modified by an OS install or partition manager.
  • Failing system disk — read errors during decryption.
  • Group Policy mismatch (encryption method, recovery options) causing the volume to refuse to decrypt.

Troubleshooting steps

  1. Run manage-bde -status to identify the protector type and conversion state of the volume.
  2. Retrieve the recovery key from AD (Get-ADComputer -Properties msFVE-RecoveryInformation), Azure AD (Devices > BitLocker keys), or Intune.
  3. If TPM-related: clear the TPM (tpm.msc), boot once successfully, then re-enable BitLocker so a fresh PCR seal is taken.
  4. Check Secure Boot state and BIOS settings — toggling them invalidates the PCR seal and forces recovery.
  5. For decryption errors, run chkdsk /f /r on the affected volume — a failing disk is a common root cause.

Decode in PowerShell

# Decode 0x8031000A (-2144272374) in PowerShell
[ComponentModel.Win32Exception]::new(-2144272374).Message

# Or via WinDbg / err.exe (Windows SDK)
# err 0x8031000A

# Or net helpmsg (legacy decimal range only)
# net helpmsg <decimal>

Frequently asked questions

What does the Windows error code 0x8031000A mean?
It is the Win32 / NTSTATUS code FVE_E_IN_REBOOT_PENDING (decimal -2144272374). The drive encryption operation cannot be completed because a restart is required.
How do I decode 0x8031000A in PowerShell?
Run [ComponentModel.Win32Exception]::new(-2144272374).Message in any PowerShell session. For HRESULT-style codes, use err.exe from the Windows SDK or the WinDbg !error command.
Where does Windows typically log this error?
It depends on the originating subsystem (Windows Update → %WinDir%\WindowsUpdate.log; AD/Kerberos → Security event log on the DC; BSOD → minidump under C:\Windows\Minidump; MSI → %TEMP%\msi*.log; WMI → Microsoft-Windows-WMI-Activity). Always cross-reference the timestamp and module name with the Application and System event logs.
Is this code recoverable?
Yes — this code is informational or warning-level. The operation can normally be retried after addressing the condition described in the summary.
Should I open a Microsoft support case for this?
Open a case if the error reproduces after applying the troubleshooting steps, particularly if it blocks production workloads, occurs across multiple endpoints, or is associated with a security boundary (BitLocker recovery, Kerberos failure, DCOM hardening, SmartScreen / WDAC). Have a fresh CBS log, minidump, or Get-WinEvent export ready before opening the case.