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
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to