examining TDI structures during kernel debugging

NTDEV
1

Hi,

During kernel debugging of a TDI filter driver I could find a way to look into structures such as TCP_REQUEST_QUERY_INFORMATION_EX, TRANSPORT_ADDRESS etc.

kd> dt TRANSPORT_ADDRESS
*** WARNING: Unable to verify timestamp for VMwareService.exe
*** ERROR: Module load completed but symbols could not be loaded for VMwareService.exe
Symbol TRANSPORT_ADDRESS not found.
kd> dt TDI_ADDRESS_IP
Symbol TDI_ADDRESS_IP not found.

For NDIS, I know there is NDIS extension ndiskd in windbg. Does such an extension exists for TDI structures or there is some other way?

Thanks,
Chandra

2

The best case scenario is that you need to add a tdi! before the symbol
name, but I seriously doubt that tdi ships with types intact. As far as
a TDI extension, I don’t know, but considering that it sounds like parts
of TDI are not really documented (that’s my understanding; I really
don’t know), I kind of doubt it.

Good luck,

mm

xxxxx@gmail.com wrote:

Hi,

During kernel debugging of a TDI filter driver I could find a way to look into structures such as TCP_REQUEST_QUERY_INFORMATION_EX, TRANSPORT_ADDRESS etc.

kd> dt TRANSPORT_ADDRESS
*** WARNING: Unable to verify timestamp for VMwareService.exe
*** ERROR: Module load completed but symbols could not be loaded for VMwareService.exe
Symbol TRANSPORT_ADDRESS not found.
kd> dt TDI_ADDRESS_IP
Symbol TDI_ADDRESS_IP not found.

For NDIS, I know there is NDIS extension ndiskd in windbg. Does such an extension exists for TDI structures or there is some other way?

Thanks,
Chandra

3

Hi Chandra,

I am not aware of a debugging extension for TDI that ships with any version of the Debugging Tools(perhaps I missed it). The simplest way to examine TDI data structures using the kernel debugger would be to dump the raw memory address(e.g. dd ) and use the TDI header files in parallel to help you piece together a particular instance of the data structure in question.

typedef struct _TRANSPORT_ADDRESS {
LONG TAAddressCount; // number of addresses following
TA_ADDRESS Address[1]; // actually TAAddressCount elements long
} TRANSPORT_ADDRESS, *PTRANSPORT_ADDRESS;

Ron> Date: Mon, 17 Dec 2007 10:41:30 -0500> From: xxxxx@gmail.com> To: xxxxx@lists.osr.com> Subject: [ntdev] examining TDI structures during kernel debugging> > Hi,> > During kernel debugging of a TDI filter driver I could find a way to look into structures such as TCP_REQUEST_QUERY_INFORMATION_EX, TRANSPORT_ADDRESS etc.> > kd> dt TRANSPORT_ADDRESS> WARNING: Unable to verify timestamp for VMwareService.exe> ERROR: Module load completed but symbols could not be loaded for VMwareService.exe> Symbol TRANSPORT_ADDRESS not found.> kd> dt TDI_ADDRESS_IP> Symbol TDI_ADDRESS_IP not found.> > For NDIS, I know there is NDIS extension ndiskd in windbg. Does such an extension exists for TDI structures or there is some other way?> > Thanks,> Chandra > > —> NTDEV is sponsored by OSR> > For our schedule of WDF, WDM, debugging and other seminars visit: > http://www.osr.com/seminars> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
_________________________________________________________________
Don’t get caught with egg on your face. Play Chicktionary!
http://club.live.com/chicktionary.aspx?icid=chick_wlhmtextlink1_dec

4

Also, if you see yourself wishing this type of functionality in the
future as well, I would consider writing a WinDbg extension. Just copy
one of the existing samples (under sdk) to start with, and something
like this will be quite easy, unless you make the mistake of reading the
documentation first; don’t do that until you need to. While I much
prefer the new EngExtCpp framework, getting it to build without using
the new MSVCRT8 and getting all the fun that comes with installing
anything that uses it really sucks, unless you rebuild the EngExtCpp
sources themselves. Not all that hard, but it definitely complicates a
first time project., so you might wish to use the DbgEng model, which
works quite well. Once you venture from common WinDbg tasks, the
documentation of DbgEng (for either type of extension) will become a
huge problem, but you won’t need to do that for this. My guess would
that to get a WinDbg extension (DbgEng variety) built that dumps one TDI
structure will take half a day or less, assuming that you start with a
sample.

Good luck,

mm

Ronald Riddle wrote:

Hi Chandra,

I am not aware of a debugging extension for TDI that ships with any
version of the Debugging Tools(perhaps I missed it). The simplest way
to examine TDI data structures using the kernel debugger would be to
dump the raw memory address(e.g. dd ) and use the TDI header
> files in parallel to help you piece together a particular instance of
> the data structure in question.
>
> typedef struct _TRANSPORT_ADDRESS {
> LONG TAAddressCount; // number of addresses following
> TA_ADDRESS Address[1]; // actually TAAddressCount elements long
> } TRANSPORT_ADDRESS, *PTRANSPORT_ADDRESS;
>
>
> Ron
>
> > Date: Mon, 17 Dec 2007 10:41:30 -0500
> > From: xxxxx@gmail.com
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] examining TDI structures during kernel debugging
> >
> > Hi,
> >
> > During kernel debugging of a TDI filter driver I could find a way to
> look into structures such as TCP_REQUEST_QUERY_INFORMATION_EX,
> TRANSPORT_ADDRESS etc.
> >
> > kd> dt TRANSPORT_ADDRESS
> > WARNING: Unable to verify timestamp for VMwareService.exe
> > ERROR: Module load completed but symbols could not be loaded for
> VMwareService.exe
> > Symbol TRANSPORT_ADDRESS not found.
> > kd> dt TDI_ADDRESS_IP
> > Symbol TDI_ADDRESS_IP not found.
> >
> > For NDIS, I know there is NDIS extension ndiskd in windbg. Does such
> an extension exists for TDI structures or there is some other way?
> >
> > Thanks,
> > Chandra
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>
> ------------------------------------------------------------------------
> Don’t get caught with egg on your face. Play Chicktionary! Check it out!
> http:</http:>

5

Simply use the ‘type’ information in your own driver. If you have included
TDI header files (tdikrnl.h?) in your own driver build, then, your private
PDB sympols will have these types in them.

prefix the typename with your driver. so, if your driver is tdifilt.sys try

kd> dt tdifilt!TDI_ADDRESS

If these are not structures that are in the DDK header files, well, you are
out of luck :wink:

And editorially: Private symbols for TDI.SYS would probably not help you
too much. The ‘guts’ of what happens in TDI occurs in the transport itself.
The role TDI.SYS plays is pretty much just a ‘broker’ between transports &
clients and some helper routines. Now, private symbols for TCPIP.SYS would
(potentially) more useful.

Good Luck,
-dave

David R. Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, December 17, 2007 10:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] examining TDI structures during kernel debugging

Hi,

During kernel debugging of a TDI filter driver I could find a way to look
into structures such as TCP_REQUEST_QUERY_INFORMATION_EX, TRANSPORT_ADDRESS
etc.

kd> dt TRANSPORT_ADDRESS
*** WARNING: Unable to verify timestamp for VMwareService.exe
*** ERROR: Module load completed but symbols could not be loaded for
VMwareService.exe Symbol TRANSPORT_ADDRESS not found.
kd> dt TDI_ADDRESS_IP
Symbol TDI_ADDRESS_IP not found.

For NDIS, I know there is NDIS extension ndiskd in windbg. Does such an
extension exists for TDI structures or there is some other way?

Thanks,
Chandra

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

Much better idea, Dave.

Thanks,

mm

David R. Cattley wrote:

Simply use the ‘type’ information in your own driver. If you have included
TDI header files (tdikrnl.h?) in your own driver build, then, your private
PDB sympols will have these types in them.

prefix the typename with your driver. so, if your driver is tdifilt.sys try

kd> dt tdifilt!TDI_ADDRESS

If these are not structures that are in the DDK header files, well, you are
out of luck :wink:

And editorially: Private symbols for TDI.SYS would probably not help you
too much. The ‘guts’ of what happens in TDI occurs in the transport itself.
The role TDI.SYS plays is pretty much just a ‘broker’ between transports &
clients and some helper routines. Now, private symbols for TCPIP.SYS would
(potentially) more useful.

Good Luck,
-dave

David R. Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, December 17, 2007 10:42 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] examining TDI structures during kernel debugging

Hi,

During kernel debugging of a TDI filter driver I could find a way to look
into structures such as TCP_REQUEST_QUERY_INFORMATION_EX, TRANSPORT_ADDRESS
etc.

kd> dt TRANSPORT_ADDRESS
*** WARNING: Unable to verify timestamp for VMwareService.exe
*** ERROR: Module load completed but symbols could not be loaded for
VMwareService.exe Symbol TRANSPORT_ADDRESS not found.
kd> dt TDI_ADDRESS_IP
Symbol TDI_ADDRESS_IP not found.

For NDIS, I know there is NDIS extension ndiskd in windbg. Does such an
extension exists for TDI structures or there is some other way?

Thanks,
Chandra

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

lately I have been on a diet rich in ‘low hanging fruit’ :slight_smile:
-d

“Martin O’Brien” wrote in message
news:xxxxx@ntdev…
> Much better idea, Dave.
>
> Thanks,
>
> mm
>