Encontré este problema recientemente, y después de varios días de depuración, descubrí el problema y lo solucioné.
Redoble de tambores por favor:
Después de instalar Hyper-V Server 2016, use una herramienta fuera de línea (como, por ejemplo, Windows PE) para montar la sección SYSTEM de la nueva instalación, y cambie DWORD ControlSet001 \ Control \ BootDriverFlags de 0x04 a 0x1c. (Probablemente también debería cambiar la versión ControlSet002 para una buena medida, y puede incluir los cambios en su install.wim para evitar tener que hacer esto después de cada instalación).
(Porque, por supuesto , lleva una semana y un depurador de kernel darse cuenta de que solo requiere un cambio de dos bits en un campo de bits oscuro y completamente indocumentado).
Este es el por qué.
El gestor de arranque de Windows utiliza rutinas UEFI integradas para encontrar la instalación de Windows, y carga el núcleo y los controladores de arranque en la RAM antes de llamar a ExitBootServices. Una vez que haya hecho eso y haya pasado el control al kernel, el kernel no podrá acceder al volumen de arranque a menos que los controladores apropiados ya estén presentes en la RAM.
Sin embargo, aquí está el truco: winload.efi no es lo suficientemente complejo como para enumerar el hardware y determinar qué controladores son realmente necesarios. En versiones anteriores, solo cargaba cosas configuradas en Inicio de arranque. Sin embargo, cargar controladores extraños conlleva una penalización de rendimiento, y cuando Windows comenzó a admitir más clases de dispositivos de arranque, se necesitaba un mejor sistema.
Ingrese el valor de BootFlags en controladores individuales y el valor de todo el sistema BootDriverFlags. If (BootFlags & BootDriverFlags)! = 0, el controlador se cargará incluso si no está configurado en Boot Start. Se supone que cada bit en el valor corresponde a un tipo diferente de hardware, por lo que el valor BootDriverFlags establece desde qué tipos de hardware se puede iniciar.
Cuando se introdujo este mecanismo, Bit 3 fue designado para dispositivos de arranque USB, pero el arranque desde dispositivos USB no era compatible con Windows estándar. La versión Hyper-V Server 2008 R2 agregó soporte específico para el arranque desde USB al establecer este valor en 0x04, y este valor se ha establecido en todas las versiones de Hyper-V Server lanzadas desde entonces.
Las mejoras generales realizadas desde entonces para admitir la función Windows To Go significa que no tiene que usar el truco de arranque a VHD recomendado para versiones anteriores de Hyper-V Server instaladas en dispositivos USB. Sin embargo, también cambian el significado del valor BootDriverFlags. A los dispositivos USB 3 se les ha dado un bit separado, y las tarjetas SD específicamente se les ha dado otro bit.
En la versión 2016, esto significa que un valor de 0x04 ahora permite arrancar solo desde discos USB2 que no son tarjetas SD. Todas las versiones de Server 2016, excepto Hyper-V Server, se envían con el valor predeterminado de 0x1c, que permite el arranque de USB2, USB3 y tarjeta SD; sin embargo, el valor de 0x04 todavía se establece en el servidor Hyper-V, ya que se agregó como una anulación en el proceso de creación de imágenes para la versión 2008R2. Sin embargo, en lugar de agregar una característica, este valor ahora la elimina.
Esto explica por qué algunas soluciones anteriores a este problema recomendaban desactivar USB3 y arrancar desde una memoria USB en lugar de la tarjeta SD: esto obligaría a que la categoría del dispositivo de arranque sea algo que todavía está cubierto por la definición ahora más limitada del "USB "mordió en BootDriverFlags.