Copyright © 2003 by Stephan Wolf. All rights reserved
Any device driver that you write has the potential risk of crashing the system. Thus, you should intensively test your driver before shipping it.
Network drivers only cause about 1% of all Windows system crashes for good reason: The official Microsoft NDISTest Tool is the acid test for all "lower edge" NDIS network drivers such as NDIS miniport and NDIS intermediate drivers.
If you write an NDIS driver, you should use NDISTest at any stage during your driver development to verify the driver's integrity and stability. Not only will NDISTest find bugs in your driver that cause system crashes, but it will also help you to write a fully NDIS conformant driver with respect to all of the following:
NDISTest can test all of the following NDIS drivers:
Although you can run NDISTest with just a single network card in one machine (see "one card tests" below), I recommend using two computers, four network cards, and two hubs to run NDISTest, as shown in Figure One.
Recommended Full NDISTest Hardware Setup
It's a good idea to use non-intelligent hubs or repeaters instead of intelligent switches for the test network. Some tests may fail or show warnings when switches are used because they filter the network traffic. If your network adapters so permit, you can connect them back-to-back directly (using a crossover cable) and omit the switch or hub.
An easy way to setup NDISTest with only one machine and two network cards is shown in Figure Two. If you have only one network card available, you can even omit the second network adapter and still run NDISTest.
Simple NDISTest Hardware Setup
NDISTest offers you the following test categories, which you can combine as desired. Each test category requires some or all of the hardware I just described.
For the communication channel between the server and the client add a "message device" (green) network adapter to both the client and the server machine. The two message devices can be anything that allows for TCP/IP to run on top of them. For instance, if your test and support devices are Wireless LAN adapters, the message devices can be standard Ethernet adapters.
Connect the two message devices to a "message network" that is separate from the private test network. Note that the message network does not need to be a private network and you may also connect other machines to it. If the message devices are the adapter cards that you ordinarily use to connect the client and server machines to your office LAN, and if you're using TCP/IP as the network protocol, you've already done this step.
Alternatively, you may also connect the two message devices to the test network, but I recommend that you use independent test and message networks.
In order to achieve an optimal test coverage, you should run NDISTest on two machines with all of the available 1c, 2c, and 2m tests enabled. If available, you should use a multi-processor machine as the client.
NDISTest is part of the Microsoft Hardware Compatibility Test (HCT). But it is also available as a stand-alone tool coming in a self-extracting archive file, which you can download from the Microsoft Windows Hardware & Driver Central (WHDC) at the NDIS Test Tool page
Note: The HCT is required to run the official WHQL tests, which qualify a device for the "Designed for Windows" logo. You can download the complete HCT in the WHQL Network Testing section (several hundred MB!). If you have MSDN Universal Subscription, then the HCT is included in your distribution CDs. After installing the HCT you will find NDISTest in
The current version of NDISTest (at the time of this writing) runs on Windows 2000, Windows XP, and Windows 2003. It does not run on Windows 98 or Windows ME. An older version of NDISTest does run on these older systems, namely version 3.91, and it is available from Microsoft WHQL (Windows Hardware Quality Labs) in their Network Testing section as file "ndt391.exe".
Note that you will find the term "trusted card" being used in earlier NDISTest versions, which is similar to what is now known as a "support device". However, with older NDISTest versions you need one trusted card in both the client and the server whereas newer NDISTest versions require only one support device in either the client or the server.
Installation of NDISTest is a fairly easy task: Simply run the downloaded self-extracting archive file and unzip the contained NDISTest files to a directory of your choice. Install NDISTest once on the client machine and once on the server machine.
Note: Once you extract the archived files, you can use the batch file "ndsetup.bat" to create further installation copies of NDISTest. For instance, to create the new directory "n:\ndistest" and copy a new installation of NDISTest there, open a command prompt in the current installation directory of NDISTest and enter the following command:
I recommend connecting a debugger to your client machine for several reasons:
In very rare cases NDISTest may also hit a breakpoint in the server. So you may need to also connect a debugger to the server machine then.
The Microsoft WinDbg debugger is available for download in the Microsoft WHDC section Microsoft Debugging Tools. If you have an NDISTest server machine you can run WinDbg on the server machine and connect it to the client machine.
During installation of NDISTest, all the debug symbols for NDISTest are copied to the directory "<cpu>\symbols" under the directory where you installed NDISTest. You should add this directory to your debugger's symbol path.
If you are unable to connect a debugger to your client or server machine, you can alternatively use a tool like SysInternals' freeware tool DebugView, which you can download from their utilities section. Actually you can use any tool or debugger (e.g. SoftICE) that will display kernel debug messages.
Another useful tool is a network sniffer that allows you to watch all the traffic on the test network. The sniffer tool should not use any of the test or support devices but should use an extra network adapter also connected to the test network. You should prefer to run the sniffer on a separate third machine.
Before you configure NDISTest, make sure to enable TCP/IP on both message devices and configure them to use the same IP subnet address. If you have DHCP enabled on the message devices, you should be ok. Check the IP addresses with the IPCONFIG command in a command prompt window if in doubt.
NDISTest will present you only those physical and virtual network adapters that are actually still available for the test, message, and support device entries. It is important to note that NDISTest will no longer show any entries that are associated with the same adapter once you select a listed adapter to be a test, message, or support device. This makes sense as you for instance cannot test an intermediate driver with a support device that is the physical adapter to which the IM is bound.
You need administrator privileges on the client and server machines in order to run NDISTest.
If you have a server machine, start NDISTest on the server first. Make sure you have administrator privileges on the server.
Test settings for server machine
The server is now fully configured and waiting to participate in any tests that the client will run.
Make sure you have administrator privileges on the client.
Note: If you are testing an NDIS intermediate driver, be sure to use an underlying network card that will pass NDISTest on its own. Run the tests that you intend to make on your NDIS IM driver on the "bare card" before you test your IM driver.
NDISTest will execute tests in the order they appear in the list.
Note: You can change the order of the tests by selecting a test script, holding down the <Ctrl> key, and moving the test script with the <Up> and <Down> keys.
Test settings for client machine
Note: When you start NDISTest for the first time on the test device, a message box might appear saying that you will have to restart the machine in order to enable the Driver Verifier on the test device. NDISTest enables Driver Verifier by default on the test device and you should leave it enabled to achieve an optimal test coverage.
How long a test run takes depends on the number of tests selected, the speed of the machine(s) and the speed of the network. This can be anything from less than a minute to several hours.
Here is how you can get a list of the results of all individual tests:
NDISTest will find lots of bugs and anomalies in your driver. It's really nit-picking and tests almost everything that has been specified in NDIS.
The quality of your NDIS miniport or intermediate driver will substantially increase when you run NDISTest against it. Do not wait to test your driver until you have added more features to it but test it as soon as you can install it for the first time. NDISTest will ensure your driver conforms to NDIS and will reveal any bugs at a very early stage.
Although available since the early 1990s, NDISTest has not become very popular amongst NDIS driver developers. Maybe because most people think NDISTest is only available in conjunction with the HCT. However, NDISTest is actually available separately from the HCT and is a great tool that will make your life easier.
NDISTest comes with a help file that has many details about how the program works internally. You will find information about the packet structure that NDISTest uses for the packets it sends out to the test network, a list of command line options, and much more. So it's really worth reading it.
Stephan Wolf has worked as an independent system software developer since 1988. He lives and works mainly in Germany, but sometimes abroad. His focus is on network driver development (not only) for all Windows variants (including CE). You can contact him at (hotmail sometimes "recognizes" serious email as spam, so try again if you get no answer).