NDIS - crash in NETIO.SYS after NdisMSendNetBufferListsComplete
kern...@yahoo.com
hi all,
I modified the NDIS 6.0 DDK ( build 6000 vista ) sample e100bex for a
new NIC card. I retained the core and NDIS related logic and modified
ONLY the HW portions. All the synchronization mechanisms were never
touched.
Send/receive seems to be working fine even for heavy send and receive
loads. FTP send/receives and HTTP downloads simultaneously from
multiple threads ( processes ) works fine even for 2.5 GBytes xfers w/
good file xfer rates 9-11 MBYtes for 100 MB link
But it consistently crashes ( BSOD ) if i use any internet video
streaming applications.
THe bugcheck code usually points to an MDL being double-freed or POOL
corruption OR plain bad memory access as shown below. It generally
happens in NETIO.SYS or TCPIP.SYS
The last piece of code executed in my module was
NdisMSendNetBufferListsComplete ( ... )
crash dump analysis below. any clues ?
target - VISTA 32 bit
DDK - build 6000
thx
ugk
*******************************************************************************
*
*
* Bugcheck
Analysis *
*
*
*******************************************************************************
IRQL_NOT_LESS_OR_EQUAL (a)
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 a kernel debugger is available get the stack backtrace.
Arguments:
Arg1: 0000001b, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, bitfield :
bit 0 : value 0 = read operation, 1 = write operation
bit 3 : value 0 = not an execute operation, 1 = execute operation
(only on chips which support this level of status)
Arg4: 81fa4e79, address which referenced memory
Debugging Details:
------------------
WRITE_ADDRESS: 0000001b
CURRENT_IRQL: 2
FAULTING_IP:
hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+19
81fa4e79 8711 xchg edx,dword ptr [ecx]
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
BUGCHECK_STR: 0xA
PROCESS_NAME: Idle
TRAP_FRAME: 81cf1aa8 -- (.trap 0xffffffff81cf1aa8)
ErrCode = 00000002
eax=81cf1b28 ebx=81cf1b44 ecx=0000001b edx=81cf1b28 esi=ffffffff
edi=87c32d40
eip=81fa4e79 esp=81cf1b1c ebp=81cf1b38 iopl=0 nv up ei pl zr
na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000
efl=00010246
hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+0x19:
81fa4e79 8711 xchg edx,dword ptr [ecx] ds:
0023:0000001b=????????
Resetting default scope
LAST_CONTROL_TRANSFER: from 81cd87f7 to 81c818d0
STACK_TEXT:
81cf168c 81cd87f7 00000003 81cfad9c 00000000 nt!
RtlpBreakWithStatusInstruction
81cf16dc 81cd9264 00000003 0000001b 81fa4e79 nt!KiBugCheckDebugBreak
+0x1c
81cf1a88 81c8fd84 0000000a 0000001b 00000002 nt!KeBugCheck2+0x5f4
81cf1a88 81fa4e79 0000000a 0000001b 00000002 nt!KiTrap0E+0x2ac
81cf1b18 8c8f1bff 84ede7c0 84ede8a0 00000000 hal!
KeAcquireInStackQueuedSpinLockRaiseToSynch+0x19
81cf1b44 8c98025b 87c32d40 00000000 00000020 afd!
AfdTLFastDgramSendComplete+0xb3
81cf1b68 8c9802a7 84ede8a0 84ede7c0 00000001 tcpip!UdpEndSendMessages
+0xd3
81cf1b80 81a4c77a 850377b8 00000002 00000001 tcpip!
UdpSendMessagesDatagramsComplete+0x22
81cf1bb0 8c99710f 00000000 00000001 86eb8c58 NETIO!
NetioDereferenceNetBufferListChain+0xcf
81cf1bc4 821c341e 86ea2940 850377b8 00000001 tcpip!
FlSendNetBufferListChainComplete+0x1c
81cf1bf8 820ffbbb 868a20e8 850377b8 00000001 ndis!
ndisMSendCompleteNetBufferListsInternal+0xb8
81cf1c0c 8c88fa9c 87cc7698 850377b8 00000001 ndis!
NdisFSendNetBufferListsComplete+0x1a
81cf1c30 821c35c8 84f45a58 850377b8 00000001 pacer!
PcFilterSendNetBufferListsComplete+0xba
81cf1c50 af4f9e02 868a20e8 850377b8 00000001 ndis!
NdisMSendNetBufferListsComplete+0x70
81cf1c88 af4f23bb 85000018 a7c9e03e 0000d000 rtlTEST_NIC_MINIPORT!
MpHandleSendInterrupt+0x2a2 [d:\rtl8169\mp_nic.c @ 942]
81cf1ca4 821b5086 85000018 00000000 00000000 rtlTEST_NIC_MINIPORT!
MPHandleInterrupt+0x9b [d:\rtl8169\mp_main.c @ 1739]
81cf1cc8 820fd252 84f4401c 00000000 00000000 ndis!ndisMiniportDpc+0x81
81cf1ce8 81ca93ae 84f4401c 84f44008 00000000 ndis!ndisInterruptDpc
+0x8b
81cf1d50 81c913ee 00000000 0000000e 00000000 nt!KiRetireDpcList+0x147
81cf1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46
STACK_COMMAND: kb
FOLLOWUP_IP:
NETIO!NetioDereferenceNetBufferListChain+cf
81a4c77a 5b pop ebx
SYMBOL_STACK_INDEX: 8
SYMBOL_NAME: NETIO!NetioDereferenceNetBufferListChain+cf
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: NETIO
IMAGE_NAME: NETIO.SYS
DEBUG_FLR_IMAGE_TIMESTAMP: 478ad439
FAILURE_BUCKET_ID: 0xA_W_NETIO!NetioDereferenceNetBufferListChain+cf
BUCKET_ID: 0xA_W_NETIO!NetioDereferenceNetBufferListChain+cf
Followup: MachineOwner
---------
kern...@yahoo.com
In my own previous post the stack trace text alignment looked so
horrible, that i repost that portion, here, now. May look better
nt!RtlpBreakWithStatusInstruction
nt!KiBugCheckDebugBreak+0x1c
nt!KeBugCheck2+0x5f4
nt!KiTrap0E+0x2ac
hal!KeAcquireInStackQueuedSpinLockRaiseToSynch+0x19
afd!AfdTLFastDgramSendComplete+0xb3
tcpip!UdpEndSendMessages+0xd3
tcpip!UdpSendMessagesDatagramsComplete+0x22
NETIO!NetioDereferenceNetBufferListChain+0xcf
tcpip!FlSendNetBufferListChainComplete+0x1c
ndis!ndisMSendCompleteNetBufferListsInternal+0xb8
ndis!NdisFSendNetBufferListsComplete+0x1a
pacer!PcFilterSendNetBufferListsComplete+0xba
ndis!NdisMSendNetBufferListsComplete+0x70
x!MpHandleSendInterrupt+0x2a2 [d:\mp_nic.c @ 942]
x!MPHandleInterrupt+0x9b [d:\mp_main.c @ 1739]
ndis!ndisMiniportDpc+0x81
ndis!ndisInterruptDpc+0x8b
nt!KiRetireDpcList+0x147
nt!KiIdleLoop+0x46
Yu Hao
sample code.
I found that the old code(6000 version) has some bugs (e100bex) like release
spinlock too early and has been fixed in new WDK.
--
Thanks
Yu Hao
<kern...@yahoo.com>
??????:3ee34a1c-7a4a-454a...@u10g2000prn.googlegroups.com...
kern...@yahoo.com
Thanks Yu. This seems to fix the issue.
I only used 2 changes from the latest 2008 server DDK, not all.
1st change..
In
__inline PNET_BUFFER_LIST
MP_FREE_SEND_NET_BUFFER(
IN PMP_ADAPTER Adapter,
IN PMP_TCB pMpTcb
)
MP_TCB flags are cleared before NdisMFreeNetBufferSGList ( ....)
and 2nd change .
In MpHandleSendInterrupt ( ... )
if (Status != NDIS_STATUS_SUCCESS && Status !=
NDIS_STATUS_PENDING)
{
break;
}
Apparently the problem mentioned in my original posting disappeared
and everything were working fine for hours together, even under
multithreaded, heavy network load. But when i switched to gigabit
mode, under heavy stress, the same problem recurred ( BSOD for double
freeing .....BAD_POOL_REQUEST )
mmmm....wondering whether any more fixes are on their way for E100BEX,
or i have to figure out myself and post here, if solved...
thanks anyway Yu
--ugk
On Feb 18, 1:09 am, "Yu Hao" <hao...@attansic.com> wrote:
> Please get the latest WDK (for winserver2008) and compare with the new
> sample code.
> I found that the old code(6000 version) has some bugs (e100bex) like release
> spinlock too early and has been fixed in new WDK.
>
> --
>
> Thanks
> Yu Hao
> <kernw...@yahoo.com>
> ??????:3ee34a1c-7a4a-454a-ae9e-8d419ac94...@u10g2000prn.googlegroups.com...
>