An attempt to manage the network stack has taken too long. When NDIS calls out into other drivers, NDIS starts a watchdog timer to ensure the call completes promptly. If the call takes too long, NDIS injects a bugcheck.
This can be caused by a simple deadlock. Look with "!stacks 2 ndis" or similar to see if any threads look suspicious. Pay special attention to the PrimaryThread from the NDIS_WATCHDOG_TRIAGE_BLOCK.
PrimaryThread is the thread on which NDIS initiated the operation. Usually, this is the first place to look, although the thread may have gone elsewhere if the operation is being handled asynchronously.
The value of Parameter 4 depends on the value of Parameter 2. Each number in this list corresponds to the same number in Parameter 2.
0x01 : 0
0x02 : The NET_PNP_EVENT_CODE of the stuck event. For more information about these codes, see NET_PNP_EVENT..
0x03 : The NDIS_STATUS code of the stuck indication. Use !ndiskd.help to decode it.
0x04 : 0
0x11 : 0
0x12 : The NET_PNP_EVENT_CODE of the stuck event. For possible values, see the previous list of values for item 2 in this list.
0x13 : The NDIS_STATUS code of the stuck indication. Use !ndiskd.help to decode it.
0x14 : 0
0x21 : 0
0x22 : 0
0x23 : The OID code of the stuck request. Use !ndiskd.help to decode it.
0x24 : The OID code of the stuck request. Use !ndiskd.help to decode it.
0x25 : 0
0x26 : 0
A miniport driver has not returned a NBL back to the stack for some time.
The address of the miniport block. Run !ndiskd.minidriver with this address for more information.
The !analyze debug extension displays information about the bug check and can be helpful in determining the root cause. Parameter 1 indicates the specific cause of the BUGCODE_NDIS_DRIVER_LIVE_DUMP bugcheck.
NDIS has detected and recovered from a serious problem in another network driver. Although the system was not halted, this problem may later cause connectivity problems or a fatal bugcheck.
This bug code occurs only in Windows 8.1 and later versions of Windows.