NdisMRegisterDevice and Vista
If you have an NDIS driver that calls NdisMRegisterDevice(), be aware of how installing under a Vista UAC elevation affects your device object’s symlink.
As Ken discusses at length, objects created by users are created, by default, in a session-local namespace. So, consider the NdisMRegisterDevice() documentation:
SymbolicName
Pointer to an NDIS_STRING type containing a Unicode string that is the Win32-visible name of the device being registered. Typically, the SymbolicName has the following format: \\DosDevices\\SymbolicName.
If you follow this advice, your driver will create its symbolic link in whatever session happens to be current. During boot-up, the right thing will happen, but during initial installation of your driver, it will be created in the namespace of whoever is doing the installing. On downlevel operating systems, this was OK too, since the person who is most likely to be running the Win32 app to connect to the device is also the user who did the installing.
But under Vista, things are different. To do the installation, users are prompted to elevate, and the link creation ends up happening in the wrong place.
The solution is to follow the advice in the WDK topic Local and Global MS-DOS Device Names:
A driver that must create its MS-DOS device names in the global \DosDevices directory can do so by creating its symbolic links in a standard driver routine that is guaranteed to run in a system thread context, such as DriverEntry. Alternatively, the global \DosDevices directory is available as \DosDevices\Global; drivers can use a name of the \DosDevices\Global\DosDeviceName to specify a name in the global directory.
So, since binary-compatible drivers (9x) are a thing of the past, and since virtually every caller of NdisMRegisterDevice() will be in a user’s context during installation (until the first reboot), it’s safest to change to always using \\DosDevices\\Global\\<devicename>.
No Responses to “NdisMRegisterDevice and Vista”
No comments yet