Hi Bear,
Thank you for reaching out.
The DISM 1009 and the reg load error are both pointing at the same thing: the COMPONENTS registry hive on the server (C:\Windows\System32\config\COMPONENTS) is corrupt and Windows can't read it. That hive is what the servicing stack relies on, so until it's healthy, Windows Update, DISM, and any feature/role install will keep failing in the same spot.
The tricky part is that the usual in-OS repair tools (SFC, DISM /RestoreHealth) lean on the same hive to do their work, so they can't fix it from inside the running system. We'll need to repair it from outside the OS.
Action Plan:
- Snapshot first. Take an EBS snapshot of the server's root volume before anything else, just so we have a clean rollback point if needed.
- Repair via a rescue instance. Stop the server, detach its root volume, and attach it to a second Windows instance in the same AZ. From there we can restore the
COMPONENTShive — specifically all three files (COMPONENTS,COMPONENTS.LOG1,COMPONENTS.LOG2) as a set — from a pre-failure snapshot, AMI, or VSS shadow copy if one exists. - Reattach and verify. Put the volume back on the original instance, boot it up, and run
DISM /RestoreHealthagainst a matching Server 2025 ISO to confirm the component store is healthy again. - If no good backup of the hive exists, the cleanest supported path is an in-place upgrade using matching Server 2025 media (keeps apps and data, rebuilds the servicing stack), or a rebuild from a clean AMI with roles and data migrated over.
Please let me know if you need further clarification. Thank you so much.
Nhu