This file contains answers to some of the most frequently asked questions about the Ndis Tester. If you run into a problem, please check to see if your question has been answered here before contacting PSS or the ndiststr alias. Thanks!

Why is my client machine hanging in the middle of the stress tests? This is usually due to data corruption in a received packet. If you do not have a debugger connected, connect one now! Tests should always be run with a debugger connected. Immediately prior to all tester breakpoints, it writes a message out to the debugger giving the reason for the breakpoint, and often including pointers to several structures which might be of interest. Note that the server machine will also hit a breakpoint if corrupted data is received, so you really need to have a debugger connected to both machines.

Why am I getting failures when setting multicast addresses?

Most likely you have a protocol still bound. If you have the Ndis Tester released with NT 3.51, then you are probably seeing many failures here. The newer version will report just one, and then adjust the total number of multicast addresses that it will test. The problem is caused by still bound protocols taking up one or more of the multicast addresses. The actual multicast address used can tell you which protocol is at fault. If the address is 03-00-00-00-00-01, then it is NetBeui. If the address is 03-00-5E-00-00-01, then it is TCP/IP.

Where can I find documentation for the Ndis Tester?

The documentation can be found on the Microsoft Developer Network Development Platform Premium Release for Windows NT® Workstation. For Windows NT® 3.51, it was on the third CD-ROM. The documentation is in file \hct\doc\hctg_c05.doc.

What versions of Windows NT® can I run the Ndis Tester on?

Previously released versions run on Windows NT® 3.51. There is also a version available for Windows 95. Sorry, the Ndis Tester will not run on Windows NT® 3.5. With the release of Windows NT® 4.0, there will be binaries for Windows NT® 3.51 and Windows® 95 as well as for Windows NT® 4.0.

My MAC driver is giving lots of errors in the query information tests, saying that the OIDs are not valid for query info. What is wrong?

This will happen if your MAC driver returns the same list for OID_GEN_SUPPORTED_LIST for both query information and query statistics. (Basically, for MacRequest and MacQueryGlobalStatistics). The list returned should be different based on which path is used to query it. This is not a problem for miniports (unless you are running the original Windows 95), as ndis.sys handles the adjusting of the list.

My miniport driver will handle up to 64 multicast addresses, but the tester is getting only a maximum of 32. In fact, the query OID_802_3_MAXIMUM_LIST_SIZE is returning 32. Why is this happening?

The ndis miniport wrapper currently only supports 32 multicast addresses. So even if your miniport really supports more, this is all that Windows NT® will currently be able to use.

What is the difference between a warning and a failure?

A failure is generated when the tester is able to determine that something is wrong. For instance, the card was not able to receive all packets that were sent. A warning is generated for situations where something unexpected happened, but the behavior may well be expected for that particular card. An example is cards that have a fixed lookahead. After a "setlookahead" command, the value read back as the actual lookahead will be the fixed value, not that which the tester tried to set. But that while that is correct behaviour for a card with a fixed lookahead, it is probably not correct with other cards. Hence the warning.

When I run the tester on my card, I get several warnings (which are expected). Can I still submit this card to WHQL for certification?

Yes, but please document in your submission that these warnings are expected. That will make things easier for both you and WHQL.

What is the criteria for passing the stress tests?

To pass the stress tests, the driver must complete the test without crashing the system or having any data corruption. In addition, everything that pended must complete properly within a reasonable amount of time. Data transfers must not fail. It is ok if packets are dropped. A warning is generated if there are failed sends. You should investigate to make sure there wasn’t a real problem causing them to fail (out-of-resources is ok).

Who do I contact if I am having problems with the Ndis Tester?

You should call PSS (Product Support Services). If you do not already have a support contract, you can call (800) 936-3500 for support contract information. While there is an e-mail alias available for questions/comments concerning the ndis tester (ndiststr@microsoft.com), we would prefer you only use that for suggestions concerning the tester. While the alias is monitored, do not expect a quick response to any questions posed there.

What information might PSS ask me for?

You should have ready

1. the platform you are testing on,
2. the version of the tester you are using,
3. What script the failure occurred in,
4. the log from this script if it is available,
5. the last 100 lines of output to the debugger, including a stack trace, if it was a bugcheck or a breakpoint was hit.

Where do I get the debugger symbols for the ndis tester?

If you get the tester from the HCT/DDK, the symbols are contained in the driver (ndistest.sys). Just put a copy of ndistest.sys in your symbols\sys directory. If you got the tester from the web site, you should have a copy of ndistest.dbg. Copy it to they symbols\sys directory. For Windows 95, there should always be a ndistest.sym file in addition to the driver (ndistest.vxd).

My card is having failure in the multicast receive tests. This is happening when testing the promiscuous and all-multicast filters. What is happening?

We have found several ethernet drivers with this problem. What we discovered was that setting a multicast address when the promiscuous or all-multicast filter was set, basically turned off that filter. We traced the problem to the driver not checking for all-multicast or promiscuous being set when it was setting the new multicast address.

Is there any criteria for what cards I should use as the trusted and server cards for the tests?

Both trusted and server cards should be similar in capability to the test card. Ie, they should have about the same thru-put and have similar CPU usage. What this really means is to NOT mix 8-bit, 16-bit, EISA, and PCI cards.

Sometimes when running a stress test, I see the following message on the debugger: "NdtStressDpc: WARNING - Client Open Instance 1 increasing Server 1 MaxSequenceNumber to 513." What does this mean?

In some of the stress tests, there is a "window" which specifies how far ahead of the server the client is allowed to get. In these tests, the client sends packets which the server responds to in some way. What has happened here is that the client is already at the limit ahead of the server (ie, it hasn’t received any responses to the last window_size packets). It is going to increase the window size by one, assuming that the server must have dropped some packets. If you get a whole bunch of these, it usually means that the server stopped--either card just hung up, or a breakpoint was hit on the server. If you get just a couple of these, there is no real problem. Make sure that your server card (and the machine it is running on) is good enough to handle your test card. If it server is much less efficient than the test card then the server is almost always going to be overrun.

Where can I get an updated version of the tester?

The latest official version of the tester (that being used by WHQL) is available on ftp.microsoft.com/services/whql/network/tests. It should be there as a self- extracting executable ndistest.exe.

My stress tests are hitting a breakpoint with the following message: "DPC Routine 8012c90e > 1sec, 230 INTs 0 ISR Time." What does this mean?

This can happen if you are running the tester on a checked build. This means that the tester is spending too much time in its DPC. The normal (retail) build of Windows NT® does not have such a check--it will just appear to lock up for the duration of the test.

I am getting an error in the 1c_ginfo tests that says "Driver failed to set bytes_returned or bytes_needed properly." The debugger is giving me a message that says "NdtRequestComplete: WARNING --BytesWritten[4] != BytesNeeded[0]". What is going on here?

There are several possibilities here. If your driver is a MAC, you are not handling properly the case when an NdisRequest query is made with a NULL buffer. Your driver needs to set the BytesNeeded in that case. If your driver is a miniport running on Windows NT® 4.0, it is probably the same problem. If your driver is a miniport running on Windows NT® 3.51 or Windows® 95, there was a bug in ndis.sys in the query for the current multicast list. If this was the error/warning you were seeing, it can be ignored.

Under Windows 95, I am getting lots of failures with my miniport in 1c_ginfo.tst. The message is that this OID is "Not valid for queryinfo." This is not happening under Windows NT®. What is going on?

There was a bug in Windows® 95, where querying miniport’s supported OIDs list for NdisRequest returned the same list as for QueryGlobalStatistics. This should be fixed in OPK2.

Can I run WAN/ISDN testing with Dial-up/RAS server running?

No, you can’t. You should stop the Diup-up/RAS server related services on the test server machine. The WAN/ISDN test server machine has to be a Windows NT® machine.

How can I run WAN/ISDN testing on Windows® 95 OSR2?

You need to install two software updates. One is the Diup-up Networking Upgrade. It’s on Microsoft Web site http://www.microsoft.com/windows/getisdn/dload.htm. The other is the TAPI2.1 upgrade. It’s also on the Microsoft Web site http://www.microsoft.com/communications/exes/tapi21.exe.