I’m using DriverNetworks to access TCP sockets via kernel-mode TDI, and
I’m getting an assert when my code queries information about the
connected socket. Here’s the code snippet in question:
===============================
// prepare irp & call the transport
TdiBuildQueryInformation (irp,
m_pDevice,
FileObj,
(PIO_COMPLETION_ROUTINE) pReq->RequestNotifyObject, //
completion routine, sh be NULL
pReq->RequestContext, //
completion context
QueryType,
pBuf
);
TDI_STATUS Status = CallDriver(irp, pReq->RequestNotifyObject==NULL);
ASSERT (Status != TDI_PENDING); // Async not supported
if (Status != TDI_PENDING && pReq->RequestNotifyObject==NULL) {
*BufferSize = (ULONG)irp->IoStatus.Information;
FreeIrp(irp);
}
I’m getting the ASSERT because CallDriver() is returning TDI_PENDING
when run on Vista, whereas every other version of Windows completes this
request synchronously (and there’s no reason it can’t complete it
synchronously). What’s interesting is that by the time I hit the
ASSERT, I’ve observed the following:
- The request buffer already contains the desired information (IP
Address, for example). - Windbg claims that the IRP has been completed already.
Anyone else run into this yet? My theory is that there is a bug in the
TDI->WSX translation layer, and they are returning PENDING unnecessarily
(legal, to be sure, but a PITA for the code that calls CallDriver()).
As such, I’m tempted to get rid of the ASSERT, and just flip a
TDI_PENDING result into TDI_SUCCESS for this call.
Thoughts and insights greatly appreciated.
David Yon
Tactical Software