0XC023002F

STATUS_NDIS_LOW_POWER_STATE (0xC023002F) fix for network adapters

Windows Errors Intermediate 👁 1 views 📅 May 28, 2026

This error hits when a network driver or cmdlet tries to wake a sleeping adapter and fails. It's a power state mismatch, not hardware failure.

You're running a PowerShell script to configure a network adapter — maybe setting up Wake-on-LAN or changing link speed — and you get 0xC023002F with the message The miniport adapter is in a lower power state. This happens most often on laptops after resume from sleep, or on desktops where the OS put the adapter into D3 (device sleep) but the driver or a cmdlet tries to talk to it at D0 (full power). I've seen it with Realtek PCIe GbE Family Controllers and Intel I219-V adapters on Windows 10 22H2 and Windows 11 23H2.

What's actually happening here

NDIS (Network Driver Interface Specification) manages power states for network devices. The adapter reports it's in a low-power state — D2 or D3 — but the command you ran expects the adapter to respond at D0. The driver didn't transition the hardware back up in time, or the OS blocked the transition because of a policy conflict. The error code 0xC023002F is NDIS_STATUS_PM_WAKEUP_FAILURE aliased through STATUS_NDIS_LOW_POWER_STATE. The adapter's miniport driver holds the power state flag, and until something forces a D0 transition, the adapter stays asleep.

Fix it in 4 steps

Skip the random driver reinstalls — that won't help unless the driver itself is corrupt. The real fix is forcing the adapter to wake and stay awake, then locking power policy.

  1. Wake the adapter explicitly
    Open Device Manager (devmgmt.msc), find your network adapter under Network adapters. Right-click and select Disable device. Wait 5 seconds. Right-click again and Enable device. This forces a full D0 -> D3 -> D0 power cycle. The adapter now reports as active.
  2. Kill selective suspend
    With the adapter still highlighted in Device Manager, double-click it, go to the Power Management tab. Uncheck Allow the computer to turn off this device to save power. Also uncheck Allow this device to wake the computer if you don't need Wake-on-LAN. Then click OK. This prevents the OS from dropping it to D3 again.
  3. Disable modern standby network connectivity (Windows 11 only)
    Open PowerShell as admin and run:
    powercfg /setacvalueindex SCHEME_CURRENT SUB_NETWORK NCPA_OPTION 0
    powercfg /setdcvalueindex SCHEME_CURRENT SUB_NETWORK NCPA_OPTION 0
    powercfg /setactive SCHEME_CURRENT
    This turns off the Network Connectivity in Standby policy that keeps the adapter in a low-power state while the display is off.
  4. Force adapter to D0 with PowerShell cmdlet
    If you still get the error in scripts, run this before your network commands:
    $adapter = Get-NetAdapter -Name "Ethernet"
    Disable-NetAdapter -Name $adapter.Name -Confirm:$false
    Start-Sleep -Seconds 3
    Enable-NetAdapter -Name $adapter.Name -Confirm:$false
    Replace "Ethernet" with the actual name from Get-NetAdapter. This does the same toggle as step 1 but from script.

Why step 1 alone isn't enough

Disabling and enabling the adapter wakes it temporarily, but if your power plan or driver settings allow selective suspend, the OS will put it back to sleep within minutes. You need step 2 to lock the power management flags in the registry. The reason step 3 matters on Windows 11 is that the NCPA_OPTION policy is separate from Device Manager's power tab — it's a network-specific power budget that bypasses the miniport driver's D-state.

What to check if it still fails

If you've done all four steps and still see 0xC023002F, the problem is almost certainly a driver that doesn't properly handle D0 transitions. Check your adapter's driver version against the manufacturer's latest. For Realtek, avoid the Windows Update driver — grab the one directly from Realtek's site (version 10.68 or later). For Intel, use the Intel PROSet package, not the generic Microsoft driver. You can verify via Device Manager > Driver > Driver Details — if the provider shows Microsoft, that's your culprit.

One more thing: if you're hitting this inside a Hyper-V VM, the virtual network adapter is managed by the host's physical adapter. You need to fix it on the host, not inside the VM. The host adapter must be in D0 before the VM can use it.

Was this solution helpful?