| Previous | Next |
| ERROR_BCD_NOT_ALL_ENTRIES_IMPORTED | ERROR_QUERY_STORAGE_ERROR |
ERROR_BCD_NOT_ALL_ENTRIES_SYNCHRONIZED
ERROR_BCD_NOT_ALL_ENTRIES_SYNCHRONIZED — 0x80390003
A productive investigation starts at partial BCD-to-firmware synchronization. The status means that Windows updated only part of the boot-entry relationship between the BCD store and firmware environment.
Meaning in the subsystem
BCD repair should begin with an export and an inventory of both BCD objects and firmware entries. Object GUIDs, EFI System Partition paths, referenced device elements, firmware NVRAM capacity, and boot order must be correlated; editing one representation in isolation can create a second inconsistency.
Do not collapse this result into a nearby status. This is not merely a BCD file-write error; the incomplete boundary includes firmware/NVRAM representation. Compare lifecycle, identity, caller, and first API.
Minimum useful evidence
| Preserve before changing state | Diagnostic value |
|---|---|
| UEFI/BIOS mode, BCD object GUIDs, firmware NVRAM boot entries, and display order | Tests whether the first boundary moves. |
| BCDBoot/BCDEdit operation, EFI System Partition identity, free space, and mount state | Pins evidence to one attempt. |
| Firmware write permissions, NVRAM capacity, secure-boot state, and vendor firmware events | Separates contract failure from environment. |
| Before/after output from firmware and BCD enumeration | Creates a stable before/after control. |
Identifiers, timestamps, versions, counts, state flags, hashes, and redacted paths normally provide enough correlation. Keep credentials, private keys, message bodies, recovery material, and personal data out of routine incident logs.
Isolate the responsible condition
- Synchronize a backed-up test store to the correct EFI System Partition; use a disposable or backed-up environment when the comparison changes boot, security, device, queue, or encryption state.
- Remove stale duplicate firmware entries in a controlled maintenance window; retain one negative control so that a broad workaround is not mistaken for a root-cause correction.
- Compare firmware order and BCD display order without assuming they are identical models; keep every other input fixed and record the first event that differs from the failing run.
A retry becomes evidence only when one controlled variable changes. In this case, if the same operation later succeeds unchanged, preserve that fact but continue checking timing, object generation, service restart, cache replacement, or policy refresh; transient success does not explain the earlier boundary.
Avoid the common misdiagnosis
The following decision points keep the investigation tied to the returning operation:
| Observed result | Interpretation |
|---|---|
| The minimal or known-good comparison succeeds | The control works; inspect production-specific state. |
| The control fails at the same first operation | The control also fails; inspect host/provider evidence. |
| A new HRESULT marks another boundary | this boundary moved; diagnose the new status separately rather than treating it as confirmation that the entire operation is fixed. |
Regression proof
Repair the failed contract rather than the surrounding system: Restore writable firmware/ESP state, clean stale entries if necessary, and rerun the supported BCDBoot/synchronization workflow. Preserve the pre-change configuration or trace.
Close the incident only when the intended Windows Boot Manager entry exists once, points to the correct ESP, survives reboot, and firmware order remains stable. Repeat under the original identity and state. A different environment is comparison, not proof.
Technical references
These references define the HRESULT family and subsystem contract used above:
- Microsoft Open Specifications: HRESULT values.
- Microsoft: boot options in Windows.
- Microsoft: BCDEdit command-line options.
- Microsoft: BcdStore class.
Looking for a different code? Search another status or error code.