“Show us the stack back-trace. Did you forget to release a spinlock somewhere?”
It seems it reproduces only when I put one breakpoint in FilterSend and one in FilterSendComplete (given that I have multiple NBLs linked).
The stack trace looks like this:
“STACK_TEXT:
fffff802e6ccbf80 fffff802e50b6f11 : fffffa8002563a50 fffff802e5307180 fffff802e6ccc130 fffff78000000320 : nt!KeAccumulateTicks+0x575
fffff802e6ccc000 fffff802e50b7d98 : ffffffffffd1a000 fffff802e57a5502 fffff802e6ccc130 0000000000000000 : nt!KeUpdateRunTime+0x51
fffff802e6ccc030 fffff802e577beba : 0000000000010000 0000000000000000 000000000000004b 0000000000000001 : nt!KeUpdateTime+0x3f9
fffff802e6ccc220 fffff802e50854ae : 000000004d8d09c1 fffffa8002d4d940 fffff802e57a5580 0000000000000000 : hal!HalpTimerClockInterrupt+0x86
fffff802e6ccc250 fffff88001503da1 : fffff8800150559b fffff88006b73e00 fffffa8002d4d940 fffffa8002563a50 : nt!KiInterruptDispatchLBControl+0x1ce
fffff802e6ccc3e8 fffff8800150559b : fffff88006b73e00 fffffa8002d4d940 fffffa8002563a50 0000000000000003 : NDIS!ndisLastNblInNblChain+0x5
fffff802e6ccc3f0 fffff880014de909 : 0000000000000021 fffff802e6ccc679 0000000000000000 fffffa8002563a50 : NDIS!ndisAddNblsToTracker+0xbb
fffff802e6ccc420 fffff88006b74c00 : fffffa800269e030 fffff802e6ccc650 fffffa8002563a50 0000000000000000 : NDIS!ndisFilterSendNetBufferLists+0x10be9
fffff802e6ccc460 fffff88006b7028b : fffffa8000e2c070 fffffa800269e030 fffffa8000000021 fffffa8000000000 : <driver_name>!_Nbls_SendIngress+0x1e0
fffff802e6ccc500 fffff88006b700c8 : fffffa8000e2c070 fffffa8000e47470 fffffa800269f970 fffff80200000021 : <driver_name>!_ProcessNblsIngress+0xbb
fffff802e6ccc550 fffff88006b73e4b : fffffa8000e2c070 fffffa8000e47470 fffffa800269f970 0000000000000021 : <driver_name>!Nbls_StartIngress+0x58
fffff802e6ccc580 fffff880014cd650 : fffffa8000e2c070 fffffa800269f970 fffff80200000000 0000000000000021 : <driver_name>!FilterSendNetBufferLists+0x4b
fffff802e6ccc5c0 fffff880014cd97b : fffffa800169b1a0 0000000000000000 0000000000000002 fffff8800185bb01 : NDIS!ndisInvokeNextSendHandler+0x110
fffff802e6ccc6d0 fffff88001718987 : fffffa8001699002 fffffa800269f970 0000000000000000 fffff80200000021 : NDIS!NdisSendNetBufferLists+0x12b
fffff802e6ccc7b0 fffff880016c5fef : fffffa80027f9000 fffffa8002690001 0000000000000000 0000000000000000 : vmswitch!VmsExtPtRouteNetBufferLists+0x525a7
fffff802e6ccc880 fffff880014c9e2e : 0000000000000000 0000000000000000 fffffa8000000001 fffffa8000000004 : vmswitch!VmsPtNicReceiveNetBufferLists+0x34f
fffff802e6ccc940 fffff880014c97b9 : fffff802e6cccb02 fffff88001610100 0000000000000000 fffff88000000004 : NDIS!ndisMIndicateNetBufferListsToOpen+0x373
fffff802e6ccc9e0 fffff880014c9a05 : fffffa80016ba1a0 0000000000000000 0000000000000001 0000000000000000 : NDIS!ndisInvokeNextReceiveHandler+0x6b9
fffff802e6cccab0 fffff880032bb7f0 : 0000000000000000 0000000000000004 0000000000000000 fffffa8001760010 : NDIS!NdisMIndicateReceiveNetBufferLists+0xc5
fffff802e6cccb30 fffff880032bb44f : fffff802e6cccc01 0000000000000000 0000000000000000 fffffa8001760010 : E1G6032E!RxProcessReceiveInterrupts+0x138
fffff802e6cccba0 fffff88001528b0c : fffffa8002649140 fffff802e6cccc30 0000000000000000 fffffa80013ff2f0 : E1G6032E!E1000HandleInterrupt+0x8f
fffff802e6cccbd0 fffff880014c8f3a : fffffa8002649160 00000000ffffffff fffffa8002649140 0000000000000000 : NDIS!ndisMiniportDpc+0x5fddc
fffff802e6cccc70 fffff802e5082498 : fffff802e5309f00 000000000000006d fffffa80013e3118 fffff802e6ccce70 : NDIS!ndisInterruptDpc+0x9e
fffff802e6cccd00 fffff802e50b2d50 : fffff802e5307180 000000002cb7cd83 fffffa8002410440 0000000000000025 : nt!KiExecuteAllDpcs+0x198
fffff802e6ccce40 fffff802e50b2745 : 0000000000000000 fffff802e5307180 fffff88002df6860 fffff802e5307180 : nt!KiRetireDpcList+0xd0
fffff802e6cccfb0 fffff802e50b2549 : 0000000000000000 fffff802e5307180 fffffa8000d20930 0000000000000000 : nt!KxRetireDpcList+0x5
fffff88002df67b0 fffff802e514d398 : fffff88002df6968 0000000000000000 0000000000000000 0000000000000000 : nt!KiDispatchInterruptContinue
fffff88002df67e0 fffff802e50b6d78 : fffff88002df6a50 fffffffffffd9da6 0000000000000001 fffff88002df6a50 : nt!KiDpcInterrupt+0xc8
fffff88002df6970 fffff9600081a9c0 : ffffffff000000e5 fffffffffffd9da6 fffffffffffd9da6 fffffa8000000000 : nt!KeSetTimer+0xf8
fffff88002df69d0 fffff802e5033521 : fffffa8000d21070 fffffa8000d2a580 fffff901000ae020 fffffa8000d16300 : cdd!PresentWorkerThread+0x3d8
fffff88002df6c10 fffff802e5071dd6 : fffff802e5307180 fffffa8000d2a580 fffffa8000d16300 fffffa8000d17980 : nt!PspSystemThreadStartup+0x59
fffff88002df6c60 0000000000000000 : fffff88002df7000 fffff88002df1000 0000000000000000 0000000000000000 : nt!KiStartSystemThread+0x16
”
I use no spinlocks, etc. in the ingress & egress functions.
And one more thing:
Is it safe to change an MDL in a NB (given you restore the original after the clone)?
These are the steps I did:
- allocated a buffer for MDL;
- allocated the MDL with NdisAllocateMdl;
- set the MDL to the NB (using NET_BUFFER_FIRST_MDL);
- reset the data offset with NET_BUFFER_DATA_OFFSET(pNb);
- called NdisAdjustNetBufferCurrentMdl on the NB.
Is this method ok?
(I need to modify / change the MDL if the unused space is too small and I don’t want to / can’t split headers in 2 mdls).</driver_name></driver_name></driver_name></driver_name>