If you maintain a Windows and Linux dual-boot workstation, you will eventually run into a baffling hardware state: your wireless network adapter vanishes completely from both operating systems.

In Linux, the interface disappears from ip link and network managers report missing hardware. In Windows Device Manager, the controller resurfaces only as an uninitialized or phantom device throwing Code 10 (This device cannot start. {Operation Failed}) or Code 43. Reinstalling OS-level drivers typically fails, and even physically swapping the M.2 Wi-Fi card often leaves the problem untouched.

After tracing this failure loop across both operating systems on an Intel Wi-Fi 6 AX201 module, I isolated the root cause: an unhandled ACPI power-state lock exacerbated by the split physical/logical architecture of Intel’s CNVio2. The Linux kernel’s Wi-Fi power-saving routine leaves the module in an unreleased D-state during warm reboots, preventing the Windows kernel from reinitializing the device.

This post documents the architecture behind the failure, the Windows PnP installer logs that expose it, the software mitigation that untangles the handoff, and the hardware-level fallback when the controller deadlocks.

The CNVio2 Architecture: Why the AX201 Is Vulnerable

Standard M.2 wireless adapters (such as the Intel AX200 or AX210) communicate over standard PCIe and USB buses. The entire network stack — MAC, baseband, and RF transceiver — resides directly on the card.

The AX201 is structurally different. It relies on Intel’s proprietary CNVio2 (Integrated Connectivity) interface:

  • The Host (CPU/PCH): Houses the MAC, DSP, and digital processing engines directly inside the main processor and chipset.
  • The Companion RF (CRF) Module: The physical M.2 2230 card houses only the analog RF transceiver, power amplifiers, and antenna circuitry.
  • The Bus: They communicate over a low-latency, proprietary physical interface rather than a standard PCIe link.
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

+---------------------------------------------------------------+
|                    Host System (CPU / PCH)                    |
|   [ Linux: iwlwifi ]                [ Windows: Netwtw ]       |
|   +-------------------------------------------------------+   |
|   |            Integrated Wi-Fi MAC / Baseband            |   |
|   +---------------------------+---------------------------+   |
+-------------------------------|-------------------------------+
                                |
                     Proprietary CNVio2 Bus
                                |
+-------------------------------v-------------------------------+
|                   Companion RF (CRF) Module                   |
|                     Intel AX201 (M.2 Form)                    |
|                Analog RF Transceiver, Front-End               |
+---------------------------------------------------------------+

Because half of the network adapter lives inside the processor, device power states (ACPI D0–D3) are directly mediated by motherboard firmware and the host CPU’s power-management plane. If an operating system issues an ACPI power-down command or suspends the link without cleanly asserting a hardware reset before a warm reboot, the CRF module remains stuck in a low-power “zombie” state.

When the next kernel initializes, it attempts to handshake with an RF frontend that is physically unresponsive.

Symptoms and Installer Log Analysis

The primary trigger is a warm reboot from Linux into Windows. When Windows boots, the Netwtw driver attempts to initialize the AX201 and immediately times out, resulting in:

1
2
3

This device cannot start. (Code 10)
{Operation Failed}
The requested operation was unsuccessful.

Attempting to apply an updated Intel driver package via standard .exe installers frequently aborts with generic error screens. Digging into the generated Windows PnP installer log (Intel®_Software_Installer_..._rollback_000_WIFI_Driver.log) revealed the exact choke point:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

14-09-2026 10:24:40 : [Standard] Installing INF: Components\WiFiDriver\Netwtw08.INF
14-09-2026 10:24:40 : [Debug] Running: "C:\WINDOWS\system32\pnputil.exe /add-driver "Components\WiFiDriver\Netwtw08.INF" /install"
...
14-09-2026 10:24:43 : [Debug] isFinished = True
14-09-2026 10:24:43 : [Debug] Output = Microsoft PnP Utility

Adding driver package:  Netwtw08.INF
Driver package added successfully.
Published Name:         oem158.inf
Driver package is up-to-date on device: PCI\VEN_8086&DEV_7A70&SUBSYS_40708086&REV_11\3&11583659&0&A3

Total driver packages:  1
Added driver packages:  0

14-09-2026 10:24:43 : [Debug] ExitCode = 259

Deconstructing ExitCode 259

The Microsoft PnP utility (pnputil.exe) successfully staged Netwtw08.INF into the driver store as oem158.inf. However, it exited with code 259. In the Windows API:

ExitCode 259 ≡ STILL_ACTIVE / ERROR_NO_MORE_ITEMS

In the context of device installation, this indicates that the target device node is locked by an unresolved operation or an unserviced I/O request packet (IRP). Because the CNVio2 hardware was stuck in a suspended D-state from the previous Linux session, the Windows PnP manager could not cycle the device’s power state, causing driver attachment to fail.

The Mitigation Pipeline

The permanent mitigation requires stripping away aggressive sleep states on both kernels so neither OS leaves the CNVio2 link suspended during an OS handoff.

1. The Linux Driver: Disable NetworkManager Power Saving

By default, Linux’s NetworkManager enables runtime Wi-Fi power-saving, signaling iwlwifi to place the card into low-power states during idle or shutdown cycles.

To disable this, edit /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf:

1

sudo nano /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

Locate the [connection] block and change wifi.powersave from 3 (enabled) to 2 (disabled):

1
2

[connection]
wifi.powersave = 2

Restart the daemon to apply the change immediately:

1

sudo systemctl restart NetworkManager

Disabling this setting ensures that the iwlwifi driver does not drop the CNVio2 link into an unrecoverable sleep state before handing control back to firmware during a warm reboot.

Windows must be prevented from putting the bus to sleep or using hybrid hibernation during shutdowns:

  • Disable Fast Startup: Open legacy Control Panel → Power Options → Choose what the power buttons do. Click “Change settings that are currently unavailable,” uncheck “Turn on fast startup,” and save. Fast Startup hibernates kernel session state and ACPI hardware descriptors instead of performing a clean teardown.
  • Disable PCIe Link State Management: In your active Windows Power Plan → Change advanced power settings, expand PCI Express → Link State Power Management, and switch both “On battery” and “Plugged in” to Off.
  • Disable Spatial Multiplexing Power Save (SMPS): In Device Manager, right-click the AX201 → Properties → Advanced. Set “MIMO Power Save Mode” to “No SMPS” and “Transmit Power” to “5. Highest.”

3. BIOS/UEFI Fast Boot

In the laptop’s UEFI configuration, locate Fast Boot under Boot Configuration or POST Behavior. Switch it from “Minimal” to “Thorough” (or Disabled). This instructs the system firmware to perform full hardware enumeration and clear device registers during every boot cycle, rather than assuming pre-existing ACPI state validity.

The Hardware Escape Hatch: The 60-Second EC Reset

A caveat on permanence: while the configuration changes above drastically reduce or eliminate handoff crashes during day-to-day use, they do not rewrite motherboard firmware. Because CNVio2 relies on tightly coupled CPU power planes, a sudden kernel panic, thermal event, or power glitch can still occasionally cause the hardware state machine to deadlock.

When a Code 10 persists across reboots, software-level drivers cannot reach the device. The only recovery mechanism is a hard power drain to reset the motherboard’s Embedded Controller (EC) and bleed residual charge from the bus:

1
2
3
4
5
6
7

+---------------------------------------------------------+
| 1. Shut down OS completely                              |
| 2. Disconnect AC adapter and all external peripherals   |
| 3. Depress and hold physical Power Button for 60s       |
|    (Ignore temporary screen/fan activity)               |
| 4. Release, reconnect AC power, and boot normally       |
+---------------------------------------------------------+

Why This Works

Holding the power switch while unpowered forces the EC to drop its power rails, draining the motherboard filter capacitors and clearing the volatile registers holding the stalled ACPI D-state. On the subsequent boot, the BIOS initializes the CNVio2 CRF module from an absolute cold state, allowing both Linux and Windows to detect the device cleanly.

Summary

Cross-OS hardware bugs are rarely random; they are almost always the result of state mismatches across different kernel drivers sharing non-standard physical architectures.

On CNVio2 hardware like the Intel AX201, keeping Wi-Fi power-saving disabled across both Linux and Windows ensures the device remains in an accessible state during reboot transitions. If the state machine ever deadlocks, a 60-second hardware drain remains the definitive ground-truth reset.

If you are tracking similar low-level firmware or driver handoff anomalies, I’d be glad to discuss: syedanwaruddin08@gmail.com.