Correct the GPT type of an existing FAT32 EFI System Partition

On a UEFI/GPT Windows disk, the existing FAT32 partition can still contain \EFI\Microsoft\Boot\bootmgfw.efi and a BCD store while its GPT partition-type field identifies it as a basic-data or other non-ESP partition. Firmware, Windows boot tools, or Windows Recovery Environment may then fail to discover or use it as the EFI System Partition. bcdedit can report that it cannot open the system store even though the store opens when its full path is supplied.

This writeup changes only the GPT type of a proven, existing FAT32 Windows ESP. It does not create, resize, format, delete, or reconstruct a partition. A missing, deleted, formatted, non-FAT32, or unreadable ESP is a different condition covered by FIX-029.

There is no Windows error code that uniquely means the existing ESP has the wrong GPT type. The type must be read from the partition table and compared with the Microsoft ESP type GUID.

In WinPE, mountvol S: /s can itself return The system cannot find the file specified even when the ESP exists. Microsoft documents that limitation. Use DiskPart to assign the temporary letter in this procedure.

Use this procedure only when all of the following have been demonstrated:

The verified Windows installation is on a GPT disk.
A partition on that same disk is FAT32.
The partition contains the Windows EFI tree, including \EFI\Microsoft\Boot\bootmgfw.efi.
detail partition reports a type other than the ESP GUID c12a7328-f81f-11d2-ba4b-00a0c93ec93b.
The candidate can be distinguished from every other FAT32 partition and every other ESP.
The disk and FAT32 filesystem are consistently readable.

The strongest confirmation is that the explicit BCD path opens, its intended loader maps to the verified Windows installation, automatic system-store discovery fails, and changing only the GPT type restores startup.

Do not use this procedure when the ESP is absent, deleted, formatted, non-FAT32, unreadable, or contains no identifiable Windows EFI tree. Do not use it when the partition already has the ESP type, when several plausible ESPs cannot be mapped to their operating systems, or when the only problem is insufficient free space. Update errors such as 0x800f0922 with ESP free-space evidence belong to the deferred capacity branch; this writeup performs no resizing.

Also stop for an MBR disk, dynamic disk, Storage Spaces layout, an unresolved multiboot configuration, or a specialist RAID/VMD/enterprise storage path.

The exact Windows build, the tool or event that changed the GPT type, and whether the incorrect type was ever intentional may remain unknown. The target disk and partition, GPT status, FAT32 filesystem, existing EFI contents, original partition-type GUID, and relationship to the verified Windows installation may not remain unknown.

Before you start:

Current Windows 10/11 installation media or another trusted Windows Recovery Environment
Administrator Command Prompt access
A stable, consistently detected GPT Windows disk
A writable backup location on the verified Windows volume or an external drive
The existing ESP contents and original GPT type recorded before any change
Enough free space to preserve the complete existing EFI directory
Exactly one proven target partition

If Windows still starts, use recovery media for the type change so the FAT32 volume is not being used by the running installation. The firmware mode does not need to be supplied by the reader; the GPT disk, FAT32 system partition, and EFI file tree establish the installed layout.

Boot trusted Windows installation media, select Repair your computer > Troubleshoot > Advanced options > Command Prompt, and disconnect unrelated removable storage. Do not assume that Windows is C: or that the ESP is already mounted. In the commands below, W: means the detected Windows volume and S: means the detected existing ESP.

Record the complete startup screen, code, named file, current firmware boot entry, and recent partition-related change if known. Do not run bcdboot, bootrec, set id, or a formatting command before completing the detection and backup steps.

Do not run set id on a partition identified only by size or FAT32.
Do not use override, noerr, a DiskPart script with unresolved variables, or a copied disk number.
Do not format, delete, create, shrink, extend, clean, initialize, or convert any disk or partition.
Do not mark a GPT partition active; active is an MBR/BIOS concept.
Do not use bootrec /fixmbr, bootrec /fixboot, or /f ALL for this proven UEFI/GPT condition.
Do not erase other vendors' EFI directories or assume they are stale.
Do not use BCDBoot /c unless a separate, evidence-backed procedure deliberately discards the old settings.
Do not use a current new-deployment ESP size recommendation as proof that a working older ESP is defective.
Do not attempt to resolve 0x800f0922 or an ESP free-space failure by repartitioning under this article.

Stop before writing if the target partition, original GUID, Windows-to-ESP relationship, or multiboot ownership is uncertain. Stop if the disk disappears, the FAT32 filesystem is unreadable, another plausible ESP exists, DiskPart cannot lock the volume without override, the partition is already correctly typed, or any proposed next step requires formatting, creation, deletion, resizing, conversion, or a forced dismount.

Check the cause

At Command Prompt, inventory disks and volumes:
```
diskpart
list disk
list volume
```
In list disk, confirm that the verified Windows disk has an asterisk in the Gpt column. If it does not, exit this procedure.
Select the detected Windows volume, display its mapping, and assign W if it has no usable letter:
```
select volume <Windows-volume-number>
detail volume
assign letter=W
exit
```
If W: is already in use, choose another unused letter and replace W: in every command.
Verify the installation rather than relying on a label or volume size:
```
dir W:\Windows\System32\Config\SYSTEM
dir W:\Windows\System32\Config\SOFTWARE
dir W:\Windows\System32\winload.efi
```
Stop if these checks do not identify the expected installation.

Reopen DiskPart, select the verified Windows disk, and inspect its partitions:

diskpart
select disk <Windows-disk-number>
detail disk
list partition
list volume

Correlate the small FAT32 volume with a partition on this exact disk by volume number, size, offset, and detail volume. Then select that partition and inspect it:
```
select partition <candidate-partition-number>
detail partition
assign letter=S
exit
```
Record the complete detail partition output or photograph it. The original type GUID is required for rollback.

Confirm that the candidate is not merely a FAT32 data or manufacturer-tools volume:

dir /a S:\
dir /a S:\EFI
dir /a S:\EFI\Microsoft
dir /a S:\EFI\Microsoft\Boot
dir /a S:\EFI\Microsoft\Boot\bootmgfw.efi
dir /a S:\EFI\Microsoft\Boot\BCD
dir /s /b S:\EFI\*.efi

Interpret the file check:
- If bootmgfw.efi exists and the surrounding Microsoft EFI tree is coherent, continue.
- If the Microsoft directory is missing but other-vendor EFI files are present, stop. Do not convert that partition based only on FAT32.
- If the ESP was deleted, recreated empty, formatted, or is unreadable, stop and use FIX-029 or the filesystem/storage condition.

Inspect the BCD by explicit path:

bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all /v

Interpret the result:
- If the explicit store opens, preserve its complete output. Identify the intended Windows Boot Loader entry rather than assuming {default}. Require path to be \Windows\System32\winload.efi, systemroot to be \Windows, and both device and osdevice to resolve to the verified Windows volume. Correlate the displayed partition with W: by its DiskPart volume identity, not merely by a drive-letter label. This proves that the BCD on this candidate ESP belongs to the verified installation.
- If the explicit store opens but no single loader maps to the verified W:\Windows, stop. Do not retag the partition.
- If the explicit store does not open but the file exists, BCD corruption may coexist with the wrong type and ownership remains provisional.
- If the BCD file is absent, boot files are incomplete and ownership remains provisional; do not claim that the type correction alone is sufficient.
When the store is missing or corrupt, continue only if independent firmware and layout evidence proves that this is the Windows system partition for the verified disk—for example, it is the sole system-partition candidate on that disk, the Microsoft EFI loader tree is coherent, and no second ESP, multiboot loader, or other-vendor ownership remains plausible. Otherwise stop. Even with that independent proof, cap the final confidence at moderate because the BCD could not establish ownership before the write.
Compare the recorded partition type with the required ESP GUID:
```
c12a7328-f81f-11d2-ba4b-00a0c93ec93b
```
Continue only when the current value is different and every other target check passed. A common incorrect value is the Microsoft basic-data GUID ebd0a0a2-b9e5-4433-87c0-68b6b72699c7, but do not assume that value without reading it.

Create the evidence and rollback backup:

md W:\BootRepairBackup
md W:\BootRepairBackup\FIX-033
xcopy S:\EFI W:\BootRepairBackup\FIX-033\EFI-before-type-fix /e /h /i /v
bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all /v > W:\BootRepairBackup\FIX-033\BCD-before-type-fix.txt
copy /y S:\EFI\Microsoft\Boot\BCD W:\BootRepairBackup\FIX-033\BCD.before-type-fix
dir /s /a W:\BootRepairBackup\FIX-033\EFI-before-type-fix

Require XCOPY to complete without an error and confirm that the copied tree contains Microsoft\Boot\bootmgfw.efi. If the BCD is absent or unreadable, the two BCD commands can fail. Record that result; do not manufacture a successful backup claim.

Branch A — The BCD and Windows EFI files are present and readable

Close any command prompt whose current directory is on S:. Return to the recovery command prompt, such as X:\Sources.
Select the already-proven disk and partition again. Do not rely on selection state left from an earlier DiskPart session:
```
diskpart
select disk <Windows-disk-number>
select partition <ESP-partition-number>
detail partition
```
Confirm one final time that the displayed disk number, partition number, size, offset, and original type match the recorded candidate.
Change only the GPT partition-type field:
```
set id=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
```
Do not append override or noerr. Microsoft states that override forces a dismount and invalidates open handles; noerr can allow a script to continue after a failure.

If DiskPart cannot lock or dismount the volume without override, make no other change. Exit DiskPart, restart from clean recovery media, redetect the target, and try once more. If the same lock failure remains, stop.
Verify the new metadata before leaving DiskPart:
```
detail partition
exit
```
The type must now be exactly c12a7328-f81f-11d2-ba4b-00a0c93ec93b.

If the temporary letter was removed during the type change, reassign it to the same proven partition:

diskpart
select disk <Windows-disk-number>
select partition <ESP-partition-number>
assign letter=S
exit

Then confirm that no file contents were changed:

dir /a S:\EFI\Microsoft\Boot\bootmgfw.efi
bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all /v

Do not run BCDBoot when the existing BCD opens and its Windows Boot Manager and loader entries are coherent. Restart and test the metadata-only repair first.

Remove the temporary drive letter before restarting:

diskpart
select disk <Windows-disk-number>
select partition <ESP-partition-number>
remove letter=S
exit

Restart and allow the verified Windows disk to boot.

Branch B — The wrong type is proven and boot files or BCD are also missing or corrupt

Use this branch only after completing the same evidence backup and GPT type correction in Branch A.

Redetect W: and assign S: to the same corrected ESP again:

diskpart
select disk <Windows-disk-number>
select partition <ESP-partition-number>
detail partition
assign letter=S
exit

Verify the BCDBoot source and target immediately before writing:

dir W:\Windows\System32\Config\BCD-Template
dir /a S:\EFI\Microsoft\Boot

Recreate the UEFI boot files from the verified Windows installation:
```
bcdboot W:\Windows /s S: /f UEFI /v
```
/s S: confines the file copy to the selected partition and deliberately avoids creating a firmware NVRAM entry. /f UEFI avoids adding unnecessary BIOS boot files. Do not add /c; it tells BCDBoot to start fresh instead of preserving applicable settings.
Require a success message from BCDBoot. Then inspect the created store explicitly:
```
bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all /v
```

In the Windows Boot Manager entry, confirm:

path                    \EFI\Microsoft\Boot\bootmgfw.efi

In the intended Windows Boot Loader entry, confirm that path is \Windows\System32\winload.efi, systemroot is \Windows, and device and osdevice resolve to the verified Windows installation.
Remove the temporary S: letter with DiskPart and restart.
If Windows boot files are now correct but firmware has no usable Windows Boot Manager entry, stop and use the missing/stale firmware-entry procedure. Do not broaden this article into NVRAM deletion or boot-order repair.

Verify the result

detail partition reports c12a7328-f81f-11d2-ba4b-00a0c93ec93b for the proven ESP.
The partition remains FAT32 and its original non-BCD EFI files remain present.
S:\EFI\Microsoft\Boot\bootmgfw.efi exists when inspected from recovery media.
bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all /v opens without error.
The Windows Boot Manager path is \EFI\Microsoft\Boot\bootmgfw.efi.
The intended Windows loader uses \Windows\System32\winload.efi and points to the verified installation.
The temporary ESP drive letter has been removed.
Windows completes two normal restarts and one cold start.
No unintended firmware entry or boot-order change was made.
Changing only the type restores startup: BP-043/BP-034 wrong-type is confirmed at high confidence.
The explicit BCD opens before and after the type change, but firmware still cannot start it: Inspect the firmware entry, boot order, and loader path. Do not rebuild a readable BCD repeatedly.
BCDBoot succeeds and Windows starts: The wrong type and missing/corrupt boot files coexisted. Record both changes; do not claim the type change alone solved it.
BCDBoot reports Failure when attempting to copy boot files: Recheck W:, S:, write access, free space, filesystem health, and whether the source contains BCD-Template. Do not format the target or keep retrying.
The code changes to one naming winload.efi, a registry hive, or a driver: The ESP is now being reached. Follow the newly displayed file and code rather than continuing partition edits.
mountvol S: /s reports that the file cannot be found in WinPE: Ignore that command as a diagnostic signal; use the DiskPart mapping already established.
The partition is already the correct ESP type: This article has no corrective action. Route to the demonstrated BCD, NVRAM, filesystem, storage, or loader condition.

Undo the change if needed

If the type change makes the configuration worse, boot the same trusted recovery media, detect the same Windows disk and partition again, and preserve the post-change state before restoring anything:

md W:\BootRepairBackup\FIX-033\after
xcopy S:\EFI W:\BootRepairBackup\FIX-033\after\EFI-after-type-fix /e /h /i /v

Restore the exact original type recorded in the diagnosis notes:

diskpart
select disk <Windows-disk-number>
select partition <ESP-partition-number>
detail partition
set id=<original-recorded-GPT-type-GUID>
detail partition
exit

This rollback is best-effort. Do not use override. If DiskPart cannot lock the now-recognized ESP without override, make no further partition-type change, retain the recovery media and backups, and stop for a controlled offline recovery path. Restoring the original wrong type can restore the original boot failure; it is an evidence-preserving reversal, not the expected final repair.

If BCDBoot replaced a readable store and required custom or multiboot entries were lost, preserve the replacement and then restore only the saved BCD file from WinPE:

copy /y S:\EFI\Microsoft\Boot\BCD W:\BootRepairBackup\FIX-033\after\BCD.after-bcdboot
copy /y W:\BootRepairBackup\FIX-033\BCD.before-type-fix S:\EFI\Microsoft\Boot\BCD

Do not copy the entire old EFI tree back blindly. Firmware-entry changes are not reversed by restoring files, which is why this procedure uses BCDBoot /s and leaves NVRAM repair to a separate writeup.

Preparation, backups and recovery reference

Sources and evidence

Case reports describe observed outcomes. They do not establish a measured success rate or independent laboratory reproduction.

UEFI/GPT-based hard drive partitions — documentation
Windows 11 Stopcode: 0xc000021a - Microsoft Q&A — reported case
No Bootable Device after converting from MBR to GPT — reported case
Can't boot Windows 10 — reported case
Windows 10 BCDEdit "The system cannot find the file ... — reported case
Windows 11 version 25H2 fails to install: we couldn't update the system reserved partition — reported case

Windows error codes and exact messages

Displayed identifier	Windows name or exact message	When it can apply
No numeric code	The boot configuration data store could not be opened. The system could not find the file specified.	The selected system store cannot be found. Microsoft also documents this message for a missing BCD, so it does not prove the partition type is wrong.
No numeric code	The boot configuration data store could not be opened. The requested system device cannot be found.	Windows cannot resolve the system device. A wrong GPT type is one possible cause; wrong disk selection, a missing ESP, or damaged BCD can produce the same result.
No numeric code	Failure when attempting to copy boot files.	`bcdboot` could not use its source or destination. Confirm the detected Windows and ESP, available space, filesystem readability, and write access before retrying.
`0xc000000f`	The Boot Configuration Data for your PC is missing or contains errors	Common BCD/startup code. Give this writeup priority only when the displayed file is `\Boot\BCD`, `\BCD`, or `\EFI\Microsoft\Boot\BCD` and the wrong ESP type is independently proven.
`0xc0000034`	The Boot Configuration Data file is missing some required information	Supports a missing or incomplete BCD diagnosis. It does not identify why the store became unavailable.
`0xc0000225`	`STATUS_NOT_FOUND` / The boot selection failed because a required device is inaccessible / A required device isn't connected or can't be accessed	The boot object or referenced device cannot be resolved. Use the named file and BCD contents to distinguish a system-partition discovery failure from other causes.
`0xc000000e`	`STATUS_NO_SUCH_DEVICE` / The application or operating system couldn't be loaded because a required file is missing or contains errors	A device that does not exist can be referenced in BCD. The code is adjacent evidence, not proof of a wrong partition type.
`0xc0000098`	The Boot Configuration Data file doesn't contain valid information for an operating system	Can apply when the displayed file is `\BCD`. The same status can name a missing or incompatible driver, so use the complete screen text.
No Windows code	No bootable device, No boot device found, or a return to firmware setup	These are firmware or manufacturer messages, not Windows error codes. They can accompany an ESP discovery problem but require firmware-entry and boot-order checks as well.

Confidence is high when an existing FAT32 partition on the verified GPT Windows disk contains the Windows EFI tree, its type is demonstrably wrong, the explicit BCD store identifies a loader for the verified installation, and changing only the type restores startup. Confidence is moderate when BCDBoot is also required because that proves two defects were repaired in the same session. Confidence is also capped at moderate when the pre-repair BCD is missing or corrupt and ownership relies on independent firmware/layout evidence; without that independent proof, stop rather than retagging.