On a Windows Server 2008 you may see the following bugcheck from the NIC miniport driver if the network card or machine is entering a sleep condition.
Fatal System Error: 0x00000124
If a miniport receives a Request (OID_PNP_SET_POWER) to enter low power, and this Request takes too long (greater than the CheckForHangTimeInSeconds), NDIS might issue a MiniportReset. This can lead to a unexpected behavior in the Miniport (in some cases a bugcheck).
The simplest workaround for the Miniport developer is to increase the CheckForHangTimeInSeconds to allow the Miniport to take longer when handling the Request. Only the Miniport vendor will know how long it requires to handle this Request so that is why it should be set by the Miniport.
Specifically: To work around this issue, increase the CheckForHangTimeInSeconds in the call to NdisMSetMiniportAttributes by setting the value accordingly in the NDIS_MINIPORT_ADAPTER_REGISTRATION_ATTRIBUTES.
While the system is up and running and at some point it needs to go to sleep (S3 or D3 for devices): NDIS generates an OID_PNP_SET_POWER Request and sends this down to each of the Miniports. In most cases the Request is handled in under 2 seconds, but in some cases it may take 3 plus seconds to complete. NDIS has a built in feature to make sure no Requests are taking too long. If it finds that a Miniport is taking too long, it will issue a reset to that particular Miniport. The time between these checks is given by the CheckForHangTimeInSeconds which is specified in the call to NdisMSetMiniportAttributes and set in the structure NDIS_MINIPORT_ADAPTER_REGISTRATION_ATTRIBUTES.
According to the documentation:
The interval, in seconds, at which NDIS should call the MiniportCheckForHangEx function. If a driver has not responded to an OID request or send request within two successive calls to MiniportCheckForHangEx, NDIS can call the driver's MiniportResetEx function.
The actual interval that NDIS uses when calling MiniportCheckForHangEx is always a multiple of two seconds. For example, if you specify five seconds the actual interval will be approximately four seconds.
Specifying zero for this member indicates that NDIS should call MiniportCheckForHangEx at the NDIS default two-second interval.
In this case the CheckForHangTimeInSeconds was not set so the default value of 2 seconds was used. In the worst case (this is highly dependent on the system and current execution) there will be about 2 seconds used to complete the request. The Miniport did not complete the request in this timeframe, so NDIS issued a MiniportReset.
The issue here is that the Miniport is already in D3 at this point, so NDIS should not issue a MiniportReset. However, due to this issue, the reset is still toggled. Adjusting the time via the CheckForHangTimeInSeconds should allow miniport to handle the request.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.
Artikel-id: 967915 - Laatst bijgewerkt: 26 jun. 2009 - Revisie: 1