On 09/03/15 17:51, Brian J. Johnson wrote: > On 09/03/2015 05:08 AM, Laszlo Ersek wrote: >> Hi, >> >> 64-bit Windows 8.1 boots on QEMU + OVMF just fine. (The "pc" (i440fx) >> machine type of QEMU has "always" worked, and we recently fixed "q35" >> too.) >> >> However, 32-bit Windows 8.1 (ie. the installer of it) crashes with a >> BSoD on the 32-bit build of OVMF *immediately*. This happens regardless >> of the QEMU machine type. The error message I'm getting is: >> >> http://people.redhat.com/~lersek/windows-on-ovmf32/win8-ovmf32.png >> >> According to <https://msdn.microsoft.com/en-us/library/cc704588.aspx>, >> the error code 0xc0000185 means "STATUS_IO_DEVICE_ERROR". >> >> I also tried with Windows 10: >> >> http://people.redhat.com/~lersek/windows-on-ovmf32/win10-ovmf32.png >> >> Here I get 0xc000000d, "STATUS_INVALID_PARAMETER". >> >> The Windows ISOs I tried with were: >> - en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso >> - en_windows_10_enterprise_2015_ltsb_n_x86_dvd_6848317.iso >> >> Can someone please help me debug this? The difference between x64 and >> x86 is "inexplicable". > > I've worked through some firmware issues on older MS releases, but never > Windows 8 or 10. So this advice may be out of date. Do you know if > Windows got through the boot loader and is starting the kernel?
This is a good idea. So here's what I did: - I built the FAT driver from source, as part of OVMF. Because, the FAT driver logs names of files being opened on EFI_D_INFO level, and I wanted to see those. - I added a short log message to CoreExitBootServices() in "MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c". This is the end of the OVMF debug log, before the BSOD hits (the log excerpt has been filtered through my sed script that replaces GUIDs with protocol names): > Booting EFI SCSI Device > BlockSize : 2048 > LastBlock : 15C05E > BlockSize : 2048 > LastBlock : 7 > FatDiskIo: Cache Page OutBound occurred! > FSOpen: Open '\EFI\BOOT\BOOTIA32.EFI' Success > FSOpen: Open '\EFI\BOOT\BOOTIA32.EFI' Success > InstallProtocolInterface: [EfiLoadedImageProtocol] 7F47DDE8 > Loading driver at 0x00010000000 EntryPoint=0x00010005420 cdboot.efi > InstallProtocolInterface: [EfiLoadedImageDevicePathProtocol] 7F481F10 So, ExitBootServices() is not called, and the crash occurs before cdboot.efi loads any other file. > If so, > you can turn on extra debug messages to show the drivers as they are > loading. That can give you some good clues. If that's not enough, you > can enable remote debugging and use MS's debuggers (eg. WinDbg) and > symbol tables to get an idea of the call chain which is failing. It's > been a long time since I've done this, so I'm rusty on the specifics... > searching on msdn.microsoft.com should get you going. > > Historically, Windows has been extremely picky about ACPI tables, much > more so than Linux. Boot issues often have to do with ACPI details. It > has also had some quirks re. what it expects in the EFI memory map, > although those have mostly related to really large systems (eg. PCIe > segment layout.) > > I see you CC'd some folks at Microsoft. Hopefully they will be able to > give you more specific advice. Thanks! Laszlo _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
