2.1  Protocol DriverEntry and Initialization

A protocol driver’s initial required entry point must be explicitly named DriverEntry so that the loader can identify it. All other exported functions, described here as ProtocolXxx, can have any developer-specified name since they are passed as addresses to NDIS. The definition of DriverEntry is that of any Windows NT kernel-mode driver.

NTSTATUS
   DriverEntry(
       IN PDRIVER_OBJECT  DriverObject,
       IN PUNICODE_STRING RegistryPath
       );

If the protocol driver exports a set of standard kernel-mode driver routines, such as any (Tdi)DispatchXxx and Unload routines, in addition to the NDIS-defined ProtocolXxx functions, the protocol driver must set the entry points of its standard routines in the DriverObject passed to DriverEntry, like any other kernel-mode intermediate driver.

To set up communication with the NDIS library, a protocol's DriverEntry must register as a protocol driver by calling NdisRegisterProtocol, as described later.

DriverEntry also can initialize any spin locks the protocol requires, for example to protect state variables that track connections and sends in progress or driver-allocated queues.

If DriverEntry fails to allocate any resources the protocol needs to operate, it should release any previously allocated resources, including making a call to NdisDeregisterProtocol if necessary, and return an appropriate error status.

While a protocol driver can allocate all the resources it requires in DriverEntry, if the driver provides a ProtocolBindAdapter function as described in Section 2.3, it can defer opening and binding to an underlying NIC (or virtual NIC) driver, as well as reserving system resources to manage such a binding until the initial network I/O request occurs. Then, when ProtocolBindAdapter calls NdisOpenAdapter, it allocates resources as needed for the underlying NIC it opens.