problem with NdisChainBufferAtFront

[turambar <n-nospam@free.fr>]

Hello,

I'm trying to develop a miniport driver, using netvmini that allows a
usermode application to transfer datas to the miniport, as if it came
from the real network.

When a usermode application writes in the appropriate device, the buffer
is placed in the receive list of the miniport and dispatched to the
protocols and socket.

I'm still having a problem with the NdisChainBufferAtFront function.

When I don't chain any buffer, there is no problem (even if no data is
transmitted to the higher layers of the network) but when I want to
chain this buffer, I get the blue screen with the message :
DRIVER_IRQL_NOT_LESS_OR_EQUAL

Even if I low the IRQL just before the action...

here is a part of the DispatchWrite function

KIRQL irql=KeGetCurrentIrql();
[...]
KeLowerIrql(DISPATCH_LEVEL);
[...]
pBuffer=Irp->MdlAddress;
pBuffer->Next = NULL;
NdisChainBufferAtFront(pPacket, pBuffer);
NdisMIndicateReceivePacket(AdapterHandle, &pPacket, 1);
[...]
KeRaiseIrql(irql, &irql);

There is the same problem if I use NdisAllocateBuffer on this function
or on the registerDevice function

My guess is that I need to allocate a memory that is accessible to NDIS,
copy the content of Irp->MdlAddress to this memory and chain that memory
to the packet.

But I couldn't do it already.

If this is the right way, can anyone help me ?

Otherwise, how can I resolve this problem ?

thanks in advance

[Gianluca Varenni]

Why are you playing with IRQLs?

If you debug your crash, I'd bet it crashes when calling
"KeLowerIrql(DISPATCH_LEVEL)". That dispatch routine is probably executing
at PASSIVE_LEVEL, you are asking to lower the IRQL (which is non-sense) to
an IRQL which is higher.

Have a nice day
GV

--
Gianluca Varenni, Windows DDK MVP

CACE Technologies
http://www.cacetech.com

"turambar <n-no...@free.fr>"
<turambarnn...@discussions.microsoft.com> wrote in message
news:AB0C2655-E916-40A5...@microsoft.com...

[Pavel A.]

Lowering IRQL this way is a no-no.
Remember that NDIS_BUFFER is actually a MDL,
so if you have just a plain memory buffer - convert to a MDL.

Besides of that, there shouldn't be any irql issues: netvmini is a
deserialized miniport,
so it's ok to indicate receive at either dispatch or passive irql.

Good luck,
--PA

"turambar <n-no...@free.fr>"
<turambarnn...@discussions.microsoft.com> wrote in message
news:AB0C2655-E916-40A5...@microsoft.com...

[turambar <n-nospam@free.fr>]

"Gianluca Varenni" wrote:

> Why are you playing with IRQLs?
>
> If you debug your crash, I'd bet it crashes when calling
> "KeLowerIrql(DISPATCH_LEVEL)". That dispatch routine is probably executing
> at PASSIVE_LEVEL, you are asking to lower the IRQL (which is non-sense) to
> an IRQL which is higher.
>

Hello,

Thanks but even if I don't call KeLowerIrql, the problem is the same. I used
this function because the error message is DRIVER_IRQL_NOT_LESS_OR_EQUAL.

I still don't know how to solve it.

TT

[Pavel A.]

Meaning of DRIVER_IRQL_NOT_LESS_OR_EQUAL can be
also a page fault in invalid context - which is not actually related to
IRQLs.

Have a good look at your changes in the WDK sample.

--PA

"turambar <n-no...@free.fr>"
<turambarnn...@discussions.microsoft.com> wrote in message

news:E9FD80D7-9D5A-43CD...@microsoft.com...