Driver load order questions

NTDEV
1

Hi,

I have a couple of questions regarding driver load order for drivers with
start type SERVICE_BOOT_START.

  1. In Windows 8 the ACPI driver is in group ‘Core’. But this group is not
    included in ServiceGroupOrder key. So when are drivers in this ‘Core’ group
    loaded and started?

  2. Assume both device A and B are enumerated by ACPI. And both A’s and B’s
    drivers have start type SERVICE_BOOT_START. A’s driver is in ‘system bus
    extender’ group, and B’s driver is in ‘SCSI miniport’ group. Therefore, OS
    calls ACPI’s DriverEntry first, then A’s DriverEntry, and at last B’s
    DriverEntry. My questions are
    a. When does OS call ACPI’s StartDevice? After all boot-start drivers’
    DriverEntries are called and returned?
    b. Is A’s StartDevice guaranteed to be called before B’s StartDevice? If
    not, is it possible to properly build ACPI DSDT/SSDT table to enforce that
    order?

Thanks,
Min

2

My understand is that that is precisely what the _DEP entry in the DSDT is used for.

Note: I am *not* an ACPI expert…

Peter
OSR

3

> Hi,

I have a couple of questions regarding driver load order for drivers with
start type SERVICE_BOOT_START.

  1. In Windows 8 the ACPI driver is in group ‘Core’. But this group is not
    included in ServiceGroupOrder key. So when are drivers in this ‘Core’
    group
    loaded and started?

I suspect, and this is a guess, that until the “core” drivers are loaded
the Registry is not accessible, so putting a key into it would not be
particularly meaningful.

  1. Assume both device A and B are enumerated by ACPI. And both A’s and B’s
    drivers have start type SERVICE_BOOT_START. A’s driver is in ‘system bus
    extender’ group, and B’s driver is in ‘SCSI miniport’ group. Therefore, OS
    calls ACPI’s DriverEntry first, then A’s DriverEntry, and at last B’s
    DriverEntry. My questions are
    a. When does OS call ACPI’s StartDevice? After all boot-start drivers’
    DriverEntries are called and returned?
    b. Is A’s StartDevice guaranteed to be called before B’s StartDevice?
    If
    not, is it possible to properly build ACPI DSDT/SSDT table to enforce that
    order?

Thanks,
Min

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

> the Registry is not accessible

Registry is always accessible, read-only at least.

Each DriverEntry gets a registry key name, and each driver is allowed to touch it in DriverEntry.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

5

I am recalling something about the various boot phases, there were
something like seven of them, and the Registry did not become visible
until stage 4 or 5. There are also some limits on what keys you can use;
some of the hardware config values are accessible via Registry service
calls from the driver, but IIRC, only certain limited Registry access was
permitted because all of that “Registry” is sort-of cached in RAM. At one
point, I think only HKLM\Hardware values can be accessed because those
keys are computed at boot time. Again, this is going back a few years,
but until certain disk drivers are located, the Registry “hive” files are
inaccesible. So just because Registry calls can be made does not mean
that all the Registry keys “Exist” or are implemented as hive contents.
Again, IIRC, the interface is the abstraction, not a promise that values
are implemented with the same access mechanism at all points duringthe
boot cycle. So saying the DDI calls have defined behavior with respect to
the abstraction is not the same as saying “the Registry is always
accessible.”

> the Registry is not accessible

Registry is always accessible, read-only at least.

Each DriverEntry gets a registry key name, and each driver is allowed to
touch it in DriverEntry.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

6

>Registry is always accessible, read-only at least. Each DriverEntry gets a registry key name,

and each driver is allowed to touch it in DriverEntry.

???

Some parts of it are unavailable for drivers with start type 0 and 1 in their DriverEntry() routines. In order to realize why, try to think what happens if driver that is supposed to read registry data from the disk is not yet initialized. This is why bootloader loads some parts of the registry into RAM before kernel’s entry point gets invoked. However, this is just a relatively small subset of the registry - most of it is not yet available…

Anton Bassov

7

Three phases of boot: 0, 1, 2

d

debt from my phone

From: xxxxx@flounder.com
Sent: 11/12/2012 2:24 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Driver load order questions

I am recalling something about the various boot phases, there were
something like seven of them, and the Registry did not become visible
until stage 4 or 5. There are also some limits on what keys you can use;
some of the hardware config values are accessible via Registry service
calls from the driver, but IIRC, only certain limited Registry access was
permitted because all of that “Registry” is sort-of cached in RAM. At one
point, I think only HKLM\Hardware values can be accessed because those
keys are computed at boot time. Again, this is going back a few years,
but until certain disk drivers are located, the Registry “hive” files are
inaccesible. So just because Registry calls can be made does not mean
that all the Registry keys “Exist” or are implemented as hive contents.
Again, IIRC, the interface is the abstraction, not a promise that values
are implemented with the same access mechanism at all points duringthe
boot cycle. So saying the DDI calls have defined behavior with respect to
the abstraction is not the same as saying “the Registry is always
accessible.”

> the Registry is not accessible

Registry is always accessible, read-only at least.

Each DriverEntry gets a registry key name, and each driver is allowed to
touch it in DriverEntry.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

8

> Some parts of it are unavailable for drivers

I mean SYSTEM hive, surely.

Drivers must never ever touch other hives.

This is why bootloader loads some parts of the registry into RAM before kernel’s entry point gets
invoked. However, this is just a relatively small subset of the registry - most of it is not yet available…

Whole SYSTEM hive IIRC.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

9

_DEP, precisely, means that the _PSx methods or power resources pointed to by _PRx objects of a device depends on the driver for the device that is indicated. As an example, if your device’s power controls are on an I2C bus, you can’t turn it on unless the driver for that I2C bus is running.

As a side effect of enforcing this, you will notice that we don’t even enumerate device nodes to the PnP manager until their dependencies are resolved (in Windows 8.) This doesn’t say anything about driver load order but it does imply something about device start order. This side effect is (mostly incidental) and I suspect it may change in the future.

  • Jake Oshins
    Windows Kernel Team

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Saturday, November 10, 2012 8:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver load order questions

My understand is that that is precisely what the _DEP entry in the DSDT is used for.

Note: I am *not* an ACPI expert…

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

10

Hi Min -

It’s my understanding that drivers are loaded in legacy fashion first, before the PnP portion is invoked. The legacy portion (my own wording here) involves loading the driver from disk and calling DriverEntry. The order here is controlled by Start type, Group and order within the group. Load order within the group is controlled by a registry key, and your driver can be put at the front of that list by using a flag in the AddService directive of your inf file. I found that there is a bug in server 2k12 (and likely windows 8) for this functionality as outlined in the link below, but was unable to figure out how to report this problem to microsoft:
http://www.osronline.com/showThread.cfm?link=233744

11

Again, acknowledging that I am not an ASL expert, or even journeyman really… and that Jake IS an ASL expert… I don’t wish to argue with the expert, but I don’t understand Jake’s reply.

Here’s the OP’s question:


Is A’s StartDevice guaranteed to be called before B’s StartDevice? If
not, is it possible to properly build ACPI DSDT/SSDT table to enforce that
order?

Are you saying that the ASL _DEP statement won’t do exactly what he’s asking?


This doesn’t say anything about driver load order but it does imply
something about device start order. This side effect is (mostly incidental) and
I suspect it may change in the future.

I don’t understand: WHICH side effect? Which driver is *loaded* first? I’m not sure that’s important in answering the OP’s question.

If DevA depends on DevB for power resources, the system can’t start DevA until DevB has been started… can it? IRP_MN_START_DEVICE signals an implicit transition to D0. So, the system can’t send the IRP_MN_START_DEVICE to DevA until he’s done so to DevB, right??

What am I missing?

Peter
OSR

12

>Is A’s StartDevice guaranteed to be called before B’s StartDevice?

If B is a child device of A, yes, and this won’t depend on their start order. Otherwise, there is no guarantee. It all depends who enumerates whom.

13

I’m saying that the contract on _DEP doesn’t say anything about when a driver is loaded, or even when a device is enumerated. The implementation in Windows 8 delays enumerating the dependent device until the depended-upon device is started. Some implementation like that is probably necessary for satisfying the actual contract on _DEP. But future versions of Windows may satisfy that contract differently, with driver-visible implications.

What this all boils down to is this: Using firmware to drive OS behavior is a bad idea, both because it’s not generally a low-precision strategy and because it’s fragile. You tend to be looking for side effects of the intended firmware interfaces, and side effects change.

In order to get a few platforms out the door in Windows 8, some people within Microsoft recommended the use of _DEP to those platform vendors. That may have been pragmatic on a short-term basis, for platforms where the firmware and the driver packages are very, very tightly tied. I think that recommending the strategy in general is asking for trouble.

  • Jake Oshins
    Windows Kernel Team
    (sometime ACPI guy)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 27, 2012 6:53 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver load order questions

Again, acknowledging that I am not an ASL expert, or even journeyman really… and that Jake IS an ASL expert… I don’t wish to argue with the expert, but I don’t understand Jake’s reply.

Here’s the OP’s question:


Is A’s StartDevice guaranteed to be called before B’s StartDevice? If
not, is it possible to properly build ACPI DSDT/SSDT table to enforce that
order?

Are you saying that the ASL _DEP statement won’t do exactly what he’s asking?


This doesn’t say anything about driver load order but it does imply
something about device start order. This side effect is (mostly incidental) and
I suspect it may change in the future.

I don’t understand: WHICH side effect? Which driver is *loaded* first? I’m not sure that’s important in answering the OP’s question.

If DevA depends on DevB for power resources, the system can’t start DevA until DevB has been started… can it? IRP_MN_START_DEVICE signals an implicit transition to D0. So, the system can’t send the IRP_MN_START_DEVICE to DevA until he’s done so to DevB, right??

What am I missing?

Peter
OSR

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

14

I *think* I understand the point you’re trying to make.

You’re saying _DEP specifies a dependency relationship, nothing more. What the OS does to implement that dependency relationship is entirely up to the OS, and can change. In addition, you’re saying if one wants something to happen in the OS, they should use the OS mechanisms that are specified by contract to make that happen, rather than relying on an implementation detail (of how the OS deals with a requirement expressed by ACPI).

Did I get that right? Assuming so, good architectural point. Thanks for that. I definitely appreciate it.

Soooo… the answer to the OP’s specific question “is it possible to properly build ACPI DSDT/SSDT table to enforce that order?” is “While _DEP will do what you’re asking, it is not advisable to enforce this ordering using APCI. Rather, the right way to accomplish your goal is to use the OS specified mechanisms to enforce your inter-driver dependencies.”

I think I’ve got it. Er, rather, I HOPE I’ve got it…

Peter
OSR