Details
-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
None
Description
Booting the ReactOS bootcd under UEFI firmware bugchecks in Phase 1 initialisation, before Setup or the live environment starts. The same ISO on the same VM boots normally under BIOS.
Status
Root cause established (instrumented A/B, comments 148452/148454), and a fix is up as PR #9374 ([FREELDR] Implement PCI bus detection on UEFI) — independently tested on QEMU/OVMF i386 against master 340f6cfec4e0: no bugcheck, PCI enumerated, Setup reached; BIOS boot unaffected (comment 148458, with screenshots). The original ARC-index hypothesis in this description was wrong and is retracted; see comments 148452/148454 for the disproof.
Symptom
(/ntoskrnl/io/iomgr/iomgr.c:577) IopCreateArcNames failed: c0000034
|
|
|
*** Fatal System Error: 0x00000069
|
(0x00000000,0x00000000,0x00000000,0x00000000)
|
|
|
Frames:
|
<ntoskrnl.exe ... ntoskrnl/ex/init.c:1849 (Phase1InitializationDiscard)>
|
<ntoskrnl.exe ... ntoskrnl/ex/init.c:2061 (Phase1Initialization)>
|
c0000034 is STATUS_OBJECT_NAME_NOT_FOUND; 0x69 is IO1_INITIALIZATION_FAILED. The loader runs, the kernel loads and the whole boot driver set is pulled in before this happens.
Root cause
The UEFI FreeLoader never reports a PCI bus in the ARC hardware tree (UefiHwDetect() had a literal // TODO: DetectPciBios). Without a MultiFunctionAdapter key with Identifier = "PCI", HalpQueryPciRegistryInfo() returns NULL and HalpInitializePciBus() returns early, so no PCI bus handler is registered, pci.sys enumerates nothing (three devnodes total vs 25+ on BIOS), there is no PIIX3 IDE controller and therefore no \Device\CdRom0 for IopCreateArcNamesCd() to open. The ARC strings FreeLoader hands the kernel are fine — the kernel finds the matching signature and then has no device to open. Full chain with evidence: comment 148452; before/after with the fix: comment 148454.
The ARC index is not the cause: UEFI numbers block devices globally, so the boot CD is cdrom(0) with the hard disk detached and cdrom(1) with it attached, and it bugchecks identically either way.
Fix
PR #9374 implements UEFI PCI detection (ACPI MCFG preferred, CF8/CFC probing with bridge walking as fallback) and reuses the shared DetectPciBios() helper for the hardware tree key. Tested here on QEMU 11.1 + edk2-i386, i386 Debug of master 340f6cfec4e0, same hybrid ISO both firmwares: UEFI no bugcheck and Setup reached with the same '\Device\CdRom0\i386' source path the BIOS run reports; BIOS boot unchanged (multi(0)disk(0)cdrom(96) path intact).
Not this ticket, but newly visible once it stops bugchecking
- The screen stays black under UEFI (Setup runs on regardless — serial proves it). Part of this is FreeLoader itself: UefiInitializeGop() selects GOP mode index 1, which on OVMF/QEMU std VGA hides all of FreeLoader's framebuffer output; SetMode(gop, 0) restores it. Kernel-side output after ExitBootServices is still under investigation (comment 148458 and screenshots).
- Booting with -usb -device usb-tablet now stalls in USBH_PdoStartDevice / hidusb before Setup.
- Booting with /HAL=halacpi.dll bugchecks identically with or without a PCI fix — halacpi.c does not consume the legacy PCI hardware key (comment 148458). Related: CORE-6616.
Reproduction
QEMU 11.1 with the firmware that ships with it:
qemu-system-i386 -m 1024 -M pc -drive if=pflash,format=raw,readonly=on,file=<qemu>/share/edk2-i386-code.fd -drive if=pflash,format=raw,file=<writable copy of edk2-i386-vars.fd> -cdrom <bootcd.iso> -serial file:uefi.log -display none -no-reboot
|
Related
CORE-9119 reports the same IopCreateArcNames failed: c0000034 into bugcheck 0x69, but on real hardware under BIOS, so likely a different root cause with the same symptom. CORE-6616 tracks the default-HAL choice for x86.
