Fix Windows Server 2019 VM Boot Failure: 0xc0000001 INACCESSIBLE_BOOT_DEVICE

Published 2026-03-12 by TechNet New England

After an automatic Windows update, a Hyper-V Generation 1 VM running Windows Server 2019 refused to boot, displaying the dreaded 0xc0000001 error with INACCESSIBLE_BOOT_DEVICE. Here's how we fixed it when all the standard repair methods failed.

The Problem

The VM was working fine until a Windows update installed overnight. On the next boot attempt:

• Error code: 0xc0000001
• Status: INACCESSIBLE_BOOT_DEVICE
• The system couldn't initialize the boot device during kernel startup

This error typically means Windows can't access the system drive during boot - usually due to driver issues, disk corruption, or in this case, registry corruption.

What We Tried (And Failed)

We went through the standard recovery checklist:

1. Boot Configuration Repair

bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd

Result: Commands completed but system still wouldn't boot.

2. System File Checker

sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows

Result: No integrity violations found.

3. DISM Repair

DISM /Image:C:\ /Cleanup-Image /RestoreHealth

Result: Image was healthy, no repairs needed.

4. Update Rollback

Attempted to uninstall the recent update via recovery environment.

Result: Rollback completed but boot failure persisted.

The Actual Fix: Registry Control Sets

After exhausting standard options, we dug into the registry and found the root cause: Windows was trying to boot using ControlSet001, which was corrupted, while a functional Last Known Good configuration existed in ControlSet002.

How Windows Control Sets Work

Windows maintains multiple "control sets" in the registry as fallback configurations:

• ControlSet001 - Usually the current/default boot configuration
• ControlSet002 - Usually the "Last Known Good" configuration
• The Select key determines which control set to use at boot

The Fix

1. Boot from Windows Server installation media or recovery environment
2. Open Command Prompt and launch the registry editor:

   regedit

3. Select HKEY_LOCAL_MACHINE, then click File → Load Hive
4. Navigate to C:\Windows\System32\config\SYSTEM and load it (name it something like "YOURSERVERNAME")
5. Navigate to: HKEY_LOCAL_MACHINE\YOURSERVERNAME\Select
6. You'll see values like:
   • Current - Which control set is currently selected
   • Default - Which control set to use by default
   • Failed - Which control set failed (if any)
   • LastKnownGood - Which control set was last known to work
7. Change Current and Default from 1 to 2 (to use ControlSet002)
8. Highlight the loaded hive and click File → Unload Hive
9. Close regedit and restart the VM

The server booted successfully using the Last Known Good configuration.

Why This Happens

Windows updates modify system drivers and registry entries. If an update corrupts entries in the active control set but the system hasn't had a chance to create a "Last Known Good" snapshot of those changes, you end up with:

• ControlSet001 - Corrupted by the failed update
• ControlSet002 - Still contains the pre-update working configuration

The automatic recovery tools don't check for this scenario - they assume the active control set is correct and try to repair it rather than falling back to a known-good configuration.

Prevention Tips

• Take VM snapshots before updates - A checkpoint before patching makes recovery trivial
• Test updates in a staging environment - Especially for critical servers
• Maintain good backups - VM-level and file-level backups both
• Document your recovery procedures - When it's 2 AM and a server is down, you'll be glad you did

When to Call for Help

Registry editing in a recovery environment isn't for the faint of heart. If you're not comfortable with these steps, or if the fix doesn't work, the issue may be more complex - hardware failure, disk corruption, or deeper system damage. A qualified IT professional can diagnose the root cause and get you back online without risking further damage to your system.