Beelink AI 395 Review and Troubleshooting Journey

When I ordered the Beelink AI 395, the plan was clear: use it as a compact AI workstation for running local models and as a testbed for offline inference workloads. On paper it looked excellent — AMD’s Ryzen AI MAX 395 CPU, dual-channel DDR5 with support for up to 256 GB, PCIe 4.0 NVMe storage, and critically, dual Intel 10 GbE E610-XT2 network adapters¹. For AI workloads that need both CPU acceleration and high-throughput networking, this combination was hard to ignore.

What follows is a detailed account of my experience: unboxing and setup, the first stability problems, the extended troubleshooting with Beelink and Intel, and the final configuration changes that delivered a stable, quiet, and performant system.

Device Specifications

To frame the context, here are the key specifications of the AI 395 as shipped:

• CPU: AMD Ryzen AI MAX 395, 16 cores, integrated NPU for AI acceleration.
• Memory: 128 GB LPDDR5 8000MT/s RAM.
• Storage: Dual M.2 2280 NVMe slots, PCIe 4.0.
• Networking: Dual Intel E610-XT2 10 GbE NICs, plus Wi-Fi 7.
• Graphics: AMD Radeon 8060S 40CUs.
• Ports: HDMI 2.1, USB4, USB 3.2, USB-C, SD4.0 Slot, 3.5 mm audio.
• Chassis: CNC-machined aluminium, compact SFF footprint.

On paper this makes the system appealing for AI research, home labs, and as a compact edge node. But as always, specifications don’t tell the whole story.

Unboxing and First Impressions

The AI 395 arrived well packed, with the usual accessories: power cable, HDMI cable, and quick-start guide. The finish is impressive — brushed aluminium, a weighty feel, and a design language that draws comparisons with a Mac Mini.

Booting for the first time, the device shipped with Windows 11 preinstalled. Setup was smooth; I connected over Wi-Fi, performed Windows updates, and installed the latest AMD drivers. No issues emerged during this phase. The cooling system was louder then I expected, but overall idle temperatures remained reasonable.

The first workloads tested were local LLMs via LM Studio. Over Wi-Fi the device was stable, delivering the expected throughput. Things changed the moment I switched from Wi-Fi to the 10 GbE NICs.

The First BSODs

Within minutes of sustained network load and GPU usgae, the system crashed with a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E) in ixw.sys. Configuring full memory dumps confirmed a null pointer dereference inside the Intel ICE driver. Each crash caused the NIC LED to freeze green, the adapters locked up and vanished from Device Manager. Only a full power cycle restored functionality.

This behaviour was reproducible and consistent, making the NICs unusable for any workload.

Here is the summary of the issue:

• Beelink AI 395 with an Intel Ethernet Network Adapter E610-XT2 (PCI\VEN_8086&DEV_57B0).
• NIC firmware: NVM 1.10, Option ROM 1.3786.0
• Driver: ixw.sys 1.2.43.0 from Intel Ethernet Pack 30.0.1
• OS: Windows 11 (build 26100)

Problem: After a couple of minutes under load the system hits a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x7E) in ixw.sys. When it crashes the NIC LED stays solid green, Windows no longer sees the adapter, and only a full power cycle brings it back.

BugCheck Review:

Crash Summary
    System: Windows 10 build 26100 x64
    BIOS Revision: 5.36.0.0
    Adapter: Intel® E610-XT2 (ICE driver family)
    Firmware: NVM 1.10, Option ROM 1.3786.0
    Driver: ixw.sys (ICE), build timestamp 27 Dec 2024, from Intel Ethernet Adapter Complete Driver Pack 30.0.1
    Hyper-V: Present/enabled

Bugcheck
    Stop code: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (0x1000007E)
     Exception: 0xC0000005 (Access violation – invalid memory reference)
    Faulting IP: ixw.sys+0x44B9E → attempted to read from 0x8 (NULL dereference)
    Process: System thread (ExecutionContext DispatcherThread)

Stack trace (trimmed):
ixw+0x44b9e
nt!ExFreePoolWithTag
ExecutionContext!UnregisterNotificationTaskCallback
ExecutionContext!HandleKWaitTask
ExecutionContext!DispatcherThread
nt!PspSystemThreadStartup
nt!KiStartSystemThread

The crash originates inside the Intel ICE driver (ixw.sys), during a callback teardown/unregister path. A freed or NULL pointer is dereferenced (RCX=0), causing a use-after-free / double-unregister condition. This is a known class of issues when modern ICE drivers (≥1.11.x) are used with outdated NVM firmware (<3.0) on E610/E810 adapters. The NIC’s very early firmware baseline (NVM 1.10) does not align with current driver expectations, leading to BSODs under Windows.

Contacting Beelink Support

I raised a support case with Beelink. My first messages included the system serial number, reproduction steps, and analysis of the dumps. Their early replies asked for photos of the device and BIOS screens, then acknowledged the NIC issue:

“Currently, the network card issue of the GTR9 395 persists, and its root cause lies in the Ethernet driver… A complete resolution to this issue will only be possible once a new driver is released.” — Beelink Support, September 2025

Beelink later provided a BIOS update (v1.08), which was not listed publicly. Applying it introduced minor changes but did not fix the BSODs. I also attempt to change the NIC settings removing some more common issues. I tried disabling offloads (RSS, LSO, checksum, interrupt moderation) and rolling back drivers, but the issue still happens and the BSDO consistently show null pointer dereference inside ixw.sys.

Driver and Firmware Investigation

At this point I reviewed Intel’s release notes. The drivers bundled in Intel’s Ethernet Pack 30.0.1 required matching NIC firmware. The AI 395 shipped with NVM 1.10, while Intel’s documentation showed that NVM 1.30 or higher was required for the 30.x driver branches. This mismatch was a possible reason for the crashes.

I tested the firmware with the intel tool “nvmupdate64e.exe -i” did not return any firmware details, which made me think the firmware maybe OEM locked. I confirmed the firmware version in the bios.

The catch: the NICs were onboard. If firmware was vendor-locked, applying Intel’s generic NVM update could brick the NICs or even the device itself. I shared this with Beelink, who confirmed cintued to confirm the issue and that it would be fixed by a driver update, then suggested waiting for Intel to release fixes. The current workaround provide was to not use the NIC’s, this would not option as I need them for my work.

Intel Forum and Escalation

The next stage was to escalte the issue to Intel directly. I raised the case on Intel’s community forums². Intel engineers confirmed the issue:

• The crash originates in the ICE driver when paired with outdated NVM.
• NVM 1.10 is too old for the 30.x drivers.
• Updating to NVM 1.30 was the next option to move forward, but since the adapters were OEM, the firmware had to come from Beelink.

I relayed this back to Beelink and also told them that if we wait for the driver, the firmware would still not be updated and the issue would return. After further correspondence, they finally provided the NIC firmware update. With NVM 1.30 installed and drivers updated to the 30.4 pack, the BSODs disappeared.

System Tuning

With stability restored, I tuned the device for its intended use:

• BIOS Power Mode: Switched from “balanced” to “performance”, unlocking full CPU potential. This allows me to push the system to the full 140w of power.

• Fan Curve: Changed from constant 2000 RPM to a graduated profile. The system now idles quietly at 40–50 °C, ramping only under load. This reduced the fan noise. The FAN’s now only ramps up to “1800 RPM under load and peak at 3800 RPM at high temp. This ensures that the system stays cool and responsive. the FAN settings are located under “Hardware Monitor” -> “Samrt Fan Function”.

• NIC Settings: Updated Windows driver configuration to align with standard networking recommendations (RSS, LSO, interrupt moderation adjusted).
  

These changes made the system far more usable: stable under network load, quiet at idle, and performant under sustained AI inference.

Geekbench results

With the system in Performance mode (BIOS v1.08), NIC firmware updated (E610 NVM 1.30) and Intel Driver Pack 30.4, Geekbench completed without instability. The table summarises CPU, OpenGL, and Vulkan outcomes for the representative run set on <2025-09-25>; ambient was 21°C and no thermal throttling was observed.

Test conditions: Windows 11 build 26100; AMD graphics driver 25.9.1; Intel NIC driver ixw.sys 1.2.43.0 (Pack 30.4); fan profile tuned (idle 40–50 °C, full ramp at 85 °C).

Conclusion

The Beelink AI 395 is a capable device, but my experience shows the risks of shipping with mismatched driver and firmware baselines. Out of the box, the Intel NICs were unstable, making wired networking unusable until Beelink supplied firmware aligned with Intel’s current drivers. The firmware does appear to tbe the same as the intel provided one, but still reach out to Bee-Link to get the offical firmware from them.

The final working configuration required:

• System BIOS: v1.08 (Firmware supplied by Bee-Link Support)
• NIC Firmware: Intel E610 NVM 1.30 (Supplied by Bee-Link Support, appears the same as Intel version)
• Driver Pack: Intel Ethernet 30.4 (Intel and Bee-Link supplied drivers both worked)

Once updated and tuned, the AI 395 now meets its promise as a compact AI workstation. But it took persistence and vendor coordination to get there. Now its time to stress the device with a few games before I start testing AI applications and Linux builds.

Images of GTR9 are taken directly from the Bee-Link website.