Boot fails to read registry for Windows 10 21H2 64bit (OS Build 19044, 1387) on NTFS

[natnat-mc]

I've been trying to setup Quibble to boot my Windows partition, with the final objective of moving it to my btrfs partition.

For this, I've tried installing Quibble to my EFI partition, telling it to load from the ARC path multi(0)disk(0)rdisk(1)partition(3)\Windows (which is what the ARC Paths tool told me to use), and adding an ntfs EFI diver to Quibble in EFI\quibble\drivers\ntfs.efi (the one from pbatard/efifs). If this matters, my Windows and EFI partitions are located on a GPT-formatted NVMe SSD, Quibble gets chainloaded by refind, everything is 64bit, and the machine is an MSI GL65 Leopard 10SDR laptop with an MSI BIOS. This happens with CSM enabled or disabled, and with and without Secure Boot (which doesn't block anything anyways).

With this, Quibble detects my Windows installation (Windows 10 21H2, OS Build 19044, 1387 as reported by winver), but fails to load the registry and ultimately to boot. (Windows's native bootloader succeeds to boot my system when chainloaded from refind, and I can access the files from the Windows partition via the EFI shell)

My full freeldr.ini is as follows:

[FREELOADER]
TimeOut=10
DefaultOS=Windows

[Operating Systems]
Windows="Windows"
Windows_Debug="Windows (Debug)"

[Windows]
SystemPath=multi(0)disk(0)rdisk(1)partition(3)\Windows

[Windows_Debug]
SystemPath=multi(0)disk(0)rdisk(1)partition(3)\Windows
Options=/DEBUG

The full error message from Quibble:

Loaded ntoskrnl.exe at fffff80800000000.
Booting NT version 10.0.19041.1387.
load_registry returned EFI_NOT_FOUND
boot returned EFI_NOT_FOUND

(I have no idea why the NT version reported by Quibble doesn't match the one returned by winver)

I haven't tried converting my Windows partition to btrfs yet, as I wanted to make sure Quibble would boot my system before making potentially hard to reverse operations, but if there is nothing to be done to make it boot from NTFS first, I'll try the btrfs conversion.

[maharmstone]

I've not played around with Pete Batard's driver too much. Does it handle case-insensitivity correctly? That would potentially explain why it can't find the SYSTEM file.

[natnat-mc]

Thanks a lot, this pointed me in the right direction. What was happening was that there was a built-in NTFS driver that got automatically loaded by the UEFI, and that failed to read the SYSTEM file when I tested it from the EFI shell. (It seemed to implement case insensitivity, but failed to read large directories, including System32 itself)

Manually forcing it to unload from the EFI shell to get Quibble to use Pete Batard's driver does seem to get me a lot further into the boot process, spending well over 10 minutes loading components from the Windows partition. However, at the very end, it does fail with the same error, after clearing the screen. (The native windows bootloader only takes a few seconds to fully boot the system - seems like a driver performance issue)

I have also tried using the refind NTFS driver, which is a lot faster and goes all the way to the end of the boot process in a few seconds. However, right after the Booting Windows message, the computer restarts instead of actually booting Windows. Neither /DEBUG nor /ONECPU does anything (or at least, anything visible).

So now I guess my problem is that booting restarts the computer instead of actually booting...

[maharmstone]

That sounds a lot like my experience with the Batard drivers - they were too slow to be usable. I do plan to write my own NTFS driver at some point.

I'm a bit behind on Quibble development, I've only updated it to 20H2 so far. Sounds like they've changed things in the later versions.

[natnat-mc]

Thanks a lot for your time with me for this.

[ExoticAtomic]

Saw and tried this yesterday, I have the exact same problem and Windows version, However, my Windows build got its' boot files overwritten a year ago - so I used quibble to try and fix it - yesterday.

My freeldr.ini looks pretty much identical, I used the same ntfs driver after finding out about it from this issue, And it started as soon as I pointed to the correct rdisk in freeldr.ini (without any fiddling with EFI shells or registry problems), However, it also reboots.

Same thing after trying /DEBUG and /ONECPU. Specs: amd64 Gigabyte A520M H - F15 BIOS Windows on ntfs partition on a sata SSD - FAT32 EFI partition on same SSD Windows 10 21H2, OS Build 19044 - Not sure about 1387 as no access to winver