SCCM Feature Upgrade Failure on HP Computers: Insufficient System Partition Disk Space (Error 0xC1900200 / -1047526912)

When attempting to install Windows 11 feature upgrade via SCCM, you might notice that the update fails quickly, and under the “More Information” section, it shows the error code 0xC1900200 (-1047526912). Additionally, you may observe that the update content is not downloading properly, and within a few minutes, the installation fails.

I encountered this issue on several HP laptops and was able to identify the root cause and solution. The first step in troubleshooting should be reviewing the Panther logs, which can help pinpoint the exact blocker.

You can find the Panther logs at the following location:

C:\$WINDOWS.~BT\Sources\Panther





Next, you need to check the XML files located in the Panther folder, as shown in the screenshot above.

Look for the most recently created CompatData.xml file. This file corresponds to the latest SCCM feature update attempt that failed.

Open this file using CMTrace, which makes it easier to read and highlight error codes or issues in a structured format.  If the device is an SCCM client, CMTrace is usually available at the following location:

C:\Windows\CCM\CMTrace.exe

In the example below, the CompatData.xml file shows no blockers, meaning the system is compatible for upgrade and should proceed without issues:




If you find any BlockingType marked as "Hard" in the CompatData.xml file, that indicates a critical compatibility issue that is blocking the Windows 11 upgrade. These hard blocks must be resolved before the update can proceed.

Your devices must meet the following minimum requirements to successfully upgrade to Windows 11:

 Windows 11 Specs and System Requirements | Microsoft Windows

In my case, the CompatData.xml log showed the following entry, indicating that the upgrade has failed due to a hard block:


It shows Setup_InsufficientSystemPartitionDiskSpace" ActualValue1="15"><CompatibilityInfo BlockingType="Hard"

This means the System Reserved Partition had only 15 MB of free space, which is not sufficient for the Windows upgrade.

It's important to note that you cannot resize or extend the EFI/System Reserved Partition using the built-in Disk Management tool in Windows. Disk Management does not allow modification of this partition type.



To free up some space in the EFI/System Reserved partition on HP computers, you can use the following command. This was suggested in a Microsoft Community thread and has helped in some cases:

Can't update Windows 11 due to System Reserved Partition Size - Microsoft Community

The default size of the EFI partition is 100 MB. Deleting the HP BIOS image files from the EFI folder should free up substantial disk space in that volume.

Please open an admin Command Prompt window (instead of PowerShell) and run these commands one by one:

mountvol Y: /s

cd /d Y:\EFI\Microsoft\Boot\Fonts

del *.ttf

powershell -command "GCI Y:\  -File -Recurse | Sort Length -descending | Select FullName, Length -first 10"

dir Y:\


I tried the method mentioned above, and after retrying the installation, the update process successfully started downloading the necessary files. It proceeded through the installation and even restarted the system. However, after the restart, the upgrade rolled back and failed again.

Upon further investigation, I noticed that the files deleted from the EFI\HP folder were automatically recreated during the upgrade process, once again filling up the limited space in the system partition.

I recommend trying this approach first, as it might work for your device depending on how much space gets freed up and whether the EFI partition stays under the threshold.

I tried the above command again

mountvol Y: /s

cd /d Y:\EFI\Microsoft\Boot\Fonts

del *.ttf

powershell -command "GCI Y:\  -File -Recurse | Sort Length -descending | Select FullName, Length -first 10"

After mounting the EFI partition to drive Y: and listing its contents, I found several large files under the EFI\HP folder, such as:


Y:\EFI\HP\DEVFW\Firmware.BIN            37,911,910 bytes (~36.2 MB)

Y:\EFI\HP\SystemDiags\SysDiags.efi      13,808,976 bytes (~13.2 MB)

Y:\EFI\HP\DEVFW\MeCurrent.BIN            9,436,632 bytes (~9.0 MB)

Y:\EFI\HP\DEVFW\Realtek.bin              2,180,128 bytes (~2.1 MB)

Y:\EFI\HP\BiosUpdate\BiosMgmt.efi        1,478,800 bytes (~1.4 MB)

In comparison, essential Windows boot files under EFI\Microsoft\Boot and EFI\Boot are much smaller:

Y:\EFI\Microsoft\Boot\bootmgfw.efi       2,756,512 bytes (~2.6 MB)

Y:\EFI\Boot\bootx64.efi                   2,756,512 bytes (~2.6 MB)

Y:\EFI\Microsoft\Boot\bootmgr.efi         2,744,752 bytes (~2.6 MB)

I removed the following files and folders from the EFI\HP directory, which together freed approximately 65 MB of space on the EFI system partition:

  • EFI\HP\DEVFW\Firmware.BIN

  • EFI\HP\SystemDiags\SysDiags.efi

  • EFI\HP\DEVFW\MeCurrent.BIN

  • EFI\HP\DEVFW\Realtek.bin

  • EFI\HP\BiosUpdate\BiosMgmt.efi

These files are OEM-specific utilities and firmware components that are generally safe to delete, as they are not essential for the normal Windows boot process.

By freeing this space, I was able to resolve the upgrade block caused by insufficient system partition disk space.

Found the following reference regarding HP file deletion:

Which files can be deleted from System partition? - HP Support Community - 9325791

⚠️ Important:
Do NOT delete anything under the following folders:

  • Y:\EFI\Microsoft\Boot\

  • Y:\EFI\Boot\

These directories contain essential Windows boot files that are critical for the system to start properly. Deleting or modifying files here can cause your system to become unbootable.

To delete the unnecessary OEM files from the EFI partition, run the following commands in an elevated Command Prompt after mounting the EFI partition as drive Y::

del /f /q Y:\EFI\HP\DEVFW\Firmware.BIN

del /f /q Y:\EFI\HP\SystemDiags\SysDiags.efi

del /f /q Y:\EFI\HP\DEVFW\MeCurrent.BIN

del /f /q Y:\EFI\HP\DEVFW\Realtek.bin

del /f /q Y:\EFI\HP\BiosUpdate\BiosMgmt.efi

After cleanup, verify the free space and folder contents with:

dir Y:\ /s

Once done, unmount the EFI partition to avoid accidental changes:

mountvol Y: /d


After performing the cleanup and freeing up space on the EFI partition, retry the feature update installation. In most cases, the update will now download, install, and complete successfully without rolling back.



Popular Posts

Windows 11 24H2 Upgrade using Intune Feature Updates Policy

Image
How to Deploy Feature Updates Using Intune: A Step-by-Step Guide Microsoft Intune provides a streamlined method for managing Windows feature updates across your organization. In this guide, I'll walk through the essential prerequisites, policy creation steps, deployment, and monitoring process to ensure a smooth rollout of feature updates using Intune. 1. Verify Prerequisites Before you create a feature update policy, ensure the following prerequisites are met on the target devices: Device Enrollment : Devices must be enrolled in Intune, either as Microsoft Entra hybrid joined or Microsoft Entra joined . Supported OS : Devices must be running a supported version of Windows 10 or Windows 11 . Telemetry Settings : Devices must have the telemetry level set to Required . You can configure this via Devices > Windows> Configuration > Create Policy > Templates>  Device Restrictions > Reporting and Telemetry > Share Usage Data >Set as Required...
Read more

Deploying a Script through Intune to a Linux PC

Image
Can Intune Deploy Shell Scripts to Linux Devices? Yes! Just like deploying PowerShell scripts to Windows, Intune can also deploy shell scripts to Linux devices. In this blog, I'll walk you through the process of deploying shell scripts to Linux using Intune, making it easier to automate tasks and manage Linux endpoints efficiently. Prerequisites Before deploying a shell script via Intune, ensure the following requirements are met: 1. Intune and Microsoft Entra ID Your environment must have Microsoft Intune configured for device management. This setup enables secure enrollment and policy enforcement on Linux devices. 2. Linux Device Enrollment The Linux PC must be properly enrolled in Intune to receive policies and scripts. If the device is not enrolled, follow Microsoft's documentation on Linux enrollment in Intune. Deploying the Shell Script Once the prerequisites are met, follow these steps to deploy your shell script through Intune: Access Microsoft Intune Sign in to the ht...
Read more

Deleting Registry.pol and Forcing Group Policy Update Using a Batch File - Deploy through SCCM

  Deleting Registry.pol and Forcing Group Policy Update Using a Batch File - Software update cycle scan failures  In some troubleshooting scenarios ( specially software update cycle scanning errors)  , it is necessary to remove the Registry.pol file to reset Group Policy settings and force an immediate update. This guide outlines how to accomplish this using a batch script and deploy it via SCCM.  Step 1: Create a Batch File Script to Delete Registry.pol and Update Group Policy @echo off setlocal :: Define paths set "RegPolPath=C:\Windows\System32\GroupPolicy\Machine\Registry.pol" :: Check if the file exists and delete it if exist "%RegPolPath%" del /f /q "%RegPolPath%" :: Force Group Policy update gpupdate /force :: Notify user echo Group Policy has been updated successfully. pause Open Notepad. Copy and paste the script above. Save the file with a .bat extension (e.g., ResetGPO.bat ). Step 2: Deploy the Batch Script Using SCCM 1. Create an SCCM Packag...
Read more

Removing Obsolete Computer Records from Active Directory Using PowerShell (Only Windows Client Versions)

  Removing Obsolete Computer Records from Active Directory Using PowerShell Active Directory (AD) environments can accumulate obsolete computer objects over time. These stale records not only clutter the directory but can also pose security risks. This article provides a PowerShell-based approach to identifying and removing outdated computer records from Active Directory. Identifying Obsolete Computer Accounts The first step in cleaning up AD is to identify inactive computers based on their last logon timestamp and password last set date. Below is a PowerShell script to find obsolete devices that have not logged in for more than 60 days: Import-Module ActiveDirectory $DaysInactive = 60 $time = (Get-Date).AddDays(-$DaysInactive) # Identify obsolete devices $obsoleteDevices = Get-ADComputer -Filter { (LastLogonTimeStamp -lt $time -and PasswordLastSet -lt $time) -and (OperatingSystem -like '*Windows 10*' -or OperatingSystem -like '*Windows 11*' -or OperatingSystem...
Read more