I have a driver that monitors TDI packets. It successfully receives IOCTL_TDI_SEND io controls in the Dispatch method, at least from the particular process that I am interested in monitoring. And it receives IOCTL_TDI_RECEIVE io controls from other processes. However, for the one procecss which I interested in monitoring I never see any IOCTL_TDI_RECEIVE io controls.
My driver resides in the PNP_TDI group of drivers as the last tag with a start order of 3.
I tried implementing the FastIoDeviceControl method to cpture fast io as well and checked for the rpStack->Parameters.DeviceIoControl.IoControlCode value for any IOCTL_TDI_RECEIVE codes and never saw any.
I definitely know that the target procecss is calling WSArecv. Any idea why I ma not seeing the recieve in my dispatch, fast io or otherwise?
Any input is appreciated. I am new to OSR and look forward to learning from this most excellent forum.
Humm…
Could the process be using TDI_EVENT_RECEIVE instead of TDI_RECEIVE?
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-285139-
xxxxx@lists.osr.com] On Behalf Of xxxxx@swbell.net
Sent: Monday, April 30, 2007 9:50 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] IOCTL_TDI_RECEIVE not passed to my driver from certain
processesI have a driver that monitors TDI packets. It successfully receives
IOCTL_TDI_SEND io controls in the Dispatch method, at least from the
particular process that I am interested in monitoring. And it receives
IOCTL_TDI_RECEIVE io controls from other processes. However, for the
one procecss which I interested in monitoring I never see any
IOCTL_TDI_RECEIVE io controls.
My driver resides in the PNP_TDI group of drivers as the last tag with
a start order of 3.
I tried implementing the FastIoDeviceControl method to cpture fast io
as well and checked for the rpStack-
>Parameters.DeviceIoControl.IoControlCode value for any
IOCTL_TDI_RECEIVE codes and never saw any.
I definitely know that the target procecss is calling WSArecv. Any idea
why I ma not seeing the recieve in my dispatch, fast io or otherwise?
Any input is appreciated. I am new to OSR and look forward to learning
from this most excellent forum.
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Thomas,
Could the process be using TDI_EVENT_RECEIVE instead of TDI_RECEIVE?
In my brief experience with TDI, TDI_RECEIVE seems to be relatively rare beast, compared to registration of ClientEventReceive() handler and friends…
Anton Bassov
Have you tried using TDIMon(sysinternals.com) yet? It would give you a
bird’s-eye view of what TDI IRPs are being generated from within that
process context.
From: xxxxx@swbell.net
Reply-To: “Windows System Software Devs Interest List”
>To: “Windows System Software Devs Interest List”
>Subject: [ntdev] IOCTL_TDI_RECEIVE not passed to my driver from certain
>processes
>Date: Mon, 30 Apr 2007 21:49:45 -0400 (EDT)
>
>I have a driver that monitors TDI packets. It successfully receives
>IOCTL_TDI_SEND io controls in the Dispatch method, at least from the
>particular process that I am interested in monitoring. And it receives
>IOCTL_TDI_RECEIVE io controls from other processes. However, for the one
>procecss which I interested in monitoring I never see any IOCTL_TDI_RECEIVE
>io controls.
>My driver resides in the PNP_TDI group of drivers as the last tag with a
>start order of 3.
>I tried implementing the FastIoDeviceControl method to cpture fast io as
>well and checked for the rpStack->Parameters.DeviceIoControl.IoControlCode
>value for any IOCTL_TDI_RECEIVE codes and never saw any.
>I definitely know that the target procecss is calling WSArecv. Any idea why
>I ma not seeing the recieve in my dispatch, fast io or otherwise?
>Any input is appreciated. I am new to OSR and look forward to learning from
>this most excellent forum.
>
>—
>Questions? First check the Kernel Driver FAQ at
>http://www.osronline.com/article.cfm?id=256
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer
_________________________________________________________________
Interest Rates NEAR 39yr LOWS! $430,000 Mortgage for $1,299/mo - Calculate
new payment
http://www.lowermybills.com/lre/index.jsp?sourceid=lmb-9632-19132&moid=14888
You must monitor ClientEventReceive calls.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntdev…
> I have a driver that monitors TDI packets. It successfully receives
IOCTL_TDI_SEND io controls in the Dispatch method, at least from the particular
process that I am interested in monitoring. And it receives IOCTL_TDI_RECEIVE
io controls from other processes. However, for the one procecss which I
interested in monitoring I never see any IOCTL_TDI_RECEIVE io controls.
> My driver resides in the PNP_TDI group of drivers as the last tag with a
start order of 3.
> I tried implementing the FastIoDeviceControl method to cpture fast io as well
and checked for the rpStack->Parameters.DeviceIoControl.IoControlCode value for
any IOCTL_TDI_RECEIVE codes and never saw any.
> I definitely know that the target procecss is calling WSArecv. Any idea why I
ma not seeing the recieve in my dispatch, fast io or otherwise?
> Any input is appreciated. I am new to OSR and look forward to learning from
this most excellent forum.
>
> In my brief experience with TDI, TDI_RECEIVE seems to be relatively rare
beast, compared to registration of ClientEventReceive() handler and
friends…
Yes. But:
a) if only a partial buffer is provided to ClientEventReceive, the it must
allocate TDI_RECEIVE IRP and return it via parameter
b) if ClientEventReceive failed due to SO_RCVBUF being full, then the receive
pipeline is stalled and the only way of restarting it is to sent TDI_RECEIVE
IRP.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks. I will pursue the TDI_EVENT_RECEIVE. I was hoping to be able to modify the received data but see that the TDI_EVENT_RECEIVE causes the transport to “give the client the opportunity to copy all or part of the buffered TSDU”. I will see if I can actually modify it in the ClientEventReceive…if indeed that is the mechanism used. Thanks again for the direction.
That was it! The process I am targeting issues TDI_SET_EVENT_HANDLERs for connects and all types of receives immediately on start up…before any clients even connect. I did not realize it worked that way. I was passing through all IOCTLs for all processes until I commanded my driver to watch for a particular process pid, but by then it was too late. So changing to “detour” all TDI_SET_EVENT_HANDLERS from the start and then filtering for the pid I need on the event receive side works. Thanks so much for the direction all!