Porting DriverEntry

In both WDM and framework-based drivers, the DriverEntry function is the primary entry point. The function prototype is the same in both models. In a WDM driver, the system calls DriverEntry when the driver is first loaded into memory. DriverEntry sets a pointer to the driver’s AddDevice routine in the DriverExtension->AddDevice field of the DRIVER_OBJECT structure, sets pointers to its I/O dispatch routines in the MajorFunction array of the DRIVER_OBJECT structure, and then returns. In a framework-based driver, the system calls the framework’s internal FxDriverEntry function upon loading the driver. This internal function initializes the framework and then calls the driver’s DriverEntry function. DriverEntry sets a pointer to the driver’s EvtDriverDeviceAdd callback and calls WdfDriverCreate to create the WDFDRIVER object, as the following example shows:


NTSTATUS
DriverEntry(
    IN PDRIVER_OBJECT  DriverObject
    IN PUNICODE_STRING RegistryPath
    )
{
    WDF_DRIVER_CONFIG_INIT( &config,
                              ToasterEvtDeviceAdd );
    status = WdfDriverCreate(
                 DriverObject
                 RegistryPath
                 WDF_NO_OBJECT_ATTRIBUTES
                 &config
                 WDF_NO_HANDLE
             );

    return STATUS_SUCCESS;
}


DriverEntry also initializes any global data or resources that the driver requires, such as creating a lookaside list or initializing tracing. Note that although WdfDriverCreate returns a handle to the WDFDRIVER object, the driver does not retain this handle, just as a WDM driver might not retain the DRIVER_OBJECT pointer that was passed to its DriverEntry routine. The reason is the same: only a few drivers use the pointer to the driver object.

 

 

Send comments about this topic to Microsoft

Show:
© 2014 Microsoft. All rights reserved.