Windows will not boot after migration: diagnose storage and firmware

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

An INACCESSIBLE_BOOT_DEVICE stop after a migration means Windows could not access its system volume during startup. It does not identify one particular driver, and it does not establish that the disk has failed. The useful first decision is where startup stopped: firmware, boot manager, Windows storage access, or encrypted-volume access. That distinction determines what evidence to collect and which specialist procedure might apply.

This is a diagnosis and recovery-planning guide. Its sources were reviewed, but no repair was tested in a lab. It therefore provides evidence requirements and decision criteria rather than commands that rewrite boot files, registry settings or partition tables. A recovery engineer can use the resulting record to select a procedure for the actual operating system and hypervisor.

Recommendations and interpretations are editorial unless attributed; source research is not lab validation.

Preserve the last known state

Before investigating, identify which copy contains the latest accepted business transactions. The old VM is useful evidence, but it is not automatically a current rollback point. If the migrated VM has accepted writes, restarting the source can discard those transactions or create two divergent systems. Record the last successful source shutdown, the target's first start, any application writes, and every configuration change since conversion.

Keep the original disk and conversion logs available. Investigate a separate copy where possible, isolated from production identities and storage. Booting a guest can itself write to the volume, even when the intended task is observation. A snapshot can help compare changes, but it does not replace an independent backup, an encryption key or a plan for reconciling newer transactions.

Capture the exact screen, stop code and time. Record whether a firmware logo, Windows boot manager, recovery prompt or Windows logo appeared first. Keep the VM's disk-to-controller mapping alongside the disk filenames and identifiers. An engineer who knows which disk was attached where can distinguish a missing boot attachment from a driver or firmware mismatch without trying several repairs at once.

Read the failure stage correctly

Microsoft's Stop 7B troubleshooting page lists several possible causes, including controller changes and corrupted boot-partition files. Its stated operating-system scope is Windows 10. The mechanism is useful context, but the article is not evidence that every repair it describes is approved for every Windows Server release.

A missing disk in recovery media deserves a separate investigation from a disk that is visible but cannot be used by the installed operating system. The recovery environment and the installed system run different driver sets. A driver loaded in one does not prove that it exists, is signed appropriately, or starts early enough in the other.

Compare firmware, partition style and boot selection

Record the original BIOS or UEFI setting, Secure Boot state, virtual TPM configuration, boot order and controller type. Compare those with the target before proposing an operating-system change. Proxmox's migration guidance maps legacy BIOS guests to SeaBIOS and UEFI guests to OVMF. Some UEFI guests depend on a registered boot entry rather than the default removable-media path; that entry may not be recreated by copying the Windows disk alone.

Partition style is another item in the record. A GPT indicator identifies a partition table, not proof that this VM currently booted in UEFI mode or that a complete, usable EFI system partition exists. Likewise, the firmware mode of rescue media describes that rescue session. It must not be substituted for evidence about the source VM's previous configuration.

Hyper-V generation adds a platform constraint. Microsoft's generation guidance distinguishes generation 1 BIOS and generation 2 UEFI VMs. Their boot devices differ, and a VM's generation cannot simply be toggled after creation. A conversion plan must choose the correct generation and supported guest combination before treating the problem as a missing driver.

Do not turn a diagnosis into an incidental BIOS-to-UEFI conversion. Microsoft's MBR2GPT documentation is explicitly scoped to Windows 10 and Windows 11. It does not establish a general supported Windows Server disk-conversion procedure. If the project needs a firmware conversion, treat it as a separate, version-supported change with its own prerequisites and tested recovery route.

Identify the complete storage path

A virtual disk reaches Windows through several layers: the hypervisor attachment, the presented controller, the Windows driver package, the driver's startup configuration, and the volume and filesystem stack. Collect evidence at each layer. Record the disk's target controller and unit number, the intended boot device, the controller's device identity, the package version and the guest architecture.

VirtIO SCSI and VirtIO Block are different devices. Their Windows driver folders are commonly vioscsi and viostor; confirm the actual ISO contents and package metadata rather than selecting a package by a similar display name. The driver must match both the controller and the supported Windows release. A successfully staged package is not, by itself, proof that the installed system can boot through that controller.

Microsoft's boot-start driver guidance recommends adding required boot-start packages offline before deployment whenever possible. That is preparation guidance. After a failed migration, the same document helps frame the evidence question: was the required package available to the image before the new device became the boot path?

Proxmox documents a temporary-disk method for letting Windows detect a VirtIO controller before moving the boot disk. The principle is useful, but changing disk attachments is a state-changing intervention. A recovery plan should name the precise disks, supported bridge controller, driver and boot-order verification, then validate that sequence on a copy. Detaching a disk and deleting its backing storage are different actions, and the plan must make that distinction unmistakable.

A successful boot through another controller suggests a difference in the storage path; it does not prove the disk is healthy or that only one driver was at fault. Failure through IDE or SATA also does not clear the controller layer, because those paths need their own working drivers. Match any bridge option to the guest and platform rather than assuming every Windows image can use it.

Treat conversion logs as first-class evidence

virt-v2v can adapt Windows guests and supply VirtIO drivers, but its defaults matter. Its block-driver option distinguishes VirtIO Block from VirtIO SCSI. Record the conversion command, version, driver source and warnings, then compare the selected option with the controller presented by the target platform.

The manual's default-oriented 0x7B check refers to a VirtIO Block interface. That is not a reason to force every converted guest onto that bus when a different supported option was selected. The investigation should reconcile the conversion's actual choice with the target configuration. A warning about missing drivers, a blocked installation or an unsupported guest is more useful than repeating conversion with unchanged inputs.

Driver releases also deserve review. Proxmox's Windows VirtIO driver page records release-specific storage issues and recommendations. Its dated entries are evidence about those combinations, not a permanent promise that one release is safe for every workload. Record the exact package and reproduce the intended guest build, Secure Boot policy and controller in the validation environment.

Separate encryption from boot corruption

A migration changes the virtual hardware that protects encryption secrets. Proxmox states that VMware virtual TPM state cannot currently be migrated to Proxmox VE. A BitLocker-protected disk can therefore request recovery even when its data and boot files are intact. Confirm access to the recovery material before spending the outage window changing the boot configuration.

The virt-v2v manual describes recovery-key requirements where secrets were held in the VMware vTPM. It also notes that Windows 11 guests may be encrypted even when an administrator believes BitLocker was not activated. Inventory actual encryption state rather than relying on recollection. Keep keys in the approved secret store, outside screenshots, ordinary tickets and command transcripts.

Recovery-media capabilities vary. Windows RE includes the WinPE-SecureStartup component, while a custom Windows PE image may omit it. An unavailable encryption-management tool is therefore evidence about the media, not proof about the encrypted disk. The engineer should establish the media version, optional components and controller support before interpreting a failed query or missing volume.

Make boot-configuration evidence attributable

Microsoft includes boot configuration checks in Stop 7B diagnosis. The useful question is whether the installed system's boot manager points to the intended device and loader. In a recovery session, a default boot-configuration query may describe the recovery environment's store. Without an explicitly identified store and partition, its output cannot establish what the migrated Windows installation will use.

Drive letters also change between the running guest and recovery media. Record volume identifiers, sizes and directory contents before assigning meaning to a letter. A path called C: on the old server need not be C: in recovery. The evidence record should connect every referenced path to the identified offline installation.

Registry startup settings, filter drivers and pending servicing operations can be relevant, but they are not universal switches to toggle. A boot-start value alone does not prove that a package is complete, signed, matched to the device or free of filter-driver dependencies. Collect the package identity and recent change history, then select a Microsoft-supported investigation for the installed release.

Reverting pending servicing, removing registry values, rewriting boot files and repairing filesystems all change the evidence and can affect recoverability. They require a distinct decision supported by the observed failure. Microsoft's DISM documentation limits pending-action reversal to recovery scenarios involving an image that did not boot; it is not a routine migration-cleanup operation.

Turn the findings into a recovery decision

Give the recovery engineer a proposed change, an expected observation and a stopping condition. For example, a storage-path hypothesis predicts that the same isolated disk copy will boot through a supported controller once the matching driver preparation is complete. If the result differs, preserve the new logs and revisit the hypothesis instead of adding unrelated repairs.

Define success beyond the Windows logo

A successful boot is the first acceptance gate. Confirm that every expected volume is present, encryption is in the intended state, Device Manager and system logs show no unresolved storage fault, and the application can read its data. Then test a controlled application transaction, restart behaviour and the new platform's backup and restore path.

Record which copy is now authoritative and how any writes made during testing are handled. Keep the source isolated until business acceptance and the agreed retention period. If the target has newer data, a return to the source needs reconciliation or a supported reverse path. The result should be a documented recovery decision with evidence, not merely a VM that reached the desktop once.

Sources

Source research checked 2026-11-10; commands were not lab tested.

• Microsoft: Advanced troubleshooting for Stop error 7B
• Microsoft: Specifying driver load order
• Microsoft: Install a boot-start driver
• Microsoft: INF AddService directive
• Microsoft: Add and remove driver packages to an offline image
• Microsoft: DISM driver servicing
• Microsoft: DISM operating system package servicing
• Microsoft: WinPE optional components reference
• Microsoft: Drvload
• Microsoft: BCDBoot
• Microsoft: Bootsect
• Microsoft: MBR2GPT
• Microsoft: Boot to UEFI mode or legacy BIOS mode
• Microsoft: Hyper-V generation 1 or 2
• Microsoft: BitLocker recovery overview
• Microsoft: manage-bde status and manage-bde unlock
• Microsoft: reg save
• Microsoft: Windows Recovery Environment
• Proxmox: Migrate to Proxmox VE
• Proxmox: Paravirtualized Block Drivers for Windows
• Proxmox: Windows VirtIO Drivers
• Proxmox: Windows 2022 guest best practices
• Broadcom: PVSCSI controllers (1010398)
• libguestfs: virt-v2v manual

This article was originally published on 10 November 2026.