golec2604 wrote: I called back to Lenovo, I told him what was going on, he was looking for the matter and was looking for information somewhere and Lenowo claims that Win7 does not officially support UEFI and they can't provide information on how to modify Win7 to work.
Well, get along with them one claims that win7 does not support uefi another or microsoft that is the software producer claims that it supports. Be smart here !!!
I will dig out to finally give
correct answers to this issue. The ignorance of service technicians combined with poor performance of hardware drivers by manufacturers is the reason for such situations as both mentioned above.
Crashing booting WinPE from the Windows installation disk on the screen
Starting Windows This is the result of WinPE using IRQ to enumerate I / O devices. As interrupts simply do not exist in the UEFI ecosystem, there is no right to fail, so the system is left without communication with graphics. The graphics driver used by the WinPE kernel has instructions to wait for the card to respond - which will never come after IRQ.
And here we come to the next thing:
the laptop manufacturer was right that Windows installations older than "eight" are
slightly underdone , because the actual system itself (starting from Win7 up), when it is started by UEFI, enumerates the I / O by calling the firmware function from the "commonly known" call pool reserved for firmware (this is how the kernel communicates with the hardware in UEFI systems, there are no more interrupts here, just ordinary calle, and the UEFI function set is like a linkable PE library for the kernel). Unfortunately - there is an exception and the exception is infamous kernel graphics support.
Let's go into this for a moment
how UEFI works in UEFI-only mode without CSM, and how in UEFI + Legacy mixed mode or even UEFI-only with additionally enabled CSM : as expected, in UEFI-only mode without CSM, all "older" I / O device access technologies are disabled, they do not physically exist for the system. In mixed mode, there are both, but beware - when booting in "legacy" mode, only interrupts will be available for the system, because EFI will not allocate the firmware command table in the memory address pool. However, when booting from UEFI, the firmware will provide the system with both commands and interrupts - and the same will happen when only CSM is enabled!
And now here's the solution: since WinPE flies interrupts and hangs without them, then
you need to start the installer in UEFI mode with CSM enabled but so that it would "fire up" as UEFI.
Problem with Windows Boot Manager not being able to find BCD (when installing the "seven" from the disc from W10), however, results from a slightly different thing - this situation installs because on the system disk, in the ESP partition (i.e. the bootable, normally invisible small FAT32 partition holding only the bootloader and any code decoding the BitLocker encrypted disk) creates is completely mixed up with the confusion - install the bootloader from the installer from "seven" + BCD made by the program called bcdedit.exe from ... Windows 10 (more precisely: from ramdisk unpacked by decimal WinPE). Of course, the BCD backward compatibility with WBM is one-sided (the newer WBM will read the older BCD, not the other way around, and here we have the opposite) - hence the expected message about the inability to read BCD.
It is possible to disable CSM so that the system continues to work properly - after installation you should:
[*: 5a55c0c2b6] install proprietary drivers for the graphics card,
[*: 5a55c0c2b6] disable the embedded system drivers
vga and
VgaSave .
[*: 5a55c0c2b6] to replace Windows Boot Manager with the one from Windows 10 (files with the extension
.efi in catalogs
EFI \ Boot and
EFI \ Microsoft \ Boot on the ESP partition
[*: 5a55c0c2b6] verify that everything works
[*: 5a55c0c2b6] disable CSM [/ list: u: 5a55c0c2b6]
