|
#azure #windows-server #sysadmin #troubleshooting #security

Azure VM Repair Guide: DISM Component Store Fix + Bootloader Recovery

Guide to fixing DISM Error 0x800f081f in Azure via offline registry surgery and resolving BCD bootloader collisions.

We’ve all been there. You notice a server acting a little quirky, so you drop into an elevated command prompt and run the trusty sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth. You expect a quick "corruption repaired" message, but instead, you trigger a multi-day troubleshooting saga.

Recently, I found myself locked in mortal combat with a Windows Server 2016 machine running in Azure. What started as a routine component store repair spiraled into a nightmare of expired updates, locked registry keys, and the dreaded Error 0x800f081f: The source files could not be found. If you are stuck in a similar Catch-22 with an uncooperative Windows Servicing Stack, here is how I performed offline registry surgery and saved a production Azure VM.

The Catch-22: Hunting for Ghosts

The initial issue was DISM failing to repair the component store. Digging into C:\Windows\Logs\CBS\CBS.log, I found the culprits: the server was missing the catalog files (.mum and .cat) for specific cumulative updates from 2022 and 2023 (KB5023697 and KB5021235).

Normally, you'd just grab these from the Microsoft Update Catalog. There was just one problem: Microsoft had purged those specific updates. They were marked "EXPIRED" and completely wiped from the public catalog. To fix the server, I had to make the OS forget those updates ever existed by deleting their keys from the CBS registry hive.

Phase 1: The Azure Repair Sandbox

You can't do registry surgery live when domain GPOs strip the local Administrator of the SeRestorePrivilege rights (throwing Errors 1314 and 1300). I needed an offline environment.

  1. Snapshot and Detach: Power down the production VM, snapshot the OS disk, and create a new managed disk from that snapshot.
  2. Spin Up a Repair VM: Deploy a temporary, cheap Windows Server VM (a Standard_B2s Spot Instance).
  3. Attach the Clone: Attach the cloned "broken" disk to this Repair VM as a data drive (mounted as F:).

Phase 2: Offline Registry Surgery

With the broken OS asleep on the F: drive, its TrustedInstaller couldn't lock me out. I used PsExec from the Sysinternals Suite to launch a SYSTEM level terminal and bypass all GPO restrictions:

# Launch a SYSTEM-level command prompt
psexec.exe -i -s cmd.exe

In that terminal, I opened regedit.exe, highlighted HKEY_LOCAL_MACHINE, and used File -> Load Hive, navigating to F:\Windows\System32\config\SOFTWARE. I named the loaded hive BROKEN_OS.

I then navigated to the offline servicing packages: HKLM\BROKEN_OS\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages

After taking ownership and granting Full Control to the Packages folder, I ran a FOR loop to exorcise the ghost KBs:

# Find and delete every package key referencing the ghost KBs
for /f "tokens=*" %a in ('reg query "HKLM\BROKEN_OS\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages" ^| findstr /I "KB5023697 KB5021235"') do reg delete "%a" /f

Finally, I unloaded the hive to save changes:

reg unload HKLM\BROKEN_OS

Phase 3: The Offline DISM Repair

With the "ghosts" gone, I ran the offline repair against the attached drive. Without the missing updates confusing the engine, it passed perfectly.

# Run repair against the offline image
DISM /Image:F:\ /Cleanup-Image /RestoreHealth

Phase 4: The Final Boss (Error 0xc000000e)

I swapped the disk back into the Production VM and... Crash. Boot Manager Error: 0xc000000e.

This was an Azure Disk Signature Collision. When I attached the clone to my Repair VM, Windows saw two identical disks and rewrote the signature of the clone. The Boot Configuration Data (BCD) was now looking for a signature that no longer matched.

I attached the disk back to the Repair VM, used diskpart to assign letter S: to the hidden "System Reserved" partition, and rebuilt the bootloader:

# Rebuild the bootloader to point to the new disk signature
bcdboot F:\Windows /s S: /f ALL

The Takeaway

I swapped the disk back into production and it booted flawlessly. An online DISM /ScanHealth confirmed the server was pristine.

The cloud abstracts hardware, but Windows is still just a file system and a registry. When standard tools fail, remember that you can always detach an OS disk, mount it to a sandbox, and operate on it offline. Just make sure you take a snapshot first.