Overview

This knowledge base article describes a boot failure affecting specific HP EliteBook G11 devices after installing the Windows update KB5075941 on Windows 11 23H2 when Full Disk Encryption (FDE) is enabled using older FDE versions. The issue does not occur with newer FDE releases starting from version 25.4 / 26.1.
Systems running these versions are not affected. After the update is applied, affected systems fail to boot into Windows and remain in a pre‑boot or recovery state. The issue has been observed irrespective of the Secure Boot configuration and currently appears to be limited to specific HP EliteBook models.
This article outlines the affected environment, symptoms, scope, and provides detailed instructions for collecting diagnostic logs and restoring the EFI boot environment to recover impacted systems.

Affected Environment 

• Operating System: Windows 11 23H2
• Windows Update: KB5075941
• Hardware Models:
  • HP EliteBook 640 G11
  • HP EliteBook 660 G11
• Encryption: 
  • Full Disk Encryption (FDE) enabled
  • Affected FDE Versions: Older FDE versions below 25.4 / 26.1
  • Secure Boot: Enabled or disabled (issue occurs in both configurations)

Symptoms

Affected systems show one or more of the following symptoms after installing Windows update KB5075941:

• Windows fails to boot after system restart
• System remains in a pre‑boot or recovery state
• No successful transition from EFI boot phase to Windows
• Reboot loops or inability to reach the Windows login screen

Known Conditions and Scope

What Is Known

• The issue occurs after installing Windows update KB5075941
• Only observed on Windows 11 23H2
• Full Disk Encryption (FDE) is enabled (only older FDE versions below 25.4 / 26.1)
• Secure Boot state does not influence the occurrence
• Currently limited to HP EliteBook 640 G11 and 660 G11

What Is Currently Not Affected

• Other HP models
• Devices from other hardware manufacturers
• FDE versions 25.4 / 26.1 and newer

Log Collection (EFI / FDE Diagnostics)

To allow further analysis, EFI and FDE diagnostic logs must be collected from the affected system.

Prerequisites

• Latest Full Disk Encryption Package from the Matrix42 Marketplace
• USB stick
• Tool for creating bootable USB media (for example, Rufus)

Preparation

• Download the latest Full Disk Encryption Release from the Matrix42 Marketplace.
  • Extract the EgoSecure-Full-Disk-Encryption-by-Matrix42.zip file
  • Extract Extension Packages.zip (e.g. EgoSecure Full Disk Encryption by Matrix42 26.1.0.0.Ext-Pkgs.zip)
• Use the winpe-x86-64.zip and create a bootable USB stick using Rufus.

Create Log Files

• Boot the affected system from the WinPE USB stick.
• After WinPE loads, the FDE Recovery GUI appears automatically.
• Navigate to Administration → Collect Log Files.
• The created Log files are now stored under:

  • X:\FDE_DevLogs\

• Use the visible command shell to navigate to the directories

Copy Log Files

1. Copy the following files to the USB stick:

From X:\FDE_DevLogs\

• pe_erd_w32.log
• efi_partition_dir.log (important)
  • This log is used to verify whether the file ebootmgfw.efi is present in the EFI\Microsoft\Boot directory.
  • If this file is missing, it is likely the root cause of the boot failure.
• setupact.log
• setupapi.dev.log

From X:\

• pe_erd_w32.log
• Logfile.log

Note: If efi_partition_dir.log is not found, also check:

• X:\
• X:\SYS\

2. Move the USB stick to a working system.
3. Compress all collected files into a single ZIP or RAR archive.
4. Provide the archive to support for further analysis.

EFI Boot Restoration (Recovery Procedure)

If immediate system recovery is required, the EFI boot configuration can be repaired using the following procedure.

Overview and Caution

This procedure restores the Microsoft bootloader in the EFI system partition. It should only be performed by experienced administrators.

Download and Replace Shell

• Download a custom Shell.efi from Github that enables execution of EFI-level commands like BIOS and Firmware updates (NIC / RAID controllers)
  • Download Link: Github
• Now open the WinPE USB stick and navigate to:

  • EFI\Boot\

• Within this folder: 
  • Rename the existing bootx64.efi to e.g. winpe-loader.efi
  • Copy the recently downloaded Shell.efi it into the folder
  • Rename Shell.efi to bootx64.efi

Restoring the Microsoft Bootloader Using Backup File

• Configure the USB stick as the first boot device in the BIOS.
• Boot the system to load the UEFI Shell.
• Identify the correct file system mapping (fs0, fs1, fs2, …).
• Enter a file system and list its contents:

  • fs0:
    ls

  • If \EFI\Microsoft\Boot or \EFI\EgoSecure\Boot exists, this is the system EFI partition.
• Restore the Microsoft bootloader using the backup file:

  • cp fs0:\EFI\Boot\bootx64.bak fs0:\EFI\Microsoft\Boot\ebootmgfw.efi

  • Note: 
    • bootx64.bak is the original Microsoft bootloader backed up during FDE installation.
    • This should allow the system to boot Windows again.

Recommended Recovery Using Latest Windows Bootloader

This is the preferred recovery option.

• Mount a Windows 11 ISO matching the installed Windows version.
• Copy the file:

  • EFI\Boot\bootx64.efi

• Place the file on the WinPE USB stick (for example: fs1:\MSBootLoader\bootx64.efi).
• Boot into the UEFI Shell and copy the bootloader:

  • cp fs1:\MSBootLoader\bootx64.efi fs0:\EFI\Microsoft\Boot\ebootmgfw.efi

• Replace the backup bootloader as well:

  • cp fs1:\MSBootLoader\bootx64.efi fs0:\EFI\Boot\bootx64.bak

• After successful boot, the latest Microsoft bootloader can also be applied directly from within Windows.

Post‑Recovery Notes

• Verify that Windows boots normally
• Ensure FDE functionality is fully operational
• Apply any additional updates only after validation

Summary

• A boot failure may occur on HP EliteBook 640 G11 and 660 G11 after installing Windows update KB5075941
• The issue affects Windows 11 23H2 systems with older FDE versions enabled
• Secure Boot status does not change the behavior
• Diagnostic logs can be collected using WinPE
• EFI boot restoration allows affected systems to recover
• Other hardware manufacturers are currently not affected