Share via

Windows 11 25H2 upgrade fails on systems with 100MB EFI System Partition (ESP) – poor detection & guidance

Javier Álvarez Molina 20 Reputation points
2025-12-12T16:41:24.3+00:00

Upgrading from Windows 11 23H2/24H2 to 25H2 fails with “We couldn’t update the system reserved partition” / error 0x800f0922 (0xc1900104) on devices where the EFI System Partition (ESP) is 100MB (very common OEM layout).

As a result, devices that reach 24H2 with a 100MB ESP are effectively blocked from upgrading to 25H2 and later versions, unless the EFI partition is manually modified. This creates a long-term upgrade dead-end for many existing installations.

Microsoft Learn states that the ESP minimum size for UEFI/GPT systems is 200MB (recommended 260MB+), yet many older systems were deployed with 100MB, and Windows Setup / Windows Update:

does not detect this condition early,

does not provide a clear, actionable error message,

does not offer an official or automated remediation.

Please improve:

Pre-upgrade detection of ESP size and available free space.

A clear blocking message such as: “EFI System Partition too small (100MB). Feature updates from 24H2 onward require ≥200MB (recommended ≥260MB).”

Official, supported remediation steps for in-place upgrades (or an automated cleanup/resize process).

Current workarounds used by administrators (unsupported / risky):

Manually freeing space inside the EFI partition (e.g. deleting unused boot fonts).

Resizing the EFI partition to 260–500MB using third-party or offline tools.

Question to Microsoft:

  • Is there any short-term fix or planned update (24H2 cumulative updates or upcoming feature updates such as 25H2) that will:

automatically handle 100MB EFI partitions, or

  • at least provide clear guidance and tooling to avoid blocking systems at 24H2?Upgrading from Windows 11 24H2 to future feature updates (e.g. 25H2) fails with “We couldn’t update the system reserved partition” / error 0x800f0922 (0xc1900104) on devices where the EFI System Partition (ESP) is 100MB (very common OEM layout). As a result, devices that reach 24H2 with a 100MB ESP are effectively blocked from upgrading to 25H2 and later versions, unless the EFI partition is manually modified. This creates a long-term upgrade dead-end for many existing installations. Microsoft Learn states that the ESP minimum size for UEFI/GPT systems is 200MB (recommended 260MB+), yet many older systems were deployed with 100MB, and Windows Setup / Windows Update:
    • does not detect this condition early,
    • does not provide a clear, actionable error message,
    • does not offer an official or automated remediation.
    Please improve:
    • Pre-upgrade detection of ESP size and available free space.
    • A clear blocking message such as:
      “EFI System Partition too small (100MB). Feature updates from 24H2 onward require ≥200MB (recommended ≥260MB).”
    • Official, supported remediation steps for in-place upgrades (or an automated cleanup/resize process).
    Current workarounds used by administrators (unsupported / risky):
    • Manually freeing space inside the EFI partition (e.g. deleting unused boot fonts).
    • Resizing the EFI partition to 260–500MB using third-party or offline tools.
    Question to Microsoft:
    • Is there any short-term fix or planned update (24H2 cumulative updates or upcoming feature updates such as 25H2) that will:
      • automatically handle 100MB EFI partitions, or
      • at least provide clear guidance and tooling to avoid blocking systems at 24H2?
Windows for business | Windows Client for IT Pros | Devices and deployment | Install Windows updates, features, or roles
0 comments
Answer accepted by question author
  1. VPHAN 11,040 Reputation points Independent Advisor
    2025-12-12T17:29:27.01+00:00

    Hi Javier Álvarez Molina,

    To answer your direct question regarding an immediate fix: Microsoft has not currently announced an automated "ESP auto-resize" mechanism for the 24H2 cumulative pipeline or the upcoming feature update roadmap (such as the projected 25H2) that functions similarly to the partition resizing logic recently deployed for the Windows Recovery Environment (WinRE). The Windows Update orchestration engine currently operates with reactive failure logic rather than the proactive, pre-flight detection you described, leaving the generic 0x800f0922 (CBS_E_INSTALLERS_FAILED) error as the primary indicator that the boot manager update failed due to a space constraint.

    This error typically triggers during the SafeOS phase when the installer attempts to stage new boot binaries. As you noted, standard GPT disk layouts typically sequence the partitions as ESP followed immediately by the Microsoft Reserved Partition (MSR) and then the primary Windows data partition. This adjacency is the technical blocker; the MSR effectively "locks" the ESP from expanding using native APIs, even if you shrink the C: drive to create unallocated space. While third-party partition managers can slide these partitions, the strictly supported Microsoft methodology relies on diskpart.exe and is manual. The immediate supported remediation involves mounting the ESP system volume using mountvol y: /s via an elevated command prompt to inspect for non-essential debris, such as bitmap logs or OEM backup folders, which often consume the critical megabytes needed for the update.

    If the 100MB partition is purely populated by essential boot files and strictly insufficient, the architectural resolution involves deleting the obstructing MSR partition to allow the ESP to extend into that 16MB space (plus additional space claimed from the OS partition), and then manually recreating the MSR entry. This process requires precise manipulation of partition IDs and offsets, which explains why no automated tool has been pushed to the general consumer channel yet. Your feedback regarding the need for a specific "soft-block" message in the Modern Setup Host is technically sound and aligns with necessary improvements for the Update Agent. I will ensure your specific request for pre-upgrade detection logic and a supported, non-destructive remediation tool is forwarded to the deployment engineering team for review.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    VP

    0 comments

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.