0x7C Debugging

I've been working on a thread (here) in which I managed to get my first look into an 0x7C. Unfortunately, it was not a Kernel-Dump and the user has been MIA since following my recommendations, so I imagined it's solved and he/she just never reported back.

BUGCODE_NDIS_DRIVER (7c)

This bug check indicates that a problem occurred with an NDIS driver.

So there's the basic definition of this particular bug check. Let's get into the debugging, shall we?

--------------------

BugCheck 7C, {1f, ffffe000027491a0, 1, 0}

^^ The 1st parameter of the bug check is 0x01 which indicates that the 2nd parameter of the bug check is a miniport address.
  
Let's look into it:

3: kd> !ndiskd.miniport ffffe000027491a0

MINIPORT

    [Pointer is unavailable; cannot dereference]

    Ndis Handle        ffffe000027491a0
    Ndis API Version   [Unreadable version value]
    Adapter Context    ffffe0000274b000
    Miniport Driver    ffffe0000274a068 - [Unreadable MiniBlock]  [Unreadable version value]
    Ndis Verifier      [Unreadable value]

    Media Type         802.3
    Physical Medium    802.3
    Device Path        String with 144 characters [Buffer at ffffc000005f88f0 is not available]
    Device Object      [DeviceObject at ffffe0000274a0a8 is not readable]
    MAC Address        [MAC address at ffffcf8001cfcfb0 is unavailble]

^^ We likely cannot read the Miniport driver or DevObj fields because it's not a Kernel-Dump. Anyway, from this, we can see that the type of media that disconnected was 802.3, which is WIRED ethernet.

STATE

    Miniport           PAUSING
    Device PnP         Started
    Datapath           00000002          ← DIVERTED_BECAUSE_MEDIA_DISCONNECTED
    NBL Status         NDIS_STATUS_MEDIA_DISCONNECTED
    Operational status [Unreadable value]
    Operational flags  [Unreadable value]
    Admin status       [Unreadable value]
    Media              MediaDisconnected
    Device Power       [Unreadable value]
    Driver Power       [Unreadable value]
    References         [Ref.ReferenceCount at ffffe0000274a328 is not readable]
    User Handles       0
    Total Resets       0
    Pending OID        None

^^ From the above we can see that 802.3 was reported disconnected, and because of that, there was a pause. The miniport cannot send data at this time because its media is disconnected. NDIS will intercept transmitted packets and immediately return them with an unsuccessful status code.

The problem is, we likely never return from this pause and/or disconnected state, at least we didn't at the time of the crash.

If we take a look at the call stack:

3: kd> kv
Child-SP          RetAddr           : Args to Child                                                           : Call Site
ffffd000`20186938 fffff800`00e542fd : 00000000`0000007c 00000000`0000001f ffffe000`027491a0 00000000`00000001 : nt!KeBugCheckEx
ffffd000`20186940 fffff800`00e3f485 : ffffe000`027491a0 00000000`00000000 ffffe000`02748020 ffffe000`0274a5e8 : ndis!ndisBugCheckEx+0x1d
ffffd000`20186980 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ndis!NdisMPauseComplete+0x1b235

^^ NDIS calls a miniport driver's MiniportPause function to initiate a pause request for a miniport adapter. The miniport adapter remains in the Pausing state until the pause operation is complete.

After a miniport driver completes all outstanding send requests and NDIS returns all the network data structures in outstanding receive indications to the driver, the driver calls NdisMPauseComplete to complete the pending pause request. After the driver calls NdisMPauseComplete, the miniport adapter is in the Paused state.

NDIS calls the MiniportRestart function to initiate a restart request for a miniport adapter that is paused.

As we can see however, this never occurred, and instead, NDIS called into a bugcheck which brought down the system.

--------------------

Overall, I recommended the user do two things:

1. Ensure their network drivers were up to date via the manufacturers website.

2. If the user was connecting wirelessly, remove the wireless from the equation and attempt to connect via wired ethernet for awhile and see if the crashes stop. If the user was using a wireless adapter (USB) instead of built-in wireless on the laptop, remove it.

Finally, if the above two failed, I mentioned likely a faulty NIC. I haven't heard anything bad back yet, and it has been over a week, so I imagine everything is okay. Hopefully.


That's all!