The Mystery of LBFO Teaming Adapters Failing to Start — the Surprising Cause Revealed!

Hi, I'm Shii-chan! Today I've got a story about a rare but annoying bug in Windows Server's LBFO teaming — once you know the cause, it all clicks into place. Let's dig in together.

What was announced?

This comes from the JP Windows Support blog (Microsoft Japan's Windows Platform Support team). They explain that during OS startup, an LBFO (Load Balancing Failover) teaming adapter can rarely fail to initialize, even though its member NICs are already linked up.

When this happens, the "Network Connections" screen shows the teaming adapter as disabled, and re-enabling it from there doesn't fix it. If you check with Get-NetAdapter, the member NICs show as Up with a link speed, but the teaming adapter itself shows Status as Not Present with a LinkSpeed of 0 bps.

Why it matters

LBFO is how Windows Server bundles multiple NICs together for redundancy and load balancing, so it's a core piece of a server's network connectivity. If it silently fails depending on boot timing, and doesn't recover on its own, a server could end up cut off from the network without anyone noticing right away.

What makes it trickier is that this is a timing-dependent issue that only happens "rarely," so it's hard to reproduce and pin down. Just knowing the event log difference between the healthy and broken cases makes triage a lot easier.

What changes

With this explanation in hand, administrators now know this issue has a clear root cause, a driver-load race condition, and can triage and recover from it with the right steps instead of chasing an unexplained network outage for hours.

Dive Deep

The root cause is that, during OS startup, loading of the NdisImPlatform driver and the device-add process for the NIC teaming adapter run in parallel. If the device-add process starts before the driver finishes loading, the teaming adapter's initialization fails.

This race depends on how long the driver takes to load, so it's timing-sensitive, and it becomes a bit more likely when boot logging is enabled.

The blog also shows how to tell the two cases apart in the event log:

• Healthy: Microsoft-Windows-MsLbfoEventProvider logs "DriverEntry exiting, Status = 0," followed by "Initializing TeamNic," "Member created," and "Aggregator created"
• Failure: only "DriverEntry exiting, Status = 0" is logged, with nothing after it

There are two ways to handle it:

• Prevention: open msconfig, go to the "Boot" tab, and uncheck boot logging, since having it enabled makes the issue more likely
• Recovery: either (A) disable and then re-enable the teaming adapter in Device Manager, or (B) restart the OS

Wrap-up

• LBFO teaming adapters can rarely get stuck as "Not Present / 0 bps" after a startup timing race
• The cause is a race between the NdisImPlatform driver load and the adapter's device-add process
• Disabling boot logging helps prevent it, and disabling/re-enabling the adapter or restarting the OS recovers it
• You can triage by checking whether "Initializing TeamNic" and later events appear in the log

If you manage Windows Server environments that use LBFO teaming and have ever been puzzled by an unexplained network outage at boot, this one's for you!