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? 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.
--
Brian J. Johnson
--------------------------------------------------------------------
My statements are my own, are not authorized by SGI, and do not
necessarily represent SGI’s positions.
_______________________________________________
edk2-devel mailing list
[email protected]
https://lists.01.org/mailman/listinfo/edk2-devel