AX211: Recurring 0x9F DRIVER_POWER_STATE_FAILURE at shutdown — deadlock between tcpip bind-pause and

Liu_lio · ‎08-25-2026

Hello,

I'd like to report a reproducible driver bug on the AX211 (CNVi) with what I believe is a fairly complete dump analysis. I'm posting in the hope that it reaches the driver team, since the usual troubleshooting steps have been exhausted.

System

HP Victus 15-fa2xxx laptop, i7-13620H (13th gen, Raptor Lake-H)
BIOS F.08 (HP firmware 15.8)
Windows 11 25H2, build 26200.9168
Intel Wi-Fi 6E AX211, driver 24.70.0.3 (2026-07-29, sys 23.50.23.1); Bluetooth 24.70.0.4
Fast Startup disabled, PnPCapabilities=256 set on the NIC

Symptom Since KB5121003 (2026-08-12) — but note the first crash predates it by a day, so the patch looks like an aggravator, not the origin — the machine BSODs with 0x9F on roughly 25% of shutdowns/reboots. The crash happens deep in the shutdown path after the screen goes off; with auto-reboot on, the user just sees "shutdown turned into a boot". 24 crashes total between 2026-08-11 and 2026-08-25. Two distinct sub-signatures, same underlying disease:

Sub-signature A — Arg1=3 (classic power IRP blocked, 10 crashes) Blocking thread waits in ndis!ndisSetSystemPower → ndisPowerSaveStop → ndisAoAcStop → ndisRequestNicActive → KeWaitForSingleObject (8/17 sample) or in tcpip!FlpWaitForMiniportToReturnTransmittedPackets (multiple samples): the TCP/IP stack, while pausing the binding, waits forever for the miniport to return transmitted packets. The D3 SET_POWER IRP is parked on \Driver\Netwtw14.

Sub-signature B — Arg1=4 (PnP sync timeout 300s, 8 crashes, becoming dominant) PnP thread: nt!PnpProcessTargetDeviceEvent → ndisPnPIrpQueryRemove/ndisDevicePnPEventNotifyFiltersAndAllTransports → (pacer/nwifi/vwififlt filter stack) → ndis!ndisAcquireMiniportPnPEventLock → KeWaitForSingleObject — dead-waiting on the miniport PnP event lock for the full 300.015s. Meanwhile the thread that holds that lock path is stuck in ndisBindEngine::UpdateBindings → ndisPauseProtocol → tcpip!FlPnpEvent → FlpWaitForMiniportToReturnTransmittedPackets — again waiting for Netwtw14 to return TX packets. ndiskd !miniport on the block shows Driver: Netwtw14, device instance PCI VEN_8086 / DEV_51F1, and "Bind operations are in progress" with the hung bind thread. So: two threads, each waiting for the other's path through the driver, watchdog kills at 300s.

The !analyze failure bucket blames pacer/pci, but both are bystanders — ndiskd !miniport directly names Netwtw14.

What has been tried (no improvement, ~25% baseline throughout)

Driver 24.20 → 24.50 → 24.70.0.3 (latest OEM-channel WHQL). 24.70 crashed 2 of 7 power transitions (~29%). Note: 24.70 resets PnPCapabilities on every reboot; we re-apply, but the Arg1=4 path ignores it anyway.
HP BIOS F.07 → F.08 (firmware 15.8). No change.
PnPCapabilities=256 + all Wake/offload registry knobs off. Reduced crashes when idle-D3 was the trigger, but shutdown path still fires.
Fast Startup off. No change (already had HiberbootEnabled=0).
Router WMM/U-APSD and "WiFi connected at shutdown" as variables — ruled out by A/B.
A mitigation attempt (scheduled task disabling the NIC just before shutdown via Disable-NetAdapter) crashed 1-for-1: the disable REMOVE IRP walks the same ndisPnPRemoveDevice → BindEngine::UpdateBindings → ndisPauseProtocol → tcpip!FlpWaitForMiniportToReturnTransmittedPackets path and hangs in the same place. This actually corroborates the analysis: any path that pauses the binding stalls on the driver not returning TX packets.

Ask

Is this a known issue in the 24.5x/23.50.2x driver line? The bind-pause/FlpWaitForMiniportToReturnTransmittedPackets hang signature looks structural, not environmental.
Is there a beta/24.80 driver that changes the TX-packet-return or PnP-event-lock behavior?
If it would help engineering, I can provide full kernel MEMORY.DMP analysis excerpts (cdb + ndiskd) on request — the minidumps attached are from crashes 22 and 23 on driver 24.70.0.3.

Thanks!

JeanetteC_Intel · ‎08-25-2026

The dual sub-signature analysis, ndiskd miniport output, and mitigation test results are well-documented and will be directly useful as we work through this.

Given the depth of your analysis, I will need deeper analysis on this issue.

If you are able to provide the full kernel MEMORY.DMP analysis excerpts (cdb + ndiskd), those would be valuable for our deeper review. You can attach them directly to this thread.

For reference, the clean driver installation guide is available here: https://www.intel.com/content/www/us/en/support/articles/000005600/wireless/legacy-intel-wireless-products.html — though I recognize this is likely familiar given your testing history.

JeanetteC_Intel · ‎08-25-2026

Please disregard the earlier reply.

The dual sub-signature analysis, ndiskd miniport output, and mitigation test results are well-documented and will be directly useful as we work through this. We will conduct a deeper review of this issue and will share an update as soon as one is available.

For reference, the clean driver installation guide is available here: https://www.intel.com/content/www/us/en/support/articles/000005600/wireless/legacy-intel-wireless-products.html — though I recognize this is likely familiar given your testing history.

Please don't hesitate to reply if you have any additional information or questions.

Liu_lio · ‎08-26-2026

Thank you for the deeper review — and for the quick correction, no problem at all.

An update that may be useful for engineering while the review is in progress: crash #26 happened this morning (2026-08-26 11:37), and it adds two data points that were not in the original report.

1) Sub-signature A (Arg1=3) confirmed on driver 24.70.0.3. All three previously captured 24.70-era crashes were Arg1=4 (PnP sync timeout). Today's is Arg1=3 — the classic blocked power IRP. So both sub-signatures coexist on 24.70.0.3, same as on 24.50.

!analyze -v (full kernel dump, not minidump — CrashDumpEnabled was raised to kernel dump after the original post):

DRIVER_POWER_STATE_FAILURE (9f)
Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time
Arg3: nt!TRIAGE_9F_POWER
FAILURE_BUCKET_ID: 0x9F_3_POWER_DOWN_tcpip!FlpWaitForMiniportToReturnTransmittedPackets

Blocked thread (the D3 SET_POWER IRP path):

tcpip!FlpWaitForMiniportToReturnTransmittedPackets+0x14
tcpip!FlpUninitializePacketProviderInterface+0x52
tcpip!FlPnpEvent+0x1ac
tcpip!Fl48PnpEvent+0xe
ndis!ndisInvokeNetPnPEvent+0x54
ndis!ndisDeliverNetPnPEventSynchronously+0xbf
ndis!ndisPnPNotifyBinding+0x11a
ndis!ndisPauseProtocolInner+0x82
ndis!ndisPauseProtocol+0x74
ndis!Ndis::BindEngine::Iterate+0x1b4
ndis!Ndis::BindEngine::UpdateBindings+0xab
ndis!Ndis::BindEngine::ApplyBindChanges+0x142
ndis!ndisPrepForLowPowerCommon+0xb4
ndis!ndisPrepForLowPower+0x17
ndis!ndisSetDevicePower+0x33a
ndis!ndisSetPower+0x99
ndis!ndisPowerDispatch
nt!IopPoHandleIrp / PopIrpWorker   ← D3 SET_POWER IRP on \Driver\Netwtw14

This is the same bind-pause/TX-return stall as in the original post, now captured on the D3 power IRP path itself rather than only via the PnP-event path.

2) ndiskd !miniport on today's dump shows a media-state inconsistency at crash time.

Intel(R) Wi-Fi 6E AX211 160MHz
Driver: Netwtw14  v23.1          (24.70.0.3 package, sys 23.50.23.1)
Device instance: PCI\VEN_8086&DEV_51F1&SUBSYS_00948086&REV_01\3&11583659&1&A3
Power: D0
Datapath:          DIVERTED_BECAUSE_MEDIA_DISCONNECTED
NBL status:        NDIS_STATUS_MEDIA_DISCONNECTED
Operational status DOWN / DOWN_NOT_CONNECTED
Media:             MediaDisconnected
Miniport media:    Connected        ← contradiction with the above
Bind operations are in progress    .thread /p ffffae0da6510040  ← the hung bind thread

Two things stand out:

The crash 8/25 sample had Media Connected / Interface Up; today's has the datapath diverted due to media disconnect — so the hang reproduces both with the link up and with the link down at shutdown, further ruling out RF environment as the trigger.
At hang time the miniport reports Media: MediaDisconnected while Miniport media: Connected — the driver's internal media state and NDIS's view disagree. If the TX path is drained/diverted on media disconnect after tcpip already queued sends into the miniport, FlpWaitForMiniportToReturnTransmittedPackets would wait forever on NBLs the driver no longer intends to complete — which matches the sub-signature A stack exactly.

Caveat in the interest of accuracy: !pendingnbls on this dump found 0 NBLs — but a bugcheck-time kernel dump does not carry the NBL pool tracking data (that lives in the NDIS debugger data block and is only reliable in live/hypervisor dumps), so this is not evidence that the TX queue was empty.

I've preserved the full 2.4 GB kernel dump from this crash and can produce any additional cdb/ndiskd excerpts on request — happy to run specific commands if the driver team tells me what would help (e.g. !miniport -ref, !miniport -log, !ndk, the adapter-context fields, or a live kernel dump captured while the hang is in progress, which the machine can produce on demand via NMI/DedicatedDumpFile if that is preferred).

Also attaching today's minidump (crash #26, Arg1=3 on 24.70.0.3) for the set.

Attachment

attach\082626-16234-01.dmp — today's minidump (needs copying into attach\ first)

Checklist before posting

Copy C:\Windows\Minidump\082626-16234-01.dmp into bsod-tools\upstream-report\attach\
Read back once for tone (no demands, factual, offers specific next steps)
Post as reply in the same thread, do NOT create a new thread

Liu_lio · ‎08-26-2026

Quick correction: the last two sections of my previous reply ("Attachment — attach\..." and "Checklist before posting
— ...") are internal working notes that were pasted in by mistake — please disregard them. The intended content ends
at "Also attaching today's minidump (crash #26, Arg1=3 on 24.70.0.3) for the set."

JeanetteC_Intel · ‎08-26-2026

Thank you for the additional details from crash #26. The confirmed coexistence of both sub-signatures on driver 24.70.0.3 and the media-state inconsistency you captured are solid data points that add a lot of clarity to the overall picture.

I will look into this internally and share an update as soon as one is available. Your specific questions regarding whether this is a tracked issue in the 24.5x/23.50.2x driver line and whether a 24.80 build addresses the TX-packet-return or PnP-event-lock behavior will be checked internally as well, and answers will be included once the update is ready.

I will also keep in touch in case we need any additional details from your end.

Feel free to reply anytime if you have anything else to add in the meantime. I appreciate the thoroughness of your analysis throughout this.

Liu_lio · ‎08-26-2026

A quick update while the review is in progress: crash #27 happened last night (2026-08-27 02:04 local), on the first shutdown after #26.

It reproduces crash #26 exactly:

FAILURE_BUCKET_ID: 0x9F_3_POWER_DOWN_tcpip!FlpWaitForMiniportToReturnTransmittedPackets
Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time

Identical blocked-thread stack: D3 SET_POWER IRP path → ndisSetPower → ndisPrepForLowPower → BindEngine::ApplyBindChanges → ndisPauseProtocol → tcpip!FlPnpEvent → FlpWaitForMiniportToReturnTransmittedPackets.
!miniport shows the same media-state inconsistency as #26 at crash time: datapath DIVERTED_BECAUSE_MEDIA_DISCONNECTED, NBL status NDIS_STATUS_MEDIA_DISCONNECTED, Media: MediaDisconnected — while Miniport media: Connected — and "Bind operations are in progress" with the hung bind thread being the same thread !analyze identifies as blocked.
Driver 24.70.0.3 (sys 23.50.23.1) in place; the PnPCapabilities=256 mitigation was still set and survived this reboot.

For context: that is now crashes #25 (Arg1=4, same deadlock observed from the PnP-event-lock side), #26 and #27 (both Arg1=3) on three consecutive days — two consecutive shutdowns, same sub-signature, same media-state contradiction, all with current mitigations in place.

Attaching #27's minidump for the set. The full 2.6 GB kernel dump from #27 is also preserved, and I can produce any additional cdb/ndiskd excerpts on request.

Liu_lio · ‎08-27-2026

Hi Jeanette,

As promised, here are the cdb + ndiskd excerpts and the SSU report.

Attachments

AX211-9F-excerpts-3crashes.txt — consolidated cdb/ndiskd excerpts from the three consecutive crashes on 24.70.0.3 (#26 8/26 Arg1=3, #27 8/27 Arg1=3, #28 8/28 Arg1=3). Contains:
- !analyze -v failure signature (identical bucket on all three: 0x9F_3_POWER_DOWN_tcpip!FlpWaitForMiniportToReturnTransmittedPackets)
- The fully-symbolized 28-frame blocked-thread stack — the thread carrying the D3 SET_POWER IRP is itself the bind thread, parked in tcpip!FlpWaitForMiniportToReturnTransmittedPackets via ndisPrepForLowPower → BindEngine::ApplyBindChanges → ndisPauseProtocol
- !miniport output for each crash — the media-state contradiction (NDIS: MediaDisconnected / datapath DIVERTED_BECAUSE_MEDIA_DISCONNECTED, driver-internal: Miniport media: Connected) reproduces identically all three times, with "Bind operations are in progress" and the hung bind thread
- !pendingnbls (0 found, with the caveat that bugcheck dumps don't carry NBL pool tracking data — noted in the file)
SSU-report.txt — Intel SSU 4.3.2 full system scan.

One observation from cross-reading the three dumps

The three crashes are not merely similar — they are identical at every level I can measure: same bucket, same stack frame-for-frame, same miniport state (down to References=0n26 and Pending OID=None in all three), same media-state contradiction. Given that two of the three hung with the link disconnected (media already down at shutdown) and one earlier sample hung with the link up, the trigger appears independent of RF state. The reproducible invariant is the driver's internal media state disagreeing with NDIS while a bind pause is in flight — if the TX path is drained or diverted on the driver's internal "disconnected" state after tcpip has already queued sends, FlpWaitForMiniportToReturnTransmittedPackets would wait on NBLs the driver no longer intends to complete. That is what all three stacks show.

All three full kernel dumps (2.39 / 2.60 / 2.50 GB) are preserved. If engineering wants the dump files themselves, tell me the preferred upload path and I'll get them there — happy to run any additional commands (specific !miniport flag variants, adapter-context fields, live NMI dump during a hang) to spec.

Please let me know if anything else is needed.

Best regards, Liu_lio