DriverEntry

NTDEV
1

Hi,

We are developing an export driver on Windows 2000. We have a Miniport
driver which depends on and uses some of the functions exported by the
export driver. When the system is booted with both the drivers, the
DriverEntry routine of the Miniport driver gets executed. But the
DriverEntry of the export driver is not getting called.
If the system is booted with only the export driver, then it’s DriverEntry
gets called. Can anybody throw some light on this ? Is this the expected
behavior ?

Thanks & Regards

Manish

2

>

We are developing an export driver on Windows 2000. We have a Miniport
driver which depends on and uses some of the functions exported by the
export driver. When the system is booted with both the drivers, the
DriverEntry routine of the Miniport driver gets executed. But the
DriverEntry of the export driver is not getting called.
If the system is booted with only the export driver, then it’s DriverEntry
gets called. Can anybody throw some light on this ? Is this the expected
behavior ?

Sure. This is the expected behavior, but not necessarily the obvious
behavior. An export driver is a kernel dll. If your client driver (your
miniport driver) loads before the export driver, the kernel loader will load
the export driver in order to resolve the dll function calls in your client
driver. Unfortunately, the kernel loader will not call the export driver’s
DriverEntry routine, as that is done by the IoManger not by the kernel
loader. Note also that as your export driver is now loaded, it will not be
considered further as a candidate for loading by the IoManager. In this case
DriverEntry never gets called. You either have to write your export driver
such that it will initialize itself as required without relying on
DriverEntry, or you have to guarantee the load order of your export driver
with respect to your client driver.

The general solution is to have some sort of registration function that your
clients must call before they use the export driver api. The registration
function would then test the initialization state and do whatever is
required. Of course there is the problem that you will not have the
DriverEntry supplied registry path, but that can also be fixed up, although
perhaps not in an optimal fashion. One solution is to use the client’s
registry path for fetching registry-based configuration information.

Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
www.hollistech.com

3

> DriverEntry routine of the Miniport driver gets executed. But the

DriverEntry of the export driver is not getting called.

If the export driver is not registered in the registry’s service database -
then it is considered to be the kernel mode DLL, not the driver.
The difference is:

  • kernel mode DLL does not have a driver object
  • kernel mode DLL’s DriverEntry is NEVER called.
  • kernel mode DLL can be loaded only by a) import resolution in other driver
    or b) by undocumented ZwSetSystemInformation.
  • kernel mode DLL can be unloaded ONLY by ZwSetSystemInformation. They are
    never unloaded using the ordinary operation of the kernel.

SCSIPORT on NT4 is a kernel-mode DLL.

Max