NDIS Edge Case Testing
 

Testing "At the Edges"

If you are a driver developer then it is ultimately your responsibility to insure that the driver functions properly and is reliable in the field. It is certain that you have developed test methods that demonstrate functionality and stress the driver's normal operation. You may also have tested your driver using the Driver Test Manager (DTM) for a WHQL digital signature.

Edge cases are simply conditions that aren't encountered (often...) in normal operation. This note is just a reminder of some NDIS-related edge conditions that need to be examined as part of your test scenarios.

Some of these suggestions may seem "just plain stupid". But we all know (or soon learn) that users often do stupid things and expect the system to continue normally. In addition, testing "at the edges" just might reveal  real problem that can occur naturally but just didn't occur under ordinary testing.

General Testing Methodology

Only you know the real functionality of your driver. You need to develop a suite of suitable load/stress tests that can be run when the edge condition is imposed. These may be tests that you created yourself or may be test scenarios that you build with test tools like NetPerf or PCATTCP.

So, run your driver-specific load/stress test and then impose the edge condition.

There are two obvious goals to edge case testing:

Event Survival

You need to define that for yourself. At the very least it means that the system should not crash and basic network connectivity should be normal after imposing the edge condition.

Post Event Behavior

It is up to you to decide how your software should behave after the edge case event has happened. For example, how your driver's services are restarted after an edge case is up to you.

After thinking about this you may have other goals that are specific to your driver. Do at least consider how the system and your software would/should behave after the edge case is reversed.

Use Driver Verifier

This should be obvious.

Obvious NDIS Edge Cases

Here are the obvious NDIS edge cases. Not all apply to all driver types.

Your Driver Uninstall Under Load

Start up your load/stress test. Then use the Network Control Panel to uninstall your driver.

Lower-Level Miniport Disable

If your driver is a protocol or filter driver start up you load/stress test. Then use the Network Control Panel to disable the miniport binding.

Lower-Level Miniport Uninstall

Same as above except you uninstall the miniport while your load/stress test is running.

Adapter Surprise Removal

If your driver is a protocol or filter driver consider binding to a USB-Ethernet adapter. Then perform a surprise removal while your load stress test is running.

Filter Install

Start up your load/stress test. Then install some additional filter in the stack. You can use one of the WDK filter driver samples as the additional filter for the test.

If your driver is a NDIS 6 filter or protocol driver, then perform this this test with a NDIS 5 and a NDIS 6 filter. The pause/resume behavior may be different.

Filter Uninstall

After installing the additional filter as described above restart your load/stress test. It should, of course, run perfectly. Then uninstall the additional filter.

Power Transitions

Start up your load/stress test. Then cause the host to enter sleep/standby conditions and then to return to the power-on state.

Adapter Property Changes

If you are writing a NDIS filter or protocol driver then changes to adapter properties should also be considered to be edge cases to be considered and possibly tested.

This isn't a complete list. Just a few properties to make you think along the right lines:

NDIS Task Offload

Start up your load/stress test. Then change various adapter task offload properties. test.

Packet Size

Some adapters offer properties that allow changing the packet size (e.g., various Jumbo packet sizes). Start up your load/stress test. Then change the packet size settings.

Locally Administered Address

Start up your load/stress test. Then change the locally administered MAC address.

IP Interface Settings

Start up your load/stress test. Then cause IP interface settings to be changed.

Some of these conditions may not influence your driver's functionality, so ignore them.

System Limitations

Here the most obvious system limitation is memory.

Memory Limitations

Use Driver Verifier to introduce memory limitations. Start your load/stress test and observe behavior.

PCAUSA Home · Privacy Statement · Products · Ordering · Support · Utilities · Resources
Mailing Lists  · PCAUSA Newsletter · PCAUSA Discussion List

Rawether for Windows, Rawether .NET, WinDis 32 and NDIS Press are trademarks of Printing Communications Assoc., Inc. (PCAUSA)
Microsoft, MS, Windows, Windows Vista, Windows 95, Windows 98, Windows Millennium, Windows 2000, and Win32 are registered trademarks and Visual C++ and Windows NT are trademarks of the Microsoft Corporation.
Copyright © 1996-2012 Printing Communications Assoc., Inc. (PCAUSA)
Last modified: January 01, 2012