When Windows XP boots without AHCI drivers on a SATA system, you get a BSOD like 0x0000007b
.
What I don't understand is why it can't load without AHCI drivers. Clearly it was already able to load the kernel code that gives you the BSOD, so why couldn't it load the rest of the OS the same way?
Alternatively: All forms of ATA support Programmed I/O, and IIRC Windows XP supported PIO as well. So they could've loaded the rest of the OS using PIO too... couldn't they?
Windows uses INT13h (BIOS) access to hard disks only at the very earliest stages. If during this time no suitable Windows driver for accessing the disk is loaded, the blue screen pops up.
INT13h is only available in Real Mode. Modern Windows, however, runs in Protected Mode or Long Mode (x64).
On native UEFI (as in: when not using the CSM), INT13h isn’t available. Windows (presumably) uses UEFI services to access disks in this environment.
Response to edit: Whether your SATA controller runs in AHCI mode or not is not controlled by the operating system. Instead, you select which to use in the firmware settings. The firmware sets the corresponding bits in the controller’s registers.
Virtual 8086 mode is just that: virtual. It does not provide access to real BIOS features. Instead, the host must emulate these features.
Although I’m no expert I find it very likely that switching back to Real Mode would discard important information in the MMU and whatnot, not to speak of the implications of halting all things Protected Mode just to access the disk.
User contributions licensed under CC BY-SA 3.0