Test TCP is a simple sockets-based command-line utility that can be used
to send or receive TCP streams and UDP datagrams. Although it has limited
flexibility, it can generate fairly heavy network traffic.
A NDIS driver should be able to handle edge conditions (adapter surprise
removal, driver uncheck or uninstall, power transitions, application abort)
while multiple TTTCP TCP streams are actively running in each direction.
PCAUSA Test TCP
Occasionally there is a need to test network software on networks that
"have problems" such as random packet drop and delays. This is especially
true if you are using an unreliable protocol such as UDP or network media
such as 802.11.
The PCAUSA Interface Impairment Generator is intended to provide a modest
impairment capability in software. In some cases this limited capability may
PCAUSA NDIS Interface Impairment Generator
Prokash Sinha is a Senior I/O Developer at Hewlett-Packard. He is
currently working on Network I/O design for next generation of fabrics to be
used on enterprise class servers. Prokash's blog covers a lot of ground
including insights into performance measurement and NDIS debugging. A
The Microsoft Network Devices Platform team, a.k.a the NDIS team, has a
blog of interest to NDIS developers. The blog discusses debugging,
Getting started with NDISKD - Part 1 of a Beginner’s Guide to
Debugging with NDISKD.
NDISKD and !miniport - Part 2 of a Beginner’s Guide to Debugging with
Debugging with NDISKD - Part 3 of a Beginner’s Guide to Debugging
Anurag is an escalation engineer in the Microsoft Platforms Global
Escalation Team. His blog provides excellent insight into NDIS debugging
This paper describes how you can enable debug trace messages in the network
configuration subsystem of the Microsoft® Windows® family of operating systems.
This paper was presented by Stephan at WinHEC 2006.
Stephan's paper can also be downloaded
as a Word document.
This note describes how you debug some types of NDIS drivers (NDIS
protocols and filters) with WinDbg Host and Target both running in VMWare
WinDbg Connections for DTM Tests
Just a brief note of observations made at PCAUSA during DTM testing.
During DTM testing it is desirable to have WinDbg running on the DTM
Client machine - even if there are no driver faults. During some tests the
DTM Client display may be blank and the debugger output is the only way to
observe that the test is actually running.
At PCAUSA we noticed that tests involving Sleep/Hibernation sometimes
hang returning from S4 if IEEE 1394 is used as the WinDbg connection. This
is especially true when testing on Windows XP.
The Sleep/Hibernation tests were more
likely to run without problems if a serial link is used as the WinDbg
Remember that the WinDbg target machine must have a real hardware serial
interface. A USB-to-Serial converter cannot be used on the WinDbg target,
although it can be used on the WinDbg host.
Your mileage may vary...