BSOD 79 (NDIS_INTERNAL_ERROR): causes and diagnosis

Status / error code:		Category:

Constant name:
Source:		Operating System:
Description: The Network Driver Interface Specification stack detected an unrecoverable internal error.

Could be also:
Constant	Type	OS
ELIBACC	errno	Linux
EFTYPE	errno	Mac
EOVERFLOW	errno	Solaris

Previous	Next
PFN_LIST_CORRUPT	PAGE_FAULT_IN_NONPAGED_AREA

NDIS_INTERNAL_ERROR

NDIS internal network stack failure for NDIS_INTERNAL_ERROR

NDIS_INTERNAL_ERROR is bug check code 0x0000004F. This bug check belongs to NDIS, the Windows kernel networking driver framework. The failing component is usually a miniport, filter, lightweight filter, protocol driver, virtual switch, VPN, firewall, packet-capture, or offload path that broke NDIS state.

How to read it in a dump

Use the stack and NDIS verifier output to identify whether the crash is in send, receive, reset, pause, restart, power, or NBL ownership.
The first parameter is usually the NDIS-specific subcode to interpret with symbols and documentation.
This is a driver-model failure, not an IP routing or DNS error.

What to check

Enable NDIS verifier and Driver Verifier for the NIC, virtual switch, VPN, firewall, and packet-capture drivers.
Check recent NIC driver updates, offload settings, teaming, virtualization, and filter-driver ordering.
Inspect NET_BUFFER_LIST ownership and completion paths.

References

Dump evidence

Preserve the complete dump, the four bug-check parameters, the exact Windows build, loaded-module list, and the event timeline immediately before the stop. AllStat summarizes the condition as “this result”; that sentence identifies the failure class, while the parameters and stack determine which object, driver, processor, or subsystem instance was involved.

Analysis order

Run WinDbg !analyze -v, then inspect the documented meaning of each parameter instead of relying only on the probably-caused-by line.
find the earliest abnormal event: driver update, firmware change, device reset, storage error, verifier report, resource exhaustion, or application hang connected with ndis / internal.
keep third-party filter, security, storage, graphics, and virtualization drivers in the module inventory; removing evidence before dump analysis can obscure the responsible path.

Do not repeatedly reboot a machine affected by this result before collecting the dump and event logs. Recovery actions should follow the component identified by the stack and parameters, not merely the symbolic stop-code name.

Looking for a different code? Search another status or error code.