1.1 Intermediate Driver DriverEntry Function

An intermediate driver’s initial required entry point must be explicitly named DriverEntry so that the loader can properly identify it. All other exported driver functions, described here as MiniportXxx and 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 driver exports a set of standard kernel-mode driver functions in addition to the ProtocolXxx functions, it must write the addresses of those standard functions in the driver object passed to DriverEntry.

In an intermediate driver, DriverEntry must at a minimum:

  1. Call NdisMInitializeWrapper and save the handle returned at NdisWrapperHandle.

  2. Call either NdisIMRegisterLayeredMiniport or NdisMRegisterMiniport to register the driver’s MiniportXxx functions, passing the handle obtained in Step 1.

  3. Call NdisRegisterProtocol to register the driver’s ProtocolXxx functions if the driver subsequently binds itself to an underlying NDIS driver.

DriverEntry can initialize spin locks for any globally shared resources the intermediate driver allocates, such as structures and memory areas the driver uses to track connections and to track sends in progress.

If DriverEntry fails to allocate any resources the driver needs to carry out network I/O operations, it should release any previously allocated resources and return an appropriate error status. For example, if DriverEntry has called NdisMInitializeWrapper, it must call NdisTerminateWrapper.

An intermediate driver’s DriverEntry function can perform some global initialization steps. However, if an intermediate driver provides a ProtocolBindAdapter function, which opens and binds to an underlying device as described in Section 1.2, such a driver can defer allocating binding-related system resources to ProtocolBindAdapter. ProtocolBindAdapter performs the bind and allocates resources as needed for the device passed at DeviceName. DriverEntry must always initialize the wrapper and register as a miniport driver. It also must register as a protocol driver if the intermediate driver also exports a set of ProtocolXxx functions.

If the intermediate driver only exports a set of MiniportXxx functions, it registers only those functions with the NDIS library, as described next.