Fix Windows Server 2025 Boot Issues with DISM, BCDEdit, WinRE, and ReAgentC

A Windows Server boot failure often looks worse than it is. You can usually recover the server without reinstalling Windows. First, find the failed layer. Then change the BCD, recovery partition, storage drivers, or BitLocker settings only when needed.

This guide covers Server 2025 systems that ignore F8, cannot start WinRE, stop with INACCESSIBLE_BOOT_DEVICE, or enter a BitLocker recovery loop. Windows Server includes WinRE, DISM, BCDEdit, ReAgentC, BCDBoot, and Bootrec. You do not need a separate toolkit.

Prerequisites

Have these items ready before you change a production server:

• Windows Server 2025 installation media that matches the architecture, language, edition, and preferably the current build.
• Administrator access, or access to WinRE > Troubleshoot > Advanced options > Command Prompt.
• Console access through a hypervisor, local keyboard and display, or a controller such as iDRAC, iLO, or IPMI.
• A current backup or VM snapshot where possible.
• The 48-digit BitLocker recovery key for each encrypted volume involved.
• Storage and network drivers for the installed controller, NIC, or iSCSI boot adapter.
• At least 2 GB of free space for mounting installation images.
• A record of the original firmware storage mode, such as AHCI, RAID, or HBA.

A Mac works well as the operator workstation. Use it to open a remote console, attach an ISO, or prepare recovery media. Run the repair commands inside Windows Server, WinRE, or Windows Setup, not in macOS Terminal.

Warning: BCDEdit, DiskPart, BCDBoot, and BitLocker changes can stop the server from starting. Check disk numbers, volume letters, firmware mode, and encryption state before making changes.

Test Environment

This workflow targets Windows Server 2025 on UEFI/GPT systems. That includes physical servers, Generation 2 VMs, and iSCSI-boot hosts. The same process generally applies to Server 2016, 2019, and 2022. However, their partition layouts and update behavior may differ.

Commands run after a normal boot need an elevated Command Prompt or PowerShell session. WinRE examples use D:\ for the offline Windows installation. That is only an example. WinRE often changes drive letters.

Quick Diagnosis for Windows Server Boot Issues with DISM and BCDEdit

1. Classify the symptom

Start with what the server actually does:

Symptom	Likely area	First check
F8 does nothing	Normal UEFI behavior	Use Automatic Repair or installation media
Automatic Repair never opens WinRE	WinRE disabled, missing, or corrupt	reagentc /info when the OS is available
“A required device isn’t connected or can’t be accessed”	BCD or boot files	bcdedit /enum all and bcdboot
INACCESSIBLE_BOOT_DEVICE	Storage path or driver	Firmware mode, controller, driver, iSCSI path
BitLocker asks for a key every boot	TPM/PCR measurement changed	Verify protectors and recent changes
reagentc /enable fails	Missing image, invalid path, or partition issue	Locate and validate winre.wim

Do not run every repair command you remember. Rebuilding WinRE will not fix a missing storage driver. Servicing the Windows component store will not replace a missing EFI boot file. Find the fault first. This saves time and reduces the risk of causing a second problem.

2. Reach WinRE without relying on F8

Legacy F8 is not the normal recovery path on a modern UEFI server. Use one of these methods:

• If Windows still boots, run:

shutdown.exe /r /o /t 0

• If Windows does not boot, interrupt startup during the spinning-dots stage three times. Automatic Repair should start on the next boot.
• If that fails, boot matching Windows Server installation media and select Next > Repair your computer > Troubleshoot > Advanced options > Command Prompt.

Use controlled console access when forcing failed starts. Do not cut power to storage arrays or hosts with write-back cache. Interrupting Windows startup is one thing. Removing power from the storage path is far riskier.

3. Map the offline volumes

WinRE often uses different drive letters from the running OS. Find the Windows, EFI System, recovery, and installation-media volumes first:

diskpart
list disk
list volume
list partition
exit

A typical UEFI server might show:

Volume 0 D Windows NTFS Partition 120 GB
Volume 1 S SYSTEM FAT32 Partition 260 MB
Volume 2 Recovery NTFS Partition 1024 MB
Volume 3 E SERVER_EVAL UDF DVD-ROM 5 GB

Confirm the Windows volume:

dir D:\Windows

Expected result:

Directory of D:\Windows

System32
WinSxS
servicing

If those folders are missing, stop and check the other volumes. Do not target a drive with DISM or BCDBoot just because it is labeled D:.

4. Capture the current recovery and BCD state

On a running server, check WinRE with:

reagentc.exe /info

Healthy output resembles:

Windows Recovery Environment (Windows RE) and system reset configuration
Information:

Windows RE status: Enabled
Windows RE location: \\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Boot Configuration Data (BCD) identifier: 7b1d…

This command answers a basic question: Is WinRE enabled on Windows Server 2025? An empty location, a Disabled status, or an error means the registration needs work.

List all BCD objects:

bcdedit.exe /enum all /v

Focus on:

• {bootmgr} and its device value.
• The active Windows loader identifier.
• device and osdevice under the Windows loader.
• recoverysequence under the loader.
• A matching recovery loader object with a valid winre.wim path.

BCDEdit returns a lot of output. Only a few fields matter here. Check that Boot Manager, the Windows loader, and the recovery loader point to real devices.

Before editing a working BCD store, export it:

bcdedit.exe /export C:\Temp\bcd-backup

Expected output:

The operation completed successfully.

The backup is small and quick to create. It can save time if a reasonable edit goes wrong.

Common Issues and Solutions

Problem: F8 Does Not Open Advanced Boot Options

Symptoms:

• Pressing F8 has no effect.
• The server moves directly from firmware initialization to Windows Boot Manager.
• There is no legacy Advanced Boot Options menu.
• Remote-console keyboard input appears too late in the boot cycle.

Why it happens: Windows Server 2025 usually uses UEFI and a fast boot path. The old F8 workflow is not reliable. A remote controller may also start its virtual keyboard after the required boot stage.

Solution:

If the OS still starts, request an advanced restart:

shutdown.exe /r /o /t 0

If it does not start, use three controlled failed boots or matching installation media. Select Repair your computer, not Install now. The buttons are close together, so check your choice on a remote console.

After reaching WinRE, open Command Prompt and map the disks:

diskpart
list volume
exit

Verification: You should reach Choose an option > Troubleshoot > Advanced options and be able to open Command Prompt.

Problem: Automatic Repair Does Not Launch WinRE

Symptoms:

• Three failed starts return to the same boot error.
• reagentc /info reports Windows RE status: Disabled.
• The recovery location is blank.
• The server was recently generalized with Sysprep.
• A cloned image boots but has no working recovery options.

Why it happens: Sysprep and image deployment can leave WinRE disabled. Automatic Repair may detect repeated failures. However, it cannot load a recovery image that is disabled, missing, or no longer listed in the BCD.

Check the current state from an elevated prompt:

reagentc.exe /info

If the image exists at the registered location, try enabling it:

reagentc.exe /enable

Expected output:

REAGENTC.EXE: Operation Successful.

If that fails, locate the image:

dir C:\Windows\System32\Recovery\winre.wim /a

The /a switch includes hidden and system files. Without it, a valid winre.wim may appear to be missing.

If the file exists, place it in a stable recovery folder and register that folder:

mkdir C:\Recovery\WindowsRE
copy C:\Windows\System32\Recovery\winre.wim C:\Recovery\WindowsRE\winre.wim
reagentc.exe /disable
reagentc.exe /setreimage /path C:\Recovery\WindowsRE /target C:\Windows
reagentc.exe /enable

Expected registration output:

Directory set to: \\?\GLOBALROOT\device\harddisk0\partition3\Recovery\WindowsRE

REAGENTC.EXE: Operation Successful.

Pass /setreimage the folder that contains winre.wim, not the WIM filename. ReAgentC is strict about this detail. Its errors are not always helpful.

Verification:

reagentc.exe /info

Confirm that the status is Enabled, the location is filled in, and a BCD identifier is present.

Problem: The Recovery Partition Is Missing or Too Small

Symptoms:

• DiskPart shows no recovery partition.
• A partitioning or cleanup job recently changed the disk.
• WinRE registration points to a nonexistent partition.
• Recovery updates fail because the partition lacks free space.
• reagentc /enable returns a general failure.

Why it happens: Disk cleanup, cloning, manual resizing, or deployment scripts can remove the recovery partition. Older layouts may also lack enough free space for newer WinRE images.

First, inspect the layout:

diskpart
select disk 0
list partition
list volume
exit

Do not assume Disk 0 contains Windows on a SAN server. Match the disk by its size, label, and identifier. Storage order can change.

If a suitable recovery partition exists, give it a temporary letter:

diskpart
select disk 0
select partition 4
assign letter=R
exit

Check free space:

fsutil.exe volume diskfree R:

Create the expected directory if needed:

mkdir R:\Recovery\WindowsRE

Copy a known-good image, register it, and then remove the temporary letter:

copy C:\Windows\System32\Recovery\winre.wim R:\Recovery\WindowsRE\winre.wim
reagentc.exe /disable
reagentc.exe /setreimage /path R:\Recovery\WindowsRE /target C:\Windows
reagentc.exe /enable
diskpart
select volume R
remove letter=R
exit

Warning: Recreating a partition means shrinking another volume and changing the partition table. Back up the server first. Do not use generic DiskPart deletion or shrink commands on a production server. Check its GPT layout, vendor partitions, BitLocker state, and storage design first.

A 1 GB recovery partition is a useful baseline for new Server 2025 systems. It is not a permanent guarantee. WinRE images and updates can grow. Check Microsoft’s current WinRE partition guidance before setting a fixed standard.

Verification:

reagentc.exe /info

Confirm that the recovery path points to the intended partition. Then test WinRE during a maintenance window.

Problem: winre.wim Is Missing or Corrupt

Symptoms:

• reagentc /enable fails despite a valid-looking recovery path.
• winre.wim is absent or has a size of zero.
• WinRE begins loading and then resets or shows an error.
• Disk or component-store corruption occurred recently.

Why it happens: An interrupted update, disk damage, manual cleanup, or a bad deployment can damage the recovery image. ReAgentC registers a path. It does not prove that the WIM itself is healthy.

Use matching Server 2025 installation media. Suppose the ISO is E: and the offline Windows installation is D:\.

First, identify the correct image index:

dism.exe /Get-WimInfo /WimFile:E:\sources\install.wim

Expected output includes one or more indexes:

Index : 4
Name : Windows Server 2025 SERVERDATACENTER
Description : Windows Server 2025 Datacenter

If the media has install.esd, use E:\sources\install.esd instead. For split files such as install.swm, use the matching DISM split-image options. You can also get standard installation media.

Create a mount directory and mount the correct index as read-only:

mkdir D:\Mount
dism.exe /Mount-Image /ImageFile:E:\sources\install.wim /Index:4 /MountDir:D:\Mount /ReadOnly

/Index:4 selects the edition found earlier. /ReadOnly prevents changes to the source image. That is the safe choice when you need only one clean file.

Copy the clean recovery image:

mkdir D:\Recovery\WindowsRE
copy D:\Mount\Windows\System32\Recovery\winre.wim D:\Recovery\WindowsRE\winre.wim

Unmount the source image without saving changes:

dism.exe /Unmount-Image /MountDir:D:\Mount /Discard

Register it against the offline installation:

reagentc.exe /disable /target D:\Windows
reagentc.exe /setreimage /path D:\Recovery\WindowsRE /target D:\Windows
reagentc.exe /enable /target D:\Windows

Some recovery builds may reject this offline ReAgentC operation. If so, start the repaired Windows installation. Then repeat the registration from an elevated prompt with C:\Windows.

You can also inspect the extracted WIM:

dism.exe /Get-WimInfo /WimFile:D:\Recovery\WindowsRE\winre.wim

Verification: DISM should return image details without reporting corruption. After Windows starts, reagentc /info should report Enabled and show the new location.

Problem: DISM Reports Source Files Could Not Be Found

Symptoms:

• DISM returns 0x800f081f.
• /RestoreHealth cannot download or locate source files.
• The recovery environment has no network path to Windows Update.
• Installation media is from a different build or edition.

Why it happens: DISM needs source files that match the damaged installation. WinRE often has no internet access. An older ISO may also lack the required files. Matching only “Server 2025” is not always enough.

For a running server, start with:

dism.exe /Online /Cleanup-Image /CheckHealth
dism.exe /Online /Cleanup-Image /ScanHealth

For an offline Windows installation at D:\:

dism.exe /Image:D:\ /Cleanup-Image /CheckHealth
dism.exe /Image:D:\ /Cleanup-Image /ScanHealth

If repair is possible and index 4 matches the installed edition:

dism.exe /Image:D:\ /Cleanup-Image /RestoreHealth /Source:wim:E:\sources\install.wim:4 /LimitAccess

/Source selects the matching image index. /LimitAccess stops DISM from trying Windows Update. This helps in WinRE and on isolated servers.

Expected result:

The restore operation completed successfully.
The operation completed successfully.

That is the result you need. If 0x800f081f returns, check the build, edition, language, and image index. Repeating the same command will not fix mismatched media.

After DISM completes, check the offline system files:

sfc.exe /scannow /offbootdir=D:\ /offwindir=D:\Windows

Verification: Repeat /ScanHealth. It should report no component-store corruption or confirm that it repaired the damage.

Problem: The BCD Store or EFI Boot Files Are Broken

Symptoms:

• 0xc000000e, 0xc0000098, or “The Boot Configuration Data file is missing.”
• Windows Boot Manager cannot find the OS loader.
• bcdedit /enum all returns “The boot configuration data store could not be opened.”
• The problem began after cloning, partitioning, or replacing a disk.

Why it happens: The BCD store may be missing, corrupt, or linked to an old partition ID. On UEFI systems, the EFI System Partition may also lack boot files while Windows remains intact.

Map the Windows and EFI volumes. The EFI partition is usually FAT32 and 100–300 MB. Vendor layouts can vary:

diskpart
list volume
select volume 1
assign letter=S
exit

Confirm the Windows directory:

dir D:\Windows

On UEFI systems, rebuild the Microsoft boot files with BCDBoot:

bcdboot.exe D:\Windows /s S: /f UEFI /v

• D:\Windows is the offline Windows installation.
• /s S: selects the EFI System Partition.
• /f UEFI writes UEFI boot files.
• /v displays verbose output.

Expected output:

Boot files successfully created.

BCDBoot is usually the right tool for a modern UEFI repair. It rebuilds the boot files from Windows. You do not need to edit every BCD object by hand.

Inspect the rebuilt store:

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

For BIOS/MBR systems only, Bootrec may also help:

bootrec.exe /fixmbr
bootrec.exe /scanos
bootrec.exe /rebuildbcd

Many older guides include bootrec /fixboot. It can return Access is denied on modern UEFI systems. It is not the main repair tool for an EFI boot partition. BCDBoot is usually a better fit for Server 2025 UEFI systems.

If you exported a known-good store earlier, import it only if the disk layout still matches:

bcdedit.exe /import D:\Temp\bcd-backup

A backup from the old disk layout may restore the wrong IDs after cloning or partition changes. A backup is useful, but it is not always correct.

Verification:

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

Confirm that the Windows loader uses the correct device and osdevice. Then remove the temporary ESP letter:

diskpart
select volume S
remove letter=S
exit

Problem: INACCESSIBLE_BOOT_DEVICE After a Storage Change

Symptoms:

• The server stops with INACCESSIBLE_BOOT_DEVICE.
• The failure began after changing RAID, AHCI, HBA, or virtual controller settings.
• A VM disk was moved from one controller type to another.
• A storage driver or firmware update was installed.
• The Windows volume is visible from WinRE but does not boot.

Why it happens: Windows loaded the kernel but then lost access to the boot volume. Common causes include a missing driver or a changed controller mode. A damaged storage filter driver can also cause it. Moving controllers before installing the new driver is another common cause.

First, undo any accidental firmware or VM changes. A server that used RAID mode may stop if switched to AHCI. This can happen even when the disks are healthy. Restoring the known-good storage path is often safer than adapting Windows to an accidental setting.

Confirm that WinRE can read the volume:

dir D:\Windows\System32\drivers

Inspect installed third-party drivers:

dism.exe /Image:D:\ /Get-Drivers /Format:Table

If the required signed storage driver is on E:\Drivers\Storage, inject it:

dism.exe /Image:D:\ /Add-Driver /Driver:E:\Drivers\Storage /Recurse

/Recurse searches subfolders for driver packages. Use it only with a small vendor driver folder. A large mixed driver store may add packages the server does not need.

Expected output:

The driver package was successfully installed.
The operation completed successfully.

If the error began after a driver update, find the published driver name:

dism.exe /Image:D:\ /Get-Drivers /Format:Table

Then remove only the confirmed faulty package:

dism.exe /Image:D:\ /Remove-Driver /Driver:oem42.inf

Warning: Removing the wrong boot driver can make recovery harder. Record the provider, class, version, and date before removing any oem*.inf package.

Inspect BCD after fixing the storage path:

bcdedit.exe /enum all /v

If the EFI boot files are also damaged, rebuild them with BCDBoot as shown earlier.

Verification: DISM should list the required controller driver in the offline image. Restore the original controller mode, disconnect unused storage, and perform a controlled boot.

For a broader decision tree, Microsoft maintains an official troubleshooting reference for INACCESSIBLE_BOOT_DEVICE.

Problem: An iSCSI-Boot Server Stops with INACCESSIBLE_BOOT_DEVICE

Symptoms:

• Local or SAN-attached systems boot, but an iSCSI-boot host does not.
• The target LUN is reachable from another initiator.
• The failure followed a NIC replacement, VLAN change, NIC team change, or target ACL update.
• The initiator IQN or source IP recently changed.
• WinRE cannot see the iSCSI-backed Windows volume.

Why it happens: An iSCSI boot depends on several parts. The firmware initiator, NIC, VLAN, target ACL, network path, drivers, and Windows settings must agree. If WinRE cannot see the LUN, changing osdevice in BCD will not restore the network path.

Work from the outside inward:

• Verify that the iSCSI target is online and the LUN mapping is unchanged.
• Confirm that the host initiator IQN is still permitted by the target ACL.
• Check the boot NIC’s link, VLAN, DHCP/static address, gateway, and multipath design.
• Disable newly added NIC teaming temporarily if it altered the boot interface.
• Confirm that firmware iSCSI settings still identify the correct target IP, port, IQN, and LUN.
• Load or inject the boot NIC and storage drivers into the offline image.

The order matters. Rebuilding BCD will not help while the firmware initiator cannot sign in to the target.

If the Windows volume becomes visible as D:, add the matching signed drivers:

dism.exe /Image:D:\ /Add-Driver /Driver:E:\Drivers\BootNIC /Recurse
dism.exe /Image:D:\ /Add-Driver /Driver:E:\Drivers\iSCSI /Recurse

Then inspect the BCD:

bcdedit.exe /enum all /v

Do not force a generic partition=D: value just because WinRE used that letter. WinRE drive letters are temporary. Boot entries normally find devices by partition ID.

If a LUN move removed the EFI files, mount the ESP as S: and rebuild them:

bcdboot.exe D:\Windows /s S: /f UEFI /v

Verification: The firmware initiator should sign in to the target before Windows Boot Manager starts. The target should show a session from the expected IQN. WinRE should also see the Windows volume without a manual connection.

Problem: BitLocker Recovery Appears After Every Update Reboot

Symptoms:

• The server requests the 48-digit recovery key on each boot.
• The loop began after a security, firmware, Secure Boot, or boot-manager update.
• The correct key unlocks the volume, but protection triggers again on the next restart.
• TPM measurements no longer match the state sealed into the BitLocker protector.

Why it happens: BitLocker can bind a system-volume protector to TPM Platform Configuration Registers (PCRs). A valid boot-chain change can alter these values. BitLocker then asks for recovery because the new boot path no longer matches its trusted baseline.

The editorial issue pattern links this behavior to a reported April 2026 security update and PCR conflict. Treat that link as unverified until you check Microsoft’s current Windows release-health entry and the exact Knowledge Base article. Do not publish or use a guessed KB number. Update details change, and the exact build matters.

If the server is in recovery, get the key from the approved escrow system. Match its Key ID to the screen. Enter it locally or through an approved secure console. Never paste it into tickets, chat, or screenshots.

After one successful boot, inspect protection:

manage-bde.exe -status C:
manage-bde.exe -protectors -get C:

Before retrying a confirmed boot-related update, suspend protection for one reboot:

manage-bde.exe -protectors -disable C: -RebootCount 1

Or use PowerShell:

Suspend-BitLocker -MountPoint "C:" -RebootCount 1

Apply only the confirmed Microsoft or vendor fix, then restart once. Check that protection resumed:

manage-bde.exe -status C:

If protection is still suspended after the successful boot:

manage-bde.exe -protectors -enable C:

Warning: Suspending protectors keeps the volume encrypted at rest. However, it briefly relaxes TPM startup checks. Keep the server secure, use the shortest possible window, and do not decrypt the volume as a workaround.

Verification: manage-bde -status C: should show Protection Status: Protection On. A second controlled reboot should finish without another recovery prompt.

Microsoft’s BitLocker recovery overview explains key handling and common recovery triggers.

Error Messages Quick Reference

Error or status	Meaning	Matching action
Windows RE status: Disabled	WinRE is not registered for automatic use	Validate winre.wim, run /setreimage, then /enable
REAGENTC.EXE: The Windows RE image was not found	Registered directory does not contain a usable image	Re-extract and register winre.wim
REAGENTC.EXE: Unable to update Boot Configuration Data	BCD is inaccessible, corrupt, or mounted incorrectly	Repair EFI boot files and BCD first
0xc000000e	Required boot device cannot be resolved or reached	Check storage path, BCD, and EFI files
0xc0000098	BCD lacks a valid OS entry or contains invalid data	Rebuild with BCDBoot; inspect with BCDEdit
The boot configuration data store could not be opened	Default BCD store is missing or inaccessible	Mount the ESP and use bcdedit /store
bootrec /fixboot: Access is denied	Common UEFI/ESP access or layout problem	Assign the ESP a letter and use BCDBoot
INACCESSIBLE_BOOT_DEVICE	Kernel lost access to the system volume	Restore controller mode or repair boot-critical drivers
0x800f081f	DISM cannot find matching repair source files	Use matching media and the correct image index
BitLocker recovery on every boot	TPM/PCR measurements do not match	Use the recovery key, validate the update issue, then suspend for one controlled reboot
The system cannot find the path specified	WinRE drive letters or target paths are wrong	Remap volumes before retrying offline commands

Platform-Specific Issues

Managing Recovery from macOS

A Mac is useful as an operator workstation. It cannot run ReAgentC, BCDEdit, or Windows DISM against the server itself.

From a Mac, you can:

• Open a browser-based iDRAC, iLO, IPMI, or hypervisor console.
• Attach the Windows Server 2025 ISO as virtual media.
• Use Microsoft Remote Desktop or Windows App while the server still boots.
• Connect to a VM console through the hypervisor’s supported client.
• Record command output in the incident log without exposing recovery keys.

A Server ISO downloaded on macOS may contain files larger than FAT32’s 4 GB limit. Use a method that supports the ISO layout and large install.wim files. Copying the ISO contents to FAT32 may create media that looks correct but does not boot.

UEFI/GPT Versus BIOS/MBR

Most Server 2025 installations use UEFI/GPT:

• Use BCDBoot with /f UEFI.
• The boot files live on a FAT32 EFI System Partition.
• bootrec /fixmbr is not the main repair for a missing UEFI loader.

Older BIOS/MBR servers differ:

• They use an active system partition rather than an ESP.
• bootrec /fixmbr and bootrec /rebuildbcd may be relevant.
• Use bcdboot D:\Windows /s S: /f BIOS only after confirming BIOS mode.

Do not switch from UEFI to legacy BIOS as a test. Windows was installed for one boot model. Changing that model usually adds another fault.

Virtual Machines

Before repairing a VM, compare its current hardware with the last known-good setup:

• Hyper-V Generation 1 versus Generation 2.
• IDE, SCSI, NVMe, VirtIO, VMware PVSCSI, or vendor-specific controller.
• Secure Boot state and template.
• Virtual TPM attachment.
• Disk order and boot order.

A snapshot rollback may be faster when one known change caused the failure. The trade-off is simple: You lose every change made after the snapshot. Check its age and app consistency before you roll back.

Configuration Issues and Correct Examples

Using the Wrong Offline Drive Letter

Incorrect:

dism.exe /Image:C:\ /Cleanup-Image /RestoreHealth

In WinRE, C: may be the recovery RAM disk or another volume. Drive letters are not reliable outside the running OS.

Correct workflow:

diskpart
list volume
exit
dir D:\Windows
dism.exe /Image:D:\ /Cleanup-Image /ScanHealth

Passing the WIM Filename to /setreimage

Incorrect:

reagentc.exe /setreimage /path D:\Recovery\WindowsRE\winre.wim

Correct:

reagentc.exe /setreimage /path D:\Recovery\WindowsRE /target D:\Windows

ReAgentC expects the folder that contains winre.wim. This small syntax detail causes a repeatable failure.

Using the Wrong Installation Image Index

Do not assume index 1 matches the installed edition:

dism.exe /Get-WimInfo /WimFile:E:\sources\install.wim

Then use the matching index:

dism.exe /Image:D:\ /Cleanup-Image /RestoreHealth /Source:wim:E:\sources\install.wim:4 /LimitAccess

The image index selects an edition, not another copy of the same files. Check it whenever you change media.

Rebuilding UEFI Boot Files with BIOS Commands

For a UEFI server, prefer:

bcdboot.exe D:\Windows /s S: /f UEFI /v

Use BCDEdit to inspect the resulting store:

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

On confirmed BIOS/MBR systems, bootrec /fixmbr, /scanos, and /rebuildbcd may also apply. Check the firmware mode first. These commands are not interchangeable.

Changing BCD While BitLocker Protection Is Active

Before planned Secure Boot, firmware, or boot-manager work:

manage-bde.exe -protectors -disable C: -RebootCount 1

After one successful boot, verify protection:

manage-bde.exe -status C:

Never delete TPM or recovery protectors just to stop a prompt. Keep the volume encrypted and fix the trust mismatch.

Running Sysprep Without a Post-Deployment WinRE Check

After deployment and before handoff:

reagentc.exe /enable
reagentc.exe /info

Deployment is not complete until WinRE has a valid location and passes a controlled boot test. Do not wait for an outage to find this gap.

Getting Help

Collect evidence before you escalate. A photo of the stop code helps, but it rarely explains the cause.

Useful logs and files

• C:\Windows\Logs\DISM\dism.log
• C:\Windows\Logs\CBS\CBS.log
• C:\Windows\System32\Recovery\ReAgent.xml
• C:\Windows\Panther\setupact.log
• C:\Windows\Panther\setuperr.log
• C:\Windows\INF\setupapi.dev.log
• C:\Windows\System32\LogFiles\Srt\SrtTrail.txt
• Event Viewer: Applications and Services Logs > Microsoft > Windows > BitLocker-API
• Event Viewer: Windows Logs > System
• Storage-controller, NIC, firmware, and iSCSI-target logs

Capture these command results:

reagentc.exe /info
bcdedit.exe /enum all /v
manage-bde.exe -status
dism.exe /Online /Get-Drivers /Format:Table

For an offline installation, use the relevant DISM /Image:D:\ command. Redact machine names, disk serials, and target IQNs as needed. Remove all BitLocker recovery data. Never include a recovery key in a general incident bundle.

Official references

• Windows Recovery Environment technical reference
• ReAgentC command-line options
• BCDEdit command reference
• DISM command-line options
• BitLocker recovery overview
• Microsoft troubleshooting for INACCESSIBLE_BOOT_DEVICE

Escalate to Microsoft or the hardware or storage vendor when:

• The boot disk disappears from firmware, WinRE, and vendor diagnostics.
• The BCD repeatedly corrupts after successful recreation.
• The server uses clustered, multipath, or vendor-managed boot-from-SAN storage.
• BitLocker recovery repeats with no deliberate boot-chain change.
• The suspected April 2026 update pattern cannot be matched to current Microsoft guidance.
• Filesystem or hardware diagnostics report media errors.

At this point, the fault is probably beyond a basic Windows boot repair. Good logs and an exact change history will help the vendor find the cause faster.

Prevention Tips

• Record the baseline: Export BCD, save reagentc /info, record the partition layout, and document the storage-controller mode after deployment.
• Validate after Sysprep: Run reagentc /enable and reagentc /info on every deployed image.
• Protect the recovery partition: Exclude recovery and EFI partitions from generic cleanup or resizing automation.
• Leave working space: Use a recovery partition sized for the current WinRE image plus future servicing growth.
• Match recovery media: Keep Server 2025 media aligned with the deployed language, architecture, edition, and build.
• Escrow BitLocker keys: Confirm that every recovery key is retrievable by Key ID before enabling encryption.
• Suspend protection deliberately: Suspend BitLocker for the smallest possible window before validated firmware or boot-chain changes.
• Stage controller changes: Install and verify the new storage driver before changing VM controller type or firmware mode.
• Document iSCSI dependencies: Record IQNs, VLANs, target ACLs, boot NICs, paths, and multipath settings.
• Test WinRE: Schedule a controlled recovery boot after deployment and after partition-layout changes.
• Keep console access working: Test out-of-band management and virtual-media attachment before an outage.
• Back up before servicing: Take an application-consistent backup or checkpoint before bootloader, storage, firmware, and security-update changes.

Most checks take only a few minutes during deployment. They take far longer during an outage when no one knows the old storage mode or key location.

Frequently Asked Questions

How do I check whether WinRE is enabled on Windows Server 2025?

Open an elevated Command Prompt and run:

reagentc.exe /info

Look for Windows RE status: Enabled and a filled-in Windows RE location. If the status is Disabled, Automatic Repair cannot use the registered local recovery environment.

Why does WinRE fail even though Automatic Repair should trigger it?

Automatic Repair can detect failed starts without a working recovery image. Sysprep may have left WinRE disabled. Cleanup may have removed the partition. The winre.wim file may also be missing or damaged. Check ReAgentC, the recovery partition, and the recovery BCD entry in that order.

What causes INACCESSIBLE_BOOT_DEVICE?

The kernel cannot reach the system volume. Common causes include controller mode changes, missing drivers, VM controller moves, storage filter drivers, and broken iSCSI paths. Restore the original storage path first. Then repair drivers or boot files as needed.

Which commands rebuild a broken Windows Server 2025 boot record?

For UEFI systems, mount the EFI System Partition and use:

bcdboot.exe D:\Windows /s S: /f UEFI /v

Use BCDEdit to inspect the resulting store:

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

On confirmed BIOS/MBR systems, bootrec /fixmbr, /scanos, and /rebuildbcd may also apply. Check the firmware mode first. These commands are not interchangeable.

How do I repair a corrupted winre.wim?

Mount the matching Server 2025 install.wim. Copy Windows\System32\Recovery\winre.wim to a recovery folder. Unmount the source, then run reagentc /setreimage and reagentc /enable.

How do I fix a BitLocker update loop without exposing the volume?

Use the approved recovery key once. Check the exact update issue against current Microsoft guidance. Then suspend protectors for one controlled reboot. Do not decrypt the volume or delete its protectors. Confirm that protection returns to Protection On.

Wrapping Up

Treat boot recovery as a chain, not one large failure. Map the disks, record the WinRE and BCD state, and find the failed layer. Then use the matching repair. On UEFI systems, BCDBoot is usually a better choice than old Bootrec routines. Storage and iSCSI failures need path and driver checks before BCD edits.

After the server starts, test WinRE and confirm BitLocker protection. Remove temporary drive letters and save a new baseline. A successful login is useful. A tested and documented recovery is better.

Step	Action	Applies To
1	Map Windows, EFI, recovery, and media volumes	Every offline repair
2	Check ReAgentC and enumerate BCD	WinRE and boot failures
3	Restore or re-register winre.wim	Missing or corrupt WinRE
4	Rebuild EFI files with BCDBoot	Broken UEFI boot chain
5	Restore drivers and storage paths	INACCESSIBLE_BOOT_DEVICE
6	Validate PCR/update guidance and suspend protection briefly	BitLocker recovery loops
7	Test WinRE and save a new baseline	Every repaired deployment

Last updated: 2026-07-24 | Applies to Windows Server 2025 on UEFI/GPT, virtualized, bare-metal, and iSCSI-boot systems