Good day,
Can anybody explain why on some XP system with RTL8139 network
card my IM driver crashed on pass through Receive indication when
NdisGetReceivedPacket return NULL for received packet?
There is my ProtocolReceive function of IM passthru driver:
NDIS_STATUS CProtocol::Receive(
IN NDIS_HANDLE MacReceiveContext,
IN PVOID HeaderBuffer,
IN UINT HeaderBufferSize,
IN PVOID LookAheadBuffer,
IN UINT LookAheadBufferSize,
IN UINT PacketSize
) {
DbgPrintEx(DPFLTR_IHVNETWORK_ID, DPFLTR_TRACE_LEVEL, “>>> %08X
CProtocol::Receive()\n”, this);
if (
(m_ePowerState > NdisDeviceStateD0)
|| (m_pMiniport == NULL)
|| (m_pMiniport->m_ePowerState > NdisDeviceStateD0)
) {
DbgPrintEx(DPFLTR_IHVNETWORK_ID, DPFLTR_TRACE_LEVEL, “<<< %08X
CProtocol::Receive(): low power state, retrun failure status\n”, this);
return NDIS_STATUS_FAILURE;
}
NDIS_STATUS status = NDIS_STATUS_FAILURE;
PNDIS_PACKET pPacket = NdisGetReceivedPacket(m_hBindingHandle,
MacReceiveContext);
if (pPacket != NULL) {
PNDIS_PACKET pNewPacket = NULL;
NdisAllocatePacket(&status, &pNewPacket, m_hPacketPool);
if (status != NDIS_STATUS_SUCCESS) {
DbgPrintEx(DPFLTR_IHVNETWORK_ID, DPFLTR_TRACE_LEVEL, “<<<
%08X CProtocol::Receive(): NdisAllocatePacket(): failed, status %08X\n”,
this, status);
return status;
}
NDIS_PACKET_FIRST_NDIS_BUFFER(pNewPacket) =
NDIS_PACKET_FIRST_NDIS_BUFFER(pPacket);
NDIS_PACKET_LAST_NDIS_BUFFER(pNewPacket) =
NDIS_PACKET_LAST_NDIS_BUFFER(pPacket);
NDIS_SET_ORIGINAL_PACKET(pNewPacket,
NDIS_GET_ORIGINAL_PACKET(pPacket));
NDIS_SET_PACKET_HEADER_SIZE(pNewPacket, HeaderBufferSize);
NdisGetPacketFlags(pNewPacket) = NdisGetPacketFlags(pPacket);
NDIS_SET_PACKET_STATUS(pNewPacket, NDIS_STATUS_RESOURCES);
NdisMIndicateReceivePacket(m_pMiniport->m_hAdapter, &pNewPacket, 1);
NdisFreePacket(pNewPacket);
} else {
switch (g_aMediumArray[m_nMediumArrayIndex]) {
case NdisMedium802_3:
// fall through
case NdisMediumWan:
NdisMEthIndicateReceive(
m_pMiniport->m_hAdapter,
MacReceiveContext,
(PCHAR) HeaderBuffer,
HeaderBufferSize,
LookAheadBuffer,
LookAheadBufferSize,
PacketSize
);
break;
default:
DbgBreakPoint();
break;
}
}
DbgPrintEx(DPFLTR_IHVNETWORK_ID, DPFLTR_TRACE_LEVEL, “<<< %08X
CProtocol::Receive(): exited, status %08X\n”, this, status);
return status;
}
There is a crash dump analysis of such situation:
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address
at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 00000000, address which referenced memory
Debugging Details:
READ_ADDRESS: 00000000
CURRENT_IRQL: 2
FAULTING_IP:
+0
00000000 ?? ???
PROCESS_NAME: Idle
DEFAULT_BUCKET_ID: DRIVER_FAULT
BUGCHECK_STR: 0xD1
TRAP_FRAME: 8054ffd4 – (.trap 0xffffffff8054ffd4)
ErrCode = 00000000
eax=86309948 ebx=86365b40 ecx=86309948 edx=00000001 esi=00000003
edi=86365b48
eip=00000000 esp=80550048 ebp=80550070 iopl=0 nv up ei ng nz ac
po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010293
00000000 ?? ???
Resetting default scope
LAST_CONTROL_TRANSFER: from 00000000 to 804e187f
FAILED_INSTRUCTION_ADDRESS:
+0
00000000 ?? ???
STACK_TEXT:
8054ffd4 00000000 badb0d00 00000001 f5351bd2 nt!KiTrap0E+0x233
WARNING: Frame IP not in any known module. Following frames may be wrong.
80550044 f75950de 86365b48 80550178 86280bf4 0x0
80550070 f66260a6 86309948 861db008 00000014 NDIS!ndisMTransferData+0x109
80550090 f75950de 86365b48 80550178 8655c5e0 psched!MpTransferData+0x3c
805500bc f5377f0c 85c69cf0 861db008 00000014 NDIS!ndisMTransferData+0x109
805500dc f5359a05 862f7008 861db008 00000000 tcpip!ARPXferData+0x26
80550188 f534a922 86260200 861ce88a 0000006c tcpip!IPRcvPacket+0x32b
805501c8 f534f4ad 00000000 861db008 861ce868 tcpip!ARPRcvIndicationNew+0x149
805501f8 f75a1c72 862f7008 861db008 861ce868 tcpip!ARPRcv+0x42
8055022c f66265d7 85c245a8 861db008 00000000
NDIS!EthFilterDprIndicateReceive+0x17c
8055026c f75a1bd6 8655c5e0 861db008 861ce868
psched!ClReceiveIndication+0x21b
805502a0 f7b8125e 862ca7f8 861db008 861ce868
NDIS!EthFilterDprIndicateReceive+0xe0
805502e0 f7b80508 861db008 861ce868 0000000e
nsmuxtun!CProtocol::Receive+0x1ae
[d:\projects\sdg-mba\trunk\src\cpp\client\driver\multiplexer\windows\protocol.cpp
@ 284]
80550304 f75a1bd6 85d076ac 861db008 861ce868
nsmuxtun!ProtocolFactory::Receive+0x38
[d:\projects\sdg-mba\trunk\src\cpp\client\driver\multiplexer\windows\protocolfactory.cpp
@ 114]
80550338 f7bbe493 861dbd98 861db008 861ce868
NDIS!EthFilterDprIndicateReceive+0xe0
80550368 f7bbe802 861db008 0000ffff 861db008
RTL8139!RTFast_IndicatePacket+0x85
80550378 f7bbe889 861db008 804e4a15 8665a3d8 RTL8139!RTFast_RcvDpc+0x50
80550390 f759a712 001db008 80559080 80558e20
RTL8139!RTFast_HandleInterrupt+0x2f
805503ac 804dbbd4 861db074 861db060 00000000 NDIS!ndisMDpc+0xff
805503d0 804dbb4d 00000000 0000000e 00000000 nt!KiRetireDpcList+0x46
805503d4 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x26
STACK_COMMAND: kb
FOLLOWUP_IP:
nsmuxtun!CProtocol::Receive+1ae
[d:\projects\sdg-mba\trunk\src\cpp\client\driver\multiplexer\windows\protocol.cpp
@ 284]
f7b8125e eb05 jmp nsmuxtun!CProtocol::Receive+0x1b5
(f7b81265)
FAULTING_SOURCE_CODE:
280: LookAheadBuffer,
281: LookAheadBufferSize,
282: PacketSize
283: );
> 284: break;
285:
286: default:
287: DbgBreakPoint();
288: break;
289: }
SYMBOL_STACK_INDEX: c
SYMBOL_NAME: nsmuxtun!CProtocol::Receive+1ae
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nsmuxtun
IMAGE_NAME: nsmuxtun.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 47567534
FAILURE_BUCKET_ID: 0xD1_CODE_AV_NULL_IP_nsmuxtun!CProtocol::Receive+1ae
BUCKET_ID: 0xD1_CODE_AV_NULL_IP_nsmuxtun!CProtocol::Receive+1ae
Followup: MachineOwner
–
Andrew Rukavishnikov
Sunbay Software Crimea Ltd.