In the meantime, I was instructed to install Windows 7 and see if my method worked for that OS to see if Win10 was causing me an issue. After installing Win7, I ran into what appears to be the same issue. Upon trying to boot, Windows tells me that it's unable to find drivers for my boot device. This coincides with Win10 and tells me that Windows is truly not loading the drivers necessary for it to find the hard drives. Is there some way I can track what drivers Windows loads during boot? I figure if I track a working boot method and my non-working boot method, I can find the missing drivers needed and then find a way to force Windows to load them during/after Grub4Dos.
No.
The issue is not at driver level, it happens earlier.
Both the Windows 10 and the Windows 7 work just fine (by themselves and after a "clean" BIOS boot).
Either your Linux distro (more likely) or kexec (less likely) destroys *something* in the BIOS values.
When you chainload BOOTMGR, it:
1) reads in real mode *something* in these BIOS values
2) passes these values to "self" and when it switches to protected mode uses these vaues to load drivers.
If these values are wrong or missing the driver cannot be loaded or cannot be loaded properly.
It is possible - at least in theory - that you could:
1) boot BIOS->grub4dos (or BIOS->GRUB2->grub4dos)
2) from grub4dos dd/save a portion of memory (containing these values)[1]
3) proceed to your Linux, verify whatever you need to verify and kexec to grub4dos
4) from grub4dos restore this portion of memory
5) proceed to chainload BOOTMGR with the right values
Knowing which locations of memory contain these values will be the hardest part (personally I do not have any idea from where to start, though you could make two "full"[2] memory dumps and compare them).
Besides it is also possible that *something* in either your Linux or kexec "locks" some BIOS interrupts.
Wonko
[1] the a1ive's version of GRUB2 does have a dd command so it might be possible to use directly that GRUB2
[2] let's say from 0x00000000 to 0x00FFFFFF for a start, though modern BIOS tend to use higher addresses, hopefully you can run BIOS function INT 15h, EAX=0xE820
https://wiki.osdev.o...emory_Map_(x86)
https://wiki.osdev.o..._EAX_.3D_0xE820
from grub4dos