[Help] Unable to boot into windows on Intel NUC 10th Gen

Hi, I have been struggling with quite a strange issue for a couple of days now, I have a bunch of Intel NUCs that have been sat around, and I went to reinstall windows on them all, but 2 of them refuse to boot into Windows under UEFI, I can boot and install in Legacy/CSM mode. These still boot into Linux and other EFI systems fine, just not Windows.

What I have tried so far:

  • Updated the UEFI firmware
  • Disable Secure Boot
  • Default Settings in BIOS
  • Multiple version of Windows 10 and 11
  • Using multiple tools to create the installer:
    • Media Creation Tool
    • Rufus 3.15.1812
    • Rufus 4.6.2208
    • Ventoy 1.0.99
    • Swapping a working installed SSD from another machine
    • Running the bootx64.efi directly from the UEFIShell
  • Using iSetupCfg to copy settings from Working NUC to Non-Working NUC.

None of the above worked, so I started to get a bit more drastic:

  • Using a Raspberry PI I took a dump of all 3 BIOSes
  • Wrote the working BIOS SPI Flash Dump onto the Non-Working NUC
    • This NUC now boots into Windows (Secure boot enabled)
    • All system identifiers, Serial Number and MAC Address are from the working NUC
  • The latest firmware package from ASUS/Intel includes a “.bin” version of the BIOS, I wrote that to the NUC, it boots UEFI but no Secure Mode as no Platform Keys (PKs) are enrolled on the device. All System Identifiers are blank, and MAC Address is something like: 88-88-88-88-88-88

Would be interested to know where I can look, or what I can do to fix the 2 non-working NUCs. I currently have 4 SPI Flash Dumps:

  1. Working NUC - BIOS Version FNCML357-FN0032 FNCML357-FN0032-Vanilla-NUC1.zip (8.2 MB)
  2. Broken NUC - FNCML357-FN0065 FNCML357-FN0065-Broken-NUC2.zip (8.3 MB)
  3. Broken NUC (Not tried to fix) - FNCML357-FN0032 FNCML357-FN0032-Broken Untouched-NUC3.zip (8.2 MB)
  4. Blank Flash Image from ASUS/Intel - FNCML357-FN0065 FNCML357-FN0065-Blank.zip (8.1 MB)

What I would like to do is either:

  • Work out what is broken and modify the dump repairing it and reflashing it to the chip
  • Understand where the System information is stored (MAC/Serial Numbers/OEM-MS License) and extract them from the broken dumps and rebuild from the working/blank dump to create a new version.

Take it from original dumps, NVRAM, GBE etc… UEFI tool / HEX Editor
Plenty of NUC threads to read about it.

I have checked the threads, I have copied the whole part from the Broken BIOS to the Blank BIOS and have the non-booting issue again, I suspect it is some of the entries in the NVAR section, comparing them by eye there’s a few extras in the broken version.

Is it possible to remove specific NVAR entries?

The UEFITool NE doesn’t allow modifications, and the old version of UEFITool shows the whole file as “RAW” rather than an “NVAR Store” in the new version.

Can I just over-write the whole NVAR Entry, or do I need to update a Reference Table?

NA for extraction, the regular for merging, they display different but the data is the same, it needs correct GUID’s/header address etc, identification from user to know what to deal with, in the regular.
It’s kind of expectable merging “parts” of a corrupted image, ending up with a non-go system…again.
Why not edit the relevant data with a hex using a cleared NVRam…
You copy/merge whatever you want…but that’s “blind” moves when the corruption is not isolated/ident

Take a stock Asus bios and transfer GbE region (MAC), padding after NVRAM (Windows code) and parts of NVRAM.
The last part would need a little reconstructing since std- defaults is also a dead link and for NUC 10 format changed and it’s unclear what would be reconstructed and what is needed.


The DMI entries here are at least the ones which are needed, but this bios chains outdated entries and links them, see Link and Full in ‘subtype’ and ‘Next node at offset …’ for the links.

I have very little time for the moment. I’d need the dump of the machine you installed with the naked firmware from Asus to see what’s reconstructed automatically in NVRAM.