If you ever wanted to handle TDI_EVENT_RECEIVE_DATAGRAM (http://msdn2.microsoft.com/en-us/library/ms801156.aspx) event handler in TDI, you would notice that it’s declaration is a bit strange(http://msdn2.microsoft.com/en-us/library/ms801622.aspx):
NTSTATUS ClientEventReceive( IN PVOID TdiEventContext, IN CONNECTION_CONTEXT ConnectionContext, IN ULONG ReceiveFlags, IN ULONG BytesIndicated, IN ULONG BytesAvailable, OUT ULONG *BytesTaken, IN PVOID Tsdu, OUT PIRP *IoRequestPacket );
Guess what? It’s declaration is the same as to a handler of TDI_EVENT_RECEIVE which sets event handlers for TCP protocol and not for UDP! If you want to handle UDP incoming data at TDI level, you most likely will need to find a correct declaration of handler function, because using declaration from MSDN will give your driver one more chance to blue screen 🙂
Thanks to www.osronline.com, I found a correct declaration: http://www.osronline.com/ddkx/w98ddk/vxdtdi_9lt9.htm which should have the following form:
NTSTATUS ClientEventReceiveDatagram( IN PVOID TdiEventContext, IN LONG SourceAddressLength, IN PVOID SourceAddress, IN LONG OptionsLength, IN PVOID Options, IN ULONG ReceiveDatagramFlags, IN ULONG BytesIndicated, IN ULONG BytesAvailable, OUT ULONG *BytesTaken, IN PVOID Tsdu, OUT PIRP *IoRequestPacket);
The most interesting thing, is that I spent 30 minutes trying to figure out what’s wrong in my code, until I noticed the presence of ConnectionContext param in the declaration of handler, so I asked myself: why would I recieve a connection context when handling connectionless protocol data … ? So I started googling.
Seems like this issue touches both local documentation for WDK and online documentation at http://msdn2.microsoft.com