NdisMRegisterDevice在哪里？

难道我的2000DDK有问题？我找不到它呀

如果没有就是未公开的函数！

NdisMRegisterDevice
NDIS_STATUS
  NdisMRegisterDevice(
    IN NDIS_HANDLE  NdisWrapperHandle,
    IN PNDIS_STRING  DeviceName,
    IN PNDIS_STRING  SymbolicName,
    IN PDRIVER_DISPATCH  MajorFunctions[],
    OUT PDEVICE_OBJECT  *pDeviceObject,
    OUT NDIS_HANDLE  *NdisDeviceHandle
    );
The NdisMRegisterDevice function creates a named device object and a symbolic link between the device object and a user-visible name for that device.

Parameters
NdisWrapperHandle
Specifies the handle returned by NdisMInitializeWrapper.
DeviceName
Points to a buffer containing a zero-terminated Unicode string that names the device object. The string must be a full-path name―for example, \Device\DeviceName.
SymbolicName
Points to a buffered Unicode string that is the Win32-visible name of the device being registered. Typically, the SymbolicName has the following format: \DosDevices\SymbolicName.
MajorFunctions
Points to an array of one or more entry points for the device driver's dispatch routines. A driver must set as many separate dispatch entry points as the IRP_MJ_XXX codes that the driver handles for the device object. Each dispatch routine is declared as follows:
NTSTATUS
(*PDRIVER_DISPATCH) (
    IN PDEVICE_OBJECT Device Object,
    IN PIRP Irp
);
 
A driver must not supply entry points for Plug and Play or Power Management handlers since the created device object is not for a physical device and therefore does not receive Plug and Play or Power Management IRPs.

pDeviceObject
Points to the newly created device object if the call succeeds.
NdisDeviceHandle
Points to a caller-supplied variable in which this function, if it succeeds, returns a handle to the device object. This handle is a required parameter to the NdisMDeregisterDevice function that the driver calls subsequently.
Return Values
NdisMRegisterDevice returns STATUS_SUCCESS if it succeeds, NDIS_STATUS_NOT_SUPPORTED if the caller is not an NDIS miniport, or a failure code if it fails.

Comments
An intermediate driver or miniport driver may require a separate, stand-alone device object. For example, an intermediate miniport might require a stand-alone device object to monitor the status of an underlying NIC when the NIC's miniport is not up and running. To obtain the NIC's status in such a case, a user-mode application or environmental subsystem sends an IRP to the device object. The IRP is processed by the intermediate driver. Without the stand-alone device object, the NIC's status is available only when the NIC's miniport is up and running.

An intermediate driver or miniport creates a device object by calling NdisMRegisterDevice from its DriverEntry function after DriverEntry has called NdisMInitializeWrapper. NdisMRegisterDevice creates a named device object and also a symbolic link between the device object name and a user-visible name for that device. If the call to NdisMRegisterDevice succeeds, the I/O Manager allocates storage in nonpaged pool for the device object itself and for all other data structures associated with the device object, including the driver's device extension. The device extension for an object created with NdisMRegisterDevice is reserved for use by NDIS and cannot be used by the driver.

A device object created with NdisMRegisterDevice functions in the same way as a device object and symbolic link that were created with IoCreateDevice and IoCreateSymbolicLink, respectively. IRPs sent to the device object are processed by the driver that created the device object―not by NDIS. The driver processes IRPs sent to the device object using dispatch routines that it registered when it supplied the MajorFunctions pointer to NdisMRegisterDevice. For more information on device objects, IRPs, and dispatch routines, see the Kernel-mode Driver Design Guide.

NDIS drivers should never call IoCreateDevice or IoCreateSymbolicLink. Instead, if an NDIS driver must create a device object, it should call NdisMRegisterDevice.

The device object that is created with NdisMRegisterDevice is not a physical device object and therefore does not receive Plug and Play or Power Management IRPs. Callers of NdisMRegisterDevice must therefore omit entry points for Plug and Play or Power Management handlers in the array that is pointed to by MajorFunctions.

If a driver's call to NdisMRegisterDevice fails, the driver can continue to load or not, depending on how critical the stand-alone device object is for the driver's operation.

Callers of NdisMRegisterDevice run at IRQL PASSIVE_LEVEL.

See Also
DriverEntry, IoCreateDevice, IoCreateSymbolicLink, NdisMDeregisterDevice, NdisMInitializeWrapper