Encontrei esse problema recentemente e, após vários dias de depuração, descobri o problema e o corrigi.
Por favor, rufem os tambores:
Depois de instalar o Hyper-V Server 2016, use uma ferramenta offline (como, por exemplo, o Windows PE) para montar a seção SYSTEM da nova instalação e altere o DWORD ControlSet001 \ Control \ BootDriverFlags de 0x04 para 0x1c. (Você provavelmente deve alterar a versão do ControlSet002 também por uma boa medida, e pode fazer as alterações no install.wim para evitar a necessidade de fazer isso após cada instalação.)
(Porque é claro que leva uma semana e um depurador do kernel para descobrir que isso requer apenas uma alteração de dois bits em um campo de bits obscuro e completamente não documentado.)
Aqui está o porquê.
O carregador de inicialização do Windows usa rotinas UEFI internas para encontrar a instalação do Windows e carrega o kernel e os drivers de inicialização na RAM antes de chamar ExitBootServices. Depois de fazer isso e passar o controle para o kernel, o kernel não pode acessar o volume de inicialização, a menos que os drivers apropriados já estejam presentes na RAM.
Aqui está o exemplo: o winload.efi não é complexo o suficiente para enumerar o hardware e determinar quais drivers são realmente necessários. Nas versões anteriores, ele carregava apenas as coisas definidas para o Boot Start. No entanto, o carregamento de drivers externos incorre em uma penalidade de desempenho e, quando o Windows começou a oferecer suporte a mais classes de dispositivos de inicialização, era necessário um sistema melhor.
Digite o valor BootFlags em drivers individuais e o valor BootDriverFlags em todo o sistema. Se (BootFlags & BootDriverFlags)! = 0, o driver será carregado, mesmo que não esteja definido como Boot Start. Cada bit no valor deve corresponder a um tipo diferente de hardware, portanto, o valor BootDriverFlags define de quais tipos de hardware podem ser inicializados.
Quando esse mecanismo foi introduzido, o Bit 3 foi designado para dispositivos de inicialização USB, mas a inicialização a partir de dispositivos USB não era suportada no Windows padrão. A versão do Hyper-V Server 2008 R2 adicionou suporte específico para a inicialização a partir do USB, definindo esse valor como 0x04, e esse valor foi definido em todas as versões do Hyper-V Server lançadas desde então.
As melhorias gerais feitas desde então para oferecer suporte ao recurso Windows To Go significam que você não precisa usar o truque de inicialização em VHD recomendado para versões anteriores do Hyper-V Server instaladas em dispositivos USB. No entanto, eles também alteram o significado do valor BootDriverFlags. Os dispositivos USB 3 receberam um bit separado e os cartões SD, especificamente, outro bit.
Na versão 2016, isso significa que um valor de 0x04 agora permite a inicialização apenas a partir de discos USB2 que não são cartões SD. Todas as versões do Server 2016, exceto o Hyper-V Server, são fornecidas com o valor padrão de 0x1c, que permite a inicialização do cartão USB2, USB3 e SD; no entanto, o valor 0x04 ainda está definido no Hyper-V Server, porque foi adicionado como uma substituição no processo de criação da imagem para a versão 2008R2. Em vez de adicionar um recurso, esse valor agora o remove.
Isso explica por que algumas soluções anteriores para esse problema recomendaram desativar o USB3 e inicializar a partir de um dispositivo USB em vez do cartão SD: isso forçaria a categoria do dispositivo de inicialização a ser algo ainda coberto pela definição agora mais limitada do "USB "em BootDriverFlags.