Windows: Incorrect disk layout causes trouble with updates and feature upgrades

[German]If the disk layout on Windows machines does not comply with Microsoft specifications, this can quickly lead to trouble. During update installation, rollbacks occur and the installation of the feature updates fails due to an error message. Here is a summary of what you should know and observe.

German Blog reader Martin Feuerstein contacted me by mail in mid-November 2020 and reported about two issues with the installation of cumulative and feature updates. Both could be traced back to the partition layout.

• In the first case Martin wrote: have been working on a case the days when an older laptop (officially not even supported for Win10) had problems with the feature update from 1809 to 1909. Cause: partition layout (installed for MBR – but the BIOS does support UEFI).
• Two days later, a long smouldering problem with regular Windows updates on two servers (2012 R2 and 2016) was solved. Cause: Partition layout (UEFI). The servers were previously migrated from ESX to Hyper-V.

So different issues, but same cause. Solution is actually "only" the conversion from a – after all bootable – MBR layout to a UEFI-compliant layout. In theory, there are already tools (MBR2GPT, GPTGen) for a smooth conversion, but in practice only the mace (backup + delete partitions + restore) worked.

Case 1: Setup exits during feature upgrade

In the first case a notebook should be upgraded from Windows 10 version 1809 to a newer Windows 10 build. The notebook is a Fujitsu Lifebook E752, is about 8 years old. There are no settings in the BIOS/UEFI regarding Secure Boot or CSM (Compatibility Support Module). When starting Windows, as with other non-UEFI devices, the Windows flag is displayed and no manufacturer logo, as would be usual with UEFI. No reference to UEFI.

Problem with this device is that the setup already at startup displays the error Windows cannot be installed because this PC has an unsupported disk layout for the UEFI firmware (I've translated the German error message shown within the below screen shot).

What is the root cause? The partition layout did not fit the requirements from this Microsoft manual. Here is the the data layout obtained with diskpart in the command prompt window.

It's an obvious problem, but annoying, because there is a Windows 10 running and only an upgrade should be done. The solution: Change the layout of the hard disk to Microsoft's requirements and then install it.

Case 2: Windows servers update roll backs

The second case involved two Windows servers, one VM with Server 2012 R2, one VM with Server 2016, which after cumulative update installation fell into roll backs during the boot phase, while other updates (e.g. Office) are installed without error message. The VMs were previously migrated from VMWare ESX to Hyper-V. Other servers in the same domain do not show any abnormalities, until before the migration there were no problems with the updates either.

No indication of an error in the event log, except that the updates cannot be installed. But an error is shown in the CBS (Component-Based Servicing) logs in c:\Windows\Logs\CBS that the boot partition was not found:

(CBS-Log, Click to zoom)

The log file contains entries like shown below:

Microsoft-Windows-BootEnvironment-Core-BootManager-PCAT
Installer name: 'Boot File Servicing (BFSVC) Installer'
                BFSVC: 'Failed to get system partition! Last Error = 0x3bc3'
Boot File Servicing (BFSVC) Installer ({c5f0e9d7-e844-4507-89e4-701b5a747221}) with HRESULT HRESULT_FROM_WIN32(15299)

So it was clear that the partition layout was also involved. Martin writes:

The VMs were previously run as a BIOS machine with MBR layout, but after the conversion they were run as Gen2/UEFI VMs under Hyper-V. For simplicity, a FAT32 partition for the boot loader was written to an MBR disk and the operating system was written to an NTFS partition

Background knowledge about partition layout

Previously the MBR layout was defined as the standard for hard disks – i.e. up to four primary partitions can be created on a disk, the boot partition (the partition with the boot manager) is set "active". Works this way since the introduction of MS-DOS. To create more than the four partitions per disk an extended partition can be created which itself contains logical partitions.

• Classic BIOS installation from Windows Vista upwards with MBR disk layout look like this: A partition for the boot manager is created, this partition is set active, the operating system is installed on a separate partition. For BIOS installations the boot partition can be formatted either with FAT32 or NTFS, the BIOS does not care. The Windows partition has to be formatted with NTFS (I don't remember whether the Vista/7 installation created an NTFS or FAT32 partition).
• UEFI installation: A partition for the boot manager is created, this partition *must* be formatted with FAT32, otherwise the UEFI cannot start the boot manager. The operating system partition is formatted with NTFS as usual for Windows. UEFI is intended for use with a GPT disk layout which does not know an active partition – In UEFI the path to the boot manager is entered on a FAT32 partition by the operating system. Reading the boot manager from the first FAT32 partition is rather a fallback solution.

Windows will start regardless of whether a BIOS or UEFI (with or without CSM) is present, provided that the boot manager can be read from a partition. For the BIOS (MBR layout) the active set partition is decisive, for UEFI the entered path to the boot manager. Alternatively UEFI also loads boot loaders from a FAT32 partition without this partition being entered in UEFI.

With an MBR layout, the FAT32 boot partition (set active for MBR) and the operating system partition, we now have a disk that can in principle boot on a BIOS computer and a UEFI computer. So everything is fine, isn't it?

Repair BCD entries with bcdboot, Click to zoom

Note: When setting up the boot manager using BCDBoot you can specify which boot method should be set up: either BIOS (/f BIOS), UEFI (/f UEFI) or a hybrid (/f ALL), which can do both.

How to solve the the update and feature update installation issues?

Basically the disk layout for the UEFI boot must be changed to GPT and a corresponding boot manager must be written. The Windows disk management does not allow the subsequent conversion of the system disk, so the disk would have to be reinitialized with the GPT layout and the operating system would have to be reinstalled.

But for the conversion there are e.g. the on-board tools MBR2GPT (didn't work for me) or GPTGen (didn't work for me either, or I didn't use the right parameters). Other partitioning programs (mostly for a fee, at least for business customers) may be able to do MBR-GPT partitioning, but Martin have not tried them. He performed the following steps:

1. Backup operating system partition

This can be done, for example, with DISM, a Microsoft tool, in a recovery environment

DISM /Capture-Image /CaptureDir:"c:\" /ImageFile:"d:\os.wim" /Name:"Betriebssystem"

For additional partitions on the disk, DISM must be executed again accordingly

2. Reinitialize the data medium

The disk will be reinitialized according to this MS document – below these drive letters are assumed:

c:\ – operating system partition
d:\ – disk containing the operating system backup
z:\ – boot partition

3. Restore operating system and create boot manager

The operating system is restored to the newly created partition

DISM /Apply-Image /ImageFile:"d:\os.wim" /Index:1 /ApplyDir:c:\

Then the boot manager is written to the newly initialized disk to make the operating system bootable:

BCDBoot c:\windows /l de-de /s z:\ /f UEFI

After these steps the system should be able to install updates or function updates as usual. Thanks to Martin for this write up. Maybe it will help somebody.