Hi. Does anyone know where I can possibly order / purchase a plastic bracket for Asus / Intel NUC ? I believe gen 11 -15 use the same bracket. Just can’t find it anywhere. Need a simple bracket, not one with additional ethernet / serial port.

Security Patch:

•Update for BDS Module Bypass Secure Boot Advisory

•Update for UEFI OOBE Write and Buffer Overflow Vulnerabilites

•Intel platform update (IPU2026.1)

•Intel platform update (IPU2026.1)

Feature Change/Update:

•Change for ISetupCfg Tool cannot modify power limit value

•Update for iFlashV to tool package

•Change for the default board product name

Issue Fix:

•Fix for the size of dbx is increased for SA50315

•Change for the Processor name.

Known Errata:

•Bitlocker Recovery will be occurred after reload Secureboot key in Setup since SN0064 has updated Secure Boot DBX

[FIX] NUC 12 Enthusiast (Serpent Canyon) boot-loops with a Thunderbolt eGPU powered on — hidden "USB4 CM Mode = CM Debug"

EDIT: The first version of this post recommended disabling the hidden "PCIE Resizable BAR Support" + the Failsafe Watchdog. After longer use one thing is certain: that combo is unstable — sometimes the machine booted, sometimes it didn't, with the settings verified intact between attempts. On top of that, any Save & Exit in BIOS Setup silently re-enables the hidden ReBAR (see the trap below). The post now describes the fix that has held through everything we threw at it: USB4 CM Mode = CM Debug.

• survives BIOS visits (F10 / Save & Exit) — nothing to re-import afterwards,
• cold boot with the enclosure powered, warm restart right after heavy GPU load, and a power outage (both devices regaining AC at once) all pass,
• no performance cost — the eGPU ends up in exactly the same state as a hot-plug (PCIe 4.0 x4, BAR1 256 MiB).

TL;DR: My NUC12SNKi72 would not boot with a powered TB eGPU attached (GIGABYTE AORUS RTX 5060 Ti AI BOX): it resets over and over before Windows ever loads, and while the enclosure is powered you can't even get into Setup (F2). No visible BIOS toggle helps. The fix is one hidden BIOS option, USB4 CM Mode = CM Debug: the firmware then skips Thunderbolt entirely during POST and Windows enumerates the eGPU on every boot — the same path as hot-plug, which always worked.

Hardware/firmware: NUC12SNKi72 (i7-12700H, Serpent Canyon), BIOS SNADL357.0065 (latest at the time), Win11. eGPU: GIGABYTE AORUS RTX 5060 Ti AI BOX on the rear Thunderbolt port.

Symptoms checklist (is this your bug?)

• Power on with the enclosure powered → fans spin up, the machine resets, and the cycle repeats — it never reaches Windows, and you can't get into Setup (F2) while it's looping.
• Warm restart from Windows and hot-plug in Windows → work (at first — the instability shows up over time).
• After a power outage (NUC + enclosure get AC back at the same moment) → loop again; power-cycling the NUC alone does NOT recover — you must power-cycle the enclosure.
• Every visible BIOS toggle is useless: Thunderbolt Boot Support, Wake from Thunderbolt, Fast Boot…
• Failsafe Watchdog + BIOS Self Recovery: after several failed boots a surprise "Flash Update / Updating main firmware" screen can appear — that's Self Recovery kicking in. It can also restore default settings behind your back, which makes your experiments look haunted. When results stop making sense, re-export the NVRAM and check what actually changed.

What did NOT work (so you don't repeat my two days)

Trap: your settings revert behind your back

Two separate mechanisms undo your work:

1. Every "Save & Exit" (F10) in BIOS Setup rewrites the SaSetup variable with defaults for the items the UI doesn't show — my ReBAR=Disabled kept coming back as Enabled after every BIOS visit, which contaminated a whole day of A/B testing. Items in the big Setup variable (watchdog, ITBT timeouts, USB4 CM Mode) survive F10 fine.
2. A watchdog-triggered Self Recovery restores defaults too (and re-enables the watchdog itself).

If you change anything in SaSetup, re-import it after every BIOS visit — or pick a fix that doesn't live there, like this one.

The fix: USB4 CM Mode = CM Debug

BIOS help text for the option: "CM debug — the system boots without any CM in BIOS phase, then boots to OS with the CM based on OS' preference by every boot." In other words: the firmware never touches the TB/USB4 topology during POST (so there is nothing to crash on), and the OS software connection manager enumerates the eGPU after boot — exactly the hot-plug path that always worked.

The option is hidden from the Setup UI and lives in the protected Setup variable (offset 0xADE on SNADL357.0065), so it takes the official AMI command-line tool (SCEWIN/AMISCE) to flip it. Step by step:

Step 1 — prepare the BIOS (enclosure powered OFF so you can get in)

Enter Setup with F2 and set:

• Security → Security Features → iSetupCfg Password Check = Bypass — without this, writes to the protected Setup variable are refused.
• Advanced → Onboard Devices → Failsafe Watchdog = Disabled (recommended — ends the Self-Recovery surprises).

Save with F10 and boot into Windows (enclosure still off).

Step 2 — get SCEWIN/AMISCE 5.05

It's a generic AMI tool that ships inside MSI Center (works on non-MSI machines — it talks to the AMI firmware, not to MSI hardware).

Easy way: the SCEHUB repo — https://github.com/ab3lkaizen/SCEHUB — follow its README; its download script fetches MSI Center and extracts SCEWIN for you.

Manual way:

1. Download https://download.msi.com/uti_exe/desktop/MSI-Center.zip and unzip it → you get MSI Center_2.x.x.x.exe (version number varies).
2. Get innoextract (https://constexpr.org/innoextract/) and run: innoextract "MSI Center_2.0.75.0.exe" → produces an .appx file.
3. The .appx is just a ZIP — open it with 7-Zip (or rename to .zip) and pull out DCv2\Package\MSI Center SDK.exe.
4. Run: innoextract "MSI Center SDK.exe" → produces tmp\PrePackage\Engine Lib_3.x.x.x.exe.
5. innoextract can NOT open this last one (it uses a newer Inno Setup 6.7) — get innounp 2.71+ (https://sourceforge.net/projects/innounp/) and run: innounp -x "Engine Lib_3.0.0.75.exe".
6. SCEWIN is now in {app}\Lib\SCEWIN\5.05.01.0002\ — keep that whole folder together (SCEWIN_64.exe + amifldrv64.sys + amigendrv64.sys). Sanity check: file Properties → Digital Signatures → American Megatrends on all three.

Step 3 — export a backup

Open PowerShell or cmd as administrator, go to the SCEWIN folder and run:

SCEWIN_64.exe /o /s backup.txt

This is read-only and gives you a text dump of every BIOS setting. It is both your way back if anything goes wrong and the source for the next step. Keep a copy somewhere safe.

Step 4 — build the import file

Open backup.txt in Notepad and Ctrl+F for USB4 CM Mode. Create a new file cm_debug.txt containing:

1. the first few lines of backup.txt — the comment header up to and including the HIICrc32= line,
2. the whole USB4 CM Mode block, copied as-is,
3. then move the * from the current option to [03]CM Debug.

You never have to find the Token or Offset yourself — they are already inside the block you just copied; the export is where they come from. They differ between BIOS versions, which is why you copy the block from your own backup.txt and not from this post.

Mine looks like this (DON'T copy it verbatim — your header, Token/Offset and help text come from YOUR export):

// Script File Name : C:\egpu\backup.txt
// Created on 10/20/26 at 15:59:10
// AMISCE Utility. Ver 5.05.01.0002
// Copyright (c) 2021 AMI. All rights reserved.
HIICrc32= 43158FCE
Setup Question
= USB4 CM Mode
Help String
= FW CM only - The system boots with FW CM only in both BIOS and OS phase.  (… keep the full line from your export …)
Token=1484
// Do NOT change this line
Offset
=ADE
Width
=01
BIOS Default
=[02]OS Dependent
Options=[00]Firmware CM Only
// Move "*" to the desired Option
         [01]Software CM first
         [02]OS Dependent
         *[03]CM Debug

Step 5 — import it

Still in the admin prompt:

SCEWIN_64.exe /i /cpwd admin /s cm_debug.txt

Expected output: Password accepted … Script file imported successfully. (possibly with "Power cycle reset required").

• Cannot update protected variable Setup. Please use /cpwd or Admin password does not exist → the Bypass from step 1 isn't set.

Step 6 — full shutdown and the real test

Shut Windows down completely (Shut down, NOT Restart — the import needs a power cycle). Power the enclosure ON, wait a few seconds, start the machine. It should boot normally; Windows brings the eGPU up by itself during boot.

Step 7 — verify

nvidia-smi --query-gpu=name,pcie.link.gen.current,pcie.link.width.current --format=csv
nvidia-smi -q -d MEMORY

On mine: PCIe gen 4, width x4, and "BAR1 Memory Usage / Total: 256 MiB" — the small BAR is normal over Thunderbolt and costs ~nothing on a x4 link.

Verified after the change

• Cold boot with the enclosure powered: ✅ every time
• Warm restart right after a 10-GiB CUDA training load: ✅
• Power outage — AC pulled from NUC and enclosure at once, plugged back: ✅
• F10 saves in BIOS Setup: ✅ CM Debug survives (it's in Setup, not SaSetup)
• Performance unchanged vs. hot-plug: PCIe 4.0 x4, nvidia-smi and CUDA work as before

Caveats

• With CM Debug the firmware does no Thunderbolt at all pre-boot: you cannot boot from a Thunderbolt drive, and devices behind the TB/USB4 ports won't work inside the BIOS UI (keyboards on the NUC's regular USB-A ports are fine). For an eGPU box this costs nothing.
• If you ever loop again: power off the enclosure → the machine boots → fix or revert by importing backup.txt (SCEWIN_64.exe /i /cpwd admin /s backup.txt), or F9 defaults in Setup — but remember F9 re-enables the Watchdog (and with it the Self-Recovery surprises) and reverts everything else.
• A BIOS update will likely reset the setting — and it can also move the tokens/offsets, so do NOT re-import your old files on a new BIOS version. After an update, redo steps 3–5 with a fresh export (same Ctrl+F, two minutes) and keep per-version backups; a backup.txt is only valid for reverts on the BIOS version it was exported from. The HIICrc32 line in the header exists to catch such mismatches, but don't rely on it.
• Only if you want to hunt hidden options on your own BIOS yourself: UEFITool/UEFIExtract https://github.com/LongSoft/UEFITool + IFRExtractor-RS https://github.com/LongSoft/IFRExtractor-RS on the BIOS capsule from the vendor's site.

Usual disclaimer: firmware settings surgery — your hardware, your risk. Make the full export backup first and know the recovery path before you start.

I was setting the backup power for NUC, So I used LiPo battery of 12v with boost converter and adjust voltage 19.2v but when I plugged in to NUC then NUC burn (short circuit internally) the encircled IC. But now it's very problematic for me to find this IC 3U=5C, U1L or replacement, Please help me what I can do ?

Hi everyone, I'm hoping someone here has seen this before.

I have an Intel NUC7i7BNH (Baby Canyon) that was running perfectly fine with Win10.

The NUC was on BIOS: BNKBL357.86A.0049. I wanted to update to the latest BIOS (0093).

The update process would start normally and validate the BIOS file successfully, but would always fail at: Flashing image for Intel(R) Management Engine firmware ... [failed!]

 Technical information: (0x800000000000000E, 0)

What I tried

I tried multiple BIOS versions: 0052, 0072, 0093. Every single one failed at exactly the same point.

But the NUC continued to boot normally after each failed update.

I then attempted BIOS recovery mode using the BIOS security jumper as a recommendation from AI:

Booted with BIOS 0093.BIO file on FAT32 USB and I saw that the recovery process started

Unfortunately the recovery update also failed at the same Intel ME firmware stage.

Current state

After the recovery flashing attempt:

• NUC no longer boots
• No front power LED
• No video output
• Monitor never wakes up
• Power button appears to do nothing and has the LED off
• BIOS_SEC jumper has been restored to its original position (pins 1-2)
• No cables were disconnected or moved during the process

However:

• The HDD spins immediately as soon as AC power is connected
• The HDD spins even before pressing the power button
• The power adapter is supplying power

Additional information

• CMOS battery has been dead for a long time, but that was not causing issues previously
• NUC was fully functional before attempting the BIOS recovery mode
• Recovery and normal BIOS updates both consistently failed only at the Intel Management Engine firmware stage

Questions

1. Has anyone seen a NUC7i7BNH get stuck in this state after an ME firmware update failure?
2. Is there a known recovery procedure beyond the standard BIOS recovery process?
3. Any way to distinguish between a corrupted BIOS, corrupted ME firmware, and a failed motherboard?

Any help would be greatly appreciated. I'd really like to recover it if possible. Inserting the USB with the BIOS file and pressing the power button did not seem to make any difference.

Thanks!

I just bought this and ran windows update

It's been 30 mins and it's stuck here lol. Currently only HDMI, power adapter and 2.4G dongle plugged in - no USB-C or anything.

Should i keep it like this or try to hard reset it. Windows sucks!

UPDATED:
after waiting for 2 hours, i decided to hard reset - pressed and the power button, and turn it on again.
And actually it's works. I suspect that somehow bios update does not "return" the result to windows update to continue proceed, or just Windows being sucks by not receiving it. Some guys definitely vibe code this.

Asus NUC prices on bare bone 15th gen NUCs have just gone up by a good $100 in US. Is this something temporary or Asus permanently raised prices ?

Title: Intel NUC 11 Extreme + Akasa Cypher HDB: RTX 5070 Ti stuck at PCIe 3.0 x16 instead of Gen4

Hi everyone,

I'm experiencing a strange PCIe limitation with my Intel NUC 11 Extreme (Beast Canyon) installed in an Akasa Cypher HDB (A-NUC77-A1B).

Although both the NUC 11 Extreme and the Akasa carrier board advertise PCIe 4.0 support, my NVIDIA RTX 5070 Ti is limited to PCIe 3.0 x16.

Hardware configuration:

• Intel NUC 11 Extreme (Tiger Lake-H)
• Akasa Cypher HDB with Akasa carrier board
• NVIDIA GeForce RTX 5070 Ti
• BIOS DBTGL579.0075 (latest installed)
• Manjaro Linux
• Three internal NVMe SSDs

NVIDIA reports:

pcie.link.gen.gpumax:      5
pcie.link.gen.hostmax:     3
pcie.link.gen.max:         3
pcie.link.gen.current:     3 (under load)
pcie.link.width.current:  16

CPU PCIe GPU Root Port (00:01.0):

LnkCap:  Speed 8GT/s, Width x16
LnkSta:  Speed 8GT/s, Width x16
LnkCap2: Supported Link Speeds: 2.5-8GT/s
LnkCtl2: Target Link Speed: 8GT/s

Interestingly, the CPU-connected Samsung NVMe SSD runs correctly at PCIe 4.0 x4:

Root Port 00:06.0:
LnkCap: Speed 16GT/s, Width x4
LnkSta: Speed 16GT/s, Width x4

Troubleshooting already performed:

• Updated BIOS from 0068 to 0075.
• Restored BIOS factory defaults.
• Checked PCIe bifurcation settings (Auto).
• Confirmed that GPU operates at x16.
• Confirmed Gen3 is the maximum reported host capability, not just an idle power-saving state.
• Checked Linux kernel logs without finding explicit PCIe link errors.

The unusual part is that the GPU Root Port itself advertises only Gen3 capabilities, whereas the NVMe Root Port correctly advertises Gen4.

Questions for other NUC 11 Extreme / Akasa Cypher HDB owners:

1. Has anyone successfully achieved PCIe 4.0 x16 with the Akasa Cypher HDB carrier board?
2. Could someone with a similar setup share their lspci Root Port link capabilities?
3. Are there known firmware, carrier-board revision, or compatibility limitations?
4. Has anyone experienced similar behavior after switching from the original Intel carrier board to the Akasa one?

I still have the original Intel carrier board, but I haven't tested it again yet.

Any suggestions or test results would be greatly appreciated.

Thanks!

I just got this NUC for $30. It’s got an 8th gen i7. Just didn’t have a hard drive. I installed a drive but it shuts down when doing anything other than web surfing. Warning sign comes up - system has recovered from an over temperature condition. Anyone have this issue before? Do I need to disassemble the whole thing to apply new thermal paste? I did go into BIOS and change the fan option to “Cooling”. Would appreciate any suggestions.

LIttle PSA if anyone is experince the issue i had

I’ve been having intermittent issues with an Intel NUC11 i3 running Windows 11 headless. Wake-on-LAN was unreliable, sometimes the NUC would wake but RDP would fail to create a usable session, and on a few occasions I had to physically power-cycle it before RDP would work again.

The NUC uses Modern Standby / S0 Low Power Idle, so I compared it with another NUC11 I have that has always behaved reliably. Both machines use the same Intel I225-LM Ethernet controller, but the problematic NUC was still using driver version 1.0.2.6 from 2020, even though Windows Update said the machine was fully up to date.

As part of the troubleshooting I checked powercfg /devicequery wake_armed. On the problematic NUC the Ethernet adapter was not listed at all, even though Wake on Magic Packet was enabled in the adapter settings. I then manually updated the Intel Ethernet driver to version 2.1.5.7 from 2025.

After the update, the Intel I225-LM immediately appeared in powercfg /devicequery wake_armed, and Wake-on-LAN from Modern Standby started working properly again. RDP also reconnected normally after wake.

So if you’re having odd WoL or RDP behaviour on a NUC11, especially with Modern Standby, check the actual Intel Ethernet driver version and don’t assume Windows Update has installed a recent one. The adapter can show Wake on Magic Packet as enabled while still not actually being armed by Windows to wake the machine. I’m aware Intel/ASUS have an existing BIOS + registry-patch fix for I225 Modern Standby issues, but in my case the key problem was that Windows Update had left the NIC on a 2020 driver and it wasn’t listed in powercfg /devicequery wake_armed.

Hello yall, im a car tuner and builder, i want to wire in a small touch screen display into my glove box on a long cable that i can pull out and tune on the fly.

I was gifted 3 nucs. All of them have this same model number: nuc7i5BNH

Though im so confused based on what i read, can someone reccomend me exactly what i need to hook this nuc up? I would really appreciate it. I know engines and car electrical, but anything like this confuses me.

looking for troubleshooting advice on my LattePanda Mu N100 module. It originally developed an HDMI display issue with a red tint while running on the Lite carrier board. I then transferred the module to the full carrier board where it booted up and worked normally at first. However, after running for a few minutes, the board abruptly turned off during what seemed like a sudden power drop or outage. Since that shutdown, the board will not turn on or boot at all. I have visually inspected both the compute module and carrier board thoroughly under good lighting, and there are no burn marks, cracked ICs, blown components, or visible shorts. Has anyone dealt with this behavior on the Mu? Specifically, could a sudden power cut latch an embedded controller protection state, corrupt the SPI BIOS flash, or take down an on-module power rail? Any guidance on specific test points or reset steps to bring it back to life would be greatly appreciated.

Hi,

i need a bios dump for DC3217IYE as i got a power outage during bios update and now the nuc is completely dead and i want o write it manually.

Edit: I need the dump as .bin or .rom

Thanks!

I have a nuc5i5ryh, which per the specs page has mini-dp 1.2, which should support up to 4k at 60 hz. I have a Cable Matters Active Mini DisplayPort to HDMI Adapter, Mini DP to HDMI from Amazon which should also support up to 4k60 (please advise if I should provide the link in the comments). I have tried a couple of different HDMI cables connecting the adapter to my Samsung S90F TV, but cannot select any refresh rate above 30 hz at 4k. When I try to set a custom 3840 x 2160 at 60p Hz resolution in the Intel Graphics Panel, I get an error message saying the custom resolution exceeds the bandwidth capacity.

Any thoughts on why I can't get 60 hz at 4k with this device?

Hi. I have an Intel NUC 13 extreme:

• i7-13750K
• 36GB RAM
• RX 7700 XT

I turned my PC on this morning and it goes into some death loop. No video. Fans don’t turn on. Just some mysterious flashing from the power LED.

Process:

• Hit switch from back of PC (the PSU switch)
• Power LED goes solid for about 15 seconds. Note: I do not touch the power LED button
• Power LED blinks 18 times and then turns off for about 2 seconds and then repeats the 18 blinks

Sorry, it doesn’t seem like I can post a video of the blinking.

The LED pattern is similar to what ASUS suggests is a thermal issue. But mine is 18 blinks. And the thermal issue is supposed to be 16 blinks. I’m pretty sure about my count. I don’t see the CPU getting hot. I do not smell any burning smell which might indicate a fried PSU.

Things I’ve tried:

• Removed GPU
• Tried each stick of RAM
• Removed all RAM
• Tested the CPU fan and it’s fine
• Removed power to PSU overnight
• New CMOS battery
• Re-seated CPU heatsink and reapplied paste

I suspect a bad mobo but would like some sort of confirmation. Looking for some Hail Mary help before I send it off for parts on eBay. Thanks in advance. Appreciate the community.

Intel NUC 13 Extreme I5 (13600Kf) Compute Element

[Timestamp](https://imgur.com/a/UhdG0Wc)

\- Brand New/Factory Sealed

\- Includes 13600Kf preinstalled

\- Does NOT include RAM/Storage

Asking $475 Local, $500 Shipped

\---

NUC 13 Extreme (Raptor Canyon) Daughterboard

(See above for Timestamps)

\- New - Never used but no original packaging.

\- Requires 12VO/12V PSU

\- Includes PCIe slot for Compute Element

\- Includes PCIe 5.0 x16 slot for GPU (Up to three slots)

Asking $125 Local, $150 Shipped

----

Local to 85016

Serious offers will be considered

Please comment before PM, thank you!

TL;DR: my NUC15CRSU9 successfully flashes its entire firmware stack — Thunderbolt retimer, BIOS and ME, all to 100% — and then fails a firmware update on the very next boot, forever. A pending update request is surviving repeated successful firmware updates and I can't find any way to clear it.

Hardware: ASUS NUC 15 Pro+ / NUC15CRSU9 (board CRARL579), Core Ultra 9 285H, 96 GB. Was running Proxmox VE 9.

How it started: I submitted a BIOS update as a UEFI capsule-on-disk from Linux, using fwupd. Turns out ASUS's .CAP is an AMI BIOS Guard / _AMIPFAT container, not a UEFI FMP capsule, so fwupd wrapped it in a generic capsule header and the firmware rejected it. Entirely my own doing — I'm not looking for sympathy, just a way out.

Symptom, on every single boot:

Then it either hangs there or resets and repeats. No OS ever loads.

Here's the strange part. Pressing ESC at that screen cancels the attempt and drops me into BIOS Setup (jumper in Normal). From there, Advanced → EZ Flash works perfectly. I've now flashed three times:

0017 → 0029 → 0032, currently on CRARL579.0032.2026.0704.0118

All three stages complete at 100% every time — Thunderbolt retimer, main firmware, ME firmware. And the next boot goes straight back into the failed-update loop. So the board isn't bricked and flashing isn't broken. Something is holding a stale "update pending" request that reflashing the firmware doesn't clear.

Already tried, all with no effect:

• BIOS Security Jumper recovery (jumper removed, CRARL579.CAP on FAT32 USB at root and in \EFI\Intel\) — recovery never runs, just reboots
• [F4] BIOS Recovery, and Setup → Recovery → Select Image / Update Image
• A different BIOS version (0029 instead of 0032)
• Load Optimal Defaults (F9+F10), and Config Menu [F5] restore to build-time defaults
• Intel MEBX Reset Header (pins 1–2), which the TPS documents specifically for "when the system may have become unresponsive, such as after a failed BIOS update"
• Jumper in Lockdown (pins 2–3) — no video at all, continuous power cycling
• Booting with every USB device removed and no NVMe fitted — loop still happens with nothing attached to update from
• Full G3 power cycle — AC out 60 s plus a 10 s power-button drain, to let the ME activate on a cold start
• A properly-typed EFI System Partition on USB (GPT, EF00) with the vendor image in \EFI\UpdateCapsule\, that device first in the boot order

And the trap: F2, F7 and F10 are never processed at POST. ESC and F10 only work inside the BIOS utility (F10 gives "Save & Exit Setup", not a boot menu). So I can't boot any external media — which means I can't get into Linux to clear OsIndications from efivarfs, which is the one thing that would obviously fix this.

What I'm asking:

1. Has anyone recovered a NUC from a stuck pending-update state like this?
2. Is there any way to clear a pending capsule request on AMI Aptio V without booting an OS?
3. Any ASUS support folks here — is there a service tool for this? I have a ticket open, and I'd rather not go to an external SPI programmer on a board that's 16 months into a 3-year warranty.

I have photos of every screen, the full capsule analysis, and a complete log of every step if any of it is useful. Happy to test anything.