NDIS User Mode I/O (NDISUIO)
Version Dependencies
Summary
Microsoft introduced the Wireless Zero Configuration (WZC)
service with Windows XP RTM (Build 2600). WZC manages 802.11 WLAN
connections if the user has checked "Use Windows to configure my wireless
network settings" in the WLAN adapter's properties under the Wireless Networks
tab.
One Microsoft component of WZC is the NDIS User Mode I/O
(NDISUIO) NDIS protocol driver.
NDISUIO is a Microsoft-signed in-box driver, meaning that
NDISUIO is already part of Windows XP and in most situations is already bound to
installed 802.3 miniports.
In addition, Microsoft provided source to NDISUIO driver and a
companion uiotest application as part of the Windows XP Build 2600 DDK. NDISUIO
is an excellent NDIS protocol driver sample.
Since NDISUIO is a
signed in-box driver, some developers have tried to rely on accessing the
in-box NDISUIO driver so that they didn't have to develop their own protocol
driver.
Unfortunately, using that strategy means that they are assuming
that the in-box driver will not change (or will always be there in the first
place). Here is the problem:
Between Windows XP
Build 2600 and XP SP1, Microsoft changed the IOCTL values that the in-box driver
uses changed from FILE_ANY_ACCESS to (FILE_READ_ACCESS | FILE_WRITE_ACCESS).
This change
inadvertently causes anyone using the old IOCTL values to talk to the new SP1
in-box driver to fail with "Error 50: The request is not supported" when issuing
IOCTL_NDISUIO_BIND_WAIT."
With the introduction of the Windows Server 2003 version of the
Windows DDK Microsoft has removed the NDISUIO sample. NDISUIO has been
replaced with the renamed and functionally-equivalent NDISPROT sample.
Starting with Windows Server 2003 developers should consider the NDISUIO driver
to be a system component reserved exclusively for use by Microsoft. You should
use the Windows Server 2003 DDK NDISPROT sample as the starting point for
development of your own NDIS protocol driver.
Recommended Solution
The lesson to be learned here is not to develop software that
depends on the Microsoft-signed in-box NDISUIO driver. The API supported by
NDISUIO is NOT a supported Windows service that you can depend upon.
Instead of using the in-box NDISUIO driver you should derive
your own NDIS protocol driver from the NDISUIO sample. Both your driver and the
in-box NDISUIO protocol driver can be bound to the same miniport without any
problems. By following this recommendation, you will insolate yourself from
changes to the in-box driver and will be immune to future changes.
These are the minimum steps:
-
Rename the NDISUIO target in SOURCES file.
-
Modify the NDIS protoName to something other then "ndisuio".
-
Modify the NT_DEVICE_NAME and DOS_DEVICE_NAME something other
then "Ndisuio".
-
Rebuild the driver using the DDK Build Utility.
(It is NOT sufficient to simply rename the NDISUIO.SYS file to another name...)
-
Modify the installer .INF file to match our driver's name.
-
Make corresponding changes in uiotest application.
There is no requirement for signing NDIS protocol drivers. There
is no WHQL test for NDIS protocol drivers. On installation, the system will not
complain about unsigned NDIS protocol drivers.
Fallback Solution
If you are not able or willing to develop and deploy your own
NDIS protocol driver, you can adapt your software to initially attempt to use
the NDISUIO Build 2600 IOCTL values. If they fail, then attempt to use the
NDISUIO SP1 IOCTL values.
Understand that this fallback approach does not protect you
against future changes to NDISUIO...
