Order of Driver Loading

发布时间：2013-8-18 20:32
分类名称：Driver

From: < Programming the Microsoft Windows Driver Model 2nd>

I said earlier that devices can have upper and lower filter drivers as well as a function driver. Two registry keys associated with the device contain information about filter drivers. The device key, which contains information about an instance of your hardware, can have UpperFilters and LowerFilters values that specify filter drivers for that instance. There is another registry key for the class to which the device belongs. For example, a mouse belongs to the Mouse class, which you could probably have figured out without me telling you. The class key can also contain UpperFilters and LowerFilters values. They specify filter drivers that the system will load for every device belonging to the class.

Figure 2-6. Layering of recursively enumerated devices.

No matter where it appears, an UpperFilters or LowerFilters value is of type REG_MULTI_SZ and can therefore contain one or more null-terminated Unicode string values.

NOTE
Windows 98/Me doesn't support the REG_MULTI_SZ registry type and doesn't fully support Unicode. In Windows 98/Me, the UpperFilters and LowerFilters values are REG_BINARY values that contain multiple null-terminated ANSI strings followed by an extra null terminator.

It may be important in some situations to understand in what order the system calls drivers. The actual process of "loading" a driver entails mapping its code image into virtual memory, and the order in which that's done is actually not very interesting. You might be interested, however, in knowing the order of calls to the AddDevice functions in the various drivers. (Refer to Figure 2-7.)

Figure 2-7. Order of AddDevice calls.

1. The system first calls the AddDevice functions in any lower filter drivers specified in the device key for the device, in the order in which they appear in the LowerFilters value.
2. Then the system calls AddDevice in any lower filter drivers specified in the class key. Again, the calls occur in the order in which the drivers appear in the LowerFilters string.
3. The system calls AddDevice in the driver specified by the Service value in the device key. This is the function driver.
4. The system calls AddDevice for any upper filter drivers specified in the device key, in the order in which they appear in the UpperFilters data string.
5. Finally the system calls AddDevice for any upper filter drivers specified in the class key, in the order in which they appear in the UpperFilters data string.

As I explain later in this chapter, each AddDevice function creates a kernel DEVICE_OBJECT and links it into the stack rooted in the PDO. Therefore, the order of calls to AddDevice governs the order of device objects in the stack and, ultimately, the order in which drivers see IRPs.

NOTE
You might have noticed that the loading of upper and lower filters belonging to the class and to the device instance isn't neatly nested as you might have expected. Before I knew the facts, I guessed that device-level filters would be closer to the function driver than class-level filters.