> -----Original Message----- > From: Laszlo Ersek [mailto:[email protected]] > Sent: Thursday, September 03, 2015 4:48 PM > To: Larry Cleeton <[email protected]> > Cc: edk2-devel-01 <[email protected]>; Kris Harper > <[email protected]> > Subject: Re: UEFI requirements for 32-bit Windows 8.1? > > So this was extremely painful... > > On 09/03/15 19:44, Laszlo Ersek wrote: > > First of all, thank you very much for responding! > > > > On 09/03/15 19:08, Larry Cleeton wrote: > >> The way I would debug this would be to modify the BCD store in the > >> ISO to turn on debugging in bootmgr, winload, and the windows > >> kernel. > >> > >> The BCD used by bootmgr on the ISO is efi\microsoft\boot\bcd. > >> > >> Extract the ISO files to a writeable file system > > > > Okay, I can do this. > > Right, I managed it. > > > > >> and then modify the BCD. The following commands assume your current > >> directory is at the root of the extracted ISO files. > >> > >> bcdedit /store efi\microsoft\boot\bcd /set {bootmgr} bootdebug on > >> > >> bcdedit /store efi\microsoft\boot\bcd /set {default} bootdebug on > >> > >> bcdedit /store efi\microsoft\boot\bcd /set {default} debug on > > > > I can do this in a Windows VM. > > First roadblock. These commands don't work from PowerShell. Dunno why. > They just don't. I googled the error message and (obviously) StackOverflow > pointed out that I needed to use cmd.exe. Then the commands worked. :) > > (As a precaution against "jitter" I set a baud rate of 38400.) > > >> Recreate an ISO from the files. > > > > Here I have a question. For the ISO image to be bootable under UEFI, > > it needs an appropriate El Torito boot image. I've created such > > before, with "genisoimage", but I'm unsure what I should pack back > > into it when recreating the Windows installer ISO. > > > > Hm... actually I could figure that out, simply by looking at the > > current El Torito image on the original ISO, from the UEFI shell. > > Okay. > > Not okay. :( This did not work *at all*. I recreated the ISO with genisoimage, > best I could. It didn't boot; the boot loader complained about not finding the > BCD file. It was there. > > Anyway... I located the start offset of 256KB original BCD file: > > efi/microsoft/boot/bcd > > in the ISO image: > > en_windows_8.1_pro_n_vl_with_update_x86_dvd_6051127.iso > > I got lucky because the 128 UDF sectors constituting the BCD file were > consecutive. So I modified the BCD file in a Windows VM, then poked it > directly back into a copy of the original ISO, with > > dd \ > if=modified_bcd \ > of=new.iso \ > bs=2048 \ > count=128 \ > seek=1359975 \ > conv=notrunc > > Then I mounted both the original and the modified ISO, and recursively > diffed them. The filesystem was okay on the modified ISO too, and the only > differences were in efi/microsoft/boot/bcd. > > >> Boot the ISO with a Windows debugger "connected" to the VM's COM1. > >> I realize I'm leaving out a lot of details about this "connection" > >> but I'm not familiar with how COM ports are plumbed on other > >> virtualization hosts. > > > > I think I've done this before. I can start another VM with WinDbg > > running in it, and I can connect the virtual COM1 ports via a unix > > domain socket. The *timing* of these virtual COM ports isn't very > > close to the real thing (they're far enough to trip up the UDK > > debugger for example!), but I *think* I've had some success with > > WinDbg. > > ... Then it was only a matter of hours to download & install & configure > WinDbg, connect the virtual machines' COM1 ports via a unix domain socket > (through the libvirt domain XMLs), realize that libvirt insists on associating > COM1 with the primary console of each VM, hence redo the entire BCD thing > for COM2, and finally end up with a working setup. > > Which left me with the following debug output: > > > Microsoft (R) Windows Debugger Version 6.3.9600.17336 AMD64 Copyright > > (c) Microsoft Corporation. All rights reserved. > > > > Opened \\.\com2 > > Waiting to reconnect... > > BD: Boot Debugger Initialized > > Connected to Windows Boot Debugger 9600 x86 compatible target at (Fri > > Sep 4 01:11:18.801 2015 (UTC + 2:00)), ptr64 FALSE Kernel Debugger > connection established. > > > > ************* Symbol Path validation summary ************** > > Response Time (ms) Location > > Deferred > SRV*c:\symbols*http://msdl.microsoft.com/download/symbols > > Symbol search path is: > > SRV*c:\symbols*http://msdl.microsoft.com/download/symbols > > Executable search path is: > > Windows Boot Debugger Kernel Version 9600 UP Free x86 compatible > > Machine Name: > > Primary image base = 0x005ab000 Loaded module list = 0x00725ee8 System > > Uptime: not available > > > > ************* Symbol Path validation summary ************** > > Response Time (ms) Location > > Deferred > SRV*c:\symbols*http://msdl.microsoft.com/download/symbols > > > > The boot selection failed because a required device is inaccessible > (c0000185). > > > > *** Fatal Error 0x00000001 : > > (0x00000005, 0xC0000185, 0x00000000, 0x00000000) > > > > Break instruction exception - code 80000003 (first chance) > > bootmgr!BlStatusError+0x29: > > 005fd405 cc int 3 > > kd> k > > ChildEBP RetAddr > > 00136c9c 005cd406 bootmgr!BlStatusError+0x29 > > 00136ed4 005c8222 bootmgr!BmFatalErrorEx+0x33d > > 00136f10 005c7bff bootmgr!BmpCreateDevices+0x106 > > 00136f48 005c7095 bootmgr!BmpLaunchBootEntry+0xcb > > 00136fe4 00000000 bootmgr!BmMain+0x3d5 > > I'm not at all smarter from this, but I very much hope it helps you help me :) > > Thanks! > Laszlo
I can't apologize for all of Windows. I didn't create it all. Just little pieces of it. :-) Your efforts have confirmed that it is the initial boot loader that is failing (bootia32.efi, aka Windows Boot Manager, aka bootmgr). The stack implies that bootmgr is failing to create the ramdisk that is specified in the BCD as the default boot entry. I vaguely remember a similar issue in insufficient RAM conditions. (If that is the cause, I agree the error reporting is ridiculous.) How much RAM is in your VM? I think Win8 started requiring 2GB minimum but will do best-effort in less. The other possibility is there truly is a failure reading the ISO via the UEFI device driver stack. I hope this helps. --Larry _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
