The asker is writing a school-project x64 bootloader in NASM that transitions CPU from Real Mode → Protected Mode → Long Mode, sets up 4-level paging (PML4/PDPT/PD), loads a C kernel at 0x100000, and jumps to it. The kernel never runs — control transfer fails silently.

This is one of the most unforgiving problems in systems programming because everything must be correct simultaneously before you get any feedback. There's no debugger, no printf, no exception trace — just a hung machine or a triple-fault reboot loop.

Why it's hard

• Mode-transition ordering is rigid. To enter long mode you must: (1) disable paging if enabled, (2) enable PAE (CR4.PAE=1), (3) load CR3 with a valid PML4, (4) set EFER.LME=1 via MSR 0xC0000080, (5) enable paging + protection (CR0.PG=1, CR0.PE=1) in the same MOV, then (6) far-jump through a 64-bit code segment descriptor. Skip a step or reorder → #GP or triple fault.
• Identity mapping must cover both the bootloader AND the kernel. If your PML4/PDPT/PD only maps the first 2 MiB, the jmp 0x100000 works, but any kernel code touching addresses beyond that page-faults with no IDT installed → triple fault.
• The C kernel's calling convention/ABI has to match. A freestanding kernel_main compiled with -ffreestanding -mno-red-zone -mcmodel=kernel and linked with a custom linker script placing .text at 0x100000 is required. GCC's default assumes a hosted environment with a red zone — interrupts will clobber stack.
• Kernel loading must actually happen. Many bootloader tutorials show the mode switch but skip the BIOS INT 13h disk-read (or ATA PIO) that copies kernel sectors to 0x100000 while still in real mode. If the asker jumps to 0x100000 without loading anything there, they execute zeros (ADD [RAX], AL repeatedly) until fault.

Direction toward a solution

1. Run under QEMU with -d int,cpu_reset -no-reboot -no-shutdown. This dumps the register state at the moment of triple fault — often revealing exactly which instruction faulted and in which mode.
2. Attach GDB: qemu-system-x86_64 -s -S then target remote :1234, set architecture i386:x86-64. Step through the mode transition and inspect CR0/CR3/CR4/EFER after each write.
3. Verify kernel bytes actually landed at 0x100000 before the far jump (x/16bx 0x100000 in GDB).
4. Confirm the GDT has a valid 64-bit code segment (L-bit set, D-bit clear) and the far jump uses that selector.

Gotcha: A 512-byte MBR bootloader cannot fit the disk-read code, GDT, paging tables, and mode-switch logic. Most working designs use a stage 2 loader that the stage-1 MBR reads off disk first.