Interpretation of Windows 2000 / XP hierarchy drive model
Webcrazy (http://webcrazy.yeah.net)
Scalability is one of the goals of Windows NT / 2000 / XP design, and its hierarchical drive model is the best embodiment of scalability. Implement two important design depends on the IO manager: 1. Any driver in Windows is designed as a Client / Server mode. For client-side drivers, obtain the server's IOCALLDRIVER requesting server through the IO Manager's IOCALLDRIVER. IOCALLDRIVER actually accepts client requests based on the client's call parameters (via IRP) calling the server's request. 2, IO Manager implements a layered data structure, saves a relationship in the Device_Object object, automatically request IRP to send the highest device in the device stack, determine how to handle, or handle itself, or Transfer down to achieve a hierarchical purpose. In view of this capability, the layered drive model can achieve many applications, such as document surveillance, encryption, antivirus, etc., which will be more extensive due to the introduction of PNP. In fact, this hierarchical model is everywhere in Windows NT / 2000 / XP. If you don't believe it, please do the following command:
FindSTR / M oattachdevice% systemroot% / system32 / drivers / *. sys
All listed Driver can almost see examples of layered drivers. Introduction to hierarchical drivers, almost all of all books describing Windows drivers. This article does not want to repeat this content, intended to illustrate this hierarchical implementation from the implementation of the underlying data structure. We first start from Device_Object. Below is part of this structure:
TYPEDEF STRUCT DECLSPEC_ALIGN (Memory_Allocation_alignment) _Device_Object {
.
.
.
Struct_driver_object * driverObject;
Struct _Device_object * nextdevice;
Struct _Device_object * attacheddeDevice;
.
.
.
PVOID DeviceExtension;
.
.
.
Cchar stacksize;
.
.
.
Struct _devobj_extension * DeviceObjectExtension;
.
.
.
DEVICE_OBJECT;
Members DriverObject are DRIVER_OBJECT corresponding to DeviceObject. Through this object, IO Manager can know how to provide services to this device (by calling DRIVEROBIECT). Usually a Driver_Object can provide a service, a different type of physical or logical device that provides a different type of DEVICE service. They may also play different roles, such as PDOs introduced for PNP and FDO, I will introduce them in detail below. Because this NextDevice member is used to link these Device_Object. So you can get this conclusion, as described in the previous sentence, the PDO and FDO exported to the same driver are logically established through the NextDevice member. For AttachedDevice members For Legacy's Driver (before Windows NT 4.0, you can use it normally in the later version), primarily through this field to implement the second function provided by the IO manager mentioned in this article. As shown below, AttacheDevice1 is attached to Device1. In this case AttachDevice1 and Device1 are usually not served by the same Driver, ie they do not link through the NextDevice member so that we can write another Driver by adding another Driver. A Device to an existing device change or monitor the behavior of this device. Of course, at this time, Device1 AttachedDevice members point to AttachDevice1. AttachedDevice1 is not attached to any device, so its AttachedDevice member points to NULL. By calling the IOCALLDRIVER requesting the DEVICE1 service, the IO Manager calls to the highest layer device attached to Device1. Here is AttachedDevice1, and for Device2, AttachedDevice3, if there is no device, it is deficed1. In this way, our attachment equipment has the opportunity to perform the corresponding operation. In addition, for the case of DEVICE1 and Device2, it is obvious that Device1 is above Device2, and at this time, the first case we started, Device1 requests Device2 through IOCALLDRIVER, logically established a relationship (we can't pass any data Structural identification This relationship is usually the logical relationship of driving developers, how to know this relationship on Windows 2000 / XP, of course, the best entry is the DDK documentation). | ------------- | ____ attachdevice1
| Device1 |
| ------------- |
------ AttachDevice3
| ------------- | ____ attachdevice2 --- |
| Device2 |
| ------------- |
DeviceExtension members typically drive developers self-defined structures, and their storage devices are related to, for example, for distinguishing PDO and FDO, and the like. Specify its size when calling IOCREATEDEVICE, IO Manager assigns a sporting memory of SIZEOF (Device_Object) DeviceExtensionSionSion, so that these two structures are physically continuous, so we often look in some file system drivers. The definition of Volume_Device_Object (Following the standard Device_Object is dedicated to the definition of Volume, avoiding this member at the DISPATCH entry).
StackSize refers to the number of devices of the current device stack (AttachedDevice, the device itself), specifies the number of STACK_LOCATION when IO Manager assigns IRP. All of the above descriptions constitute a Windows hierarchical drive model before Windows NT 4.0. This is also the main work idea of legacy of lentic derived drivers. AttachedDevice pointed out the Attached device, Microsoft introduced an Attachedto in the DeviceObjectExtension structure member in Windows 2000, which pointed out that the current device Attached low-level device, which is not implemented in Windows NT. DeviceObjectExtension is a very important structure. Here you need to introduce the WDM driver of PNP's WDM driver. She is a structure defined by the system (distinguishes DeviceExtension). For Driver_Object, there is a similar structure called DriveRextenion. The latter has a ClientDriveRextension structure, assigned by IOAllocatedRiveRObjectExtension, IOGETDRIVEROBJECTEXTENSION. Classpnp.sys is the management of Disk.sys, Tape.sys and CDROM.SYS by this method; NDis.sys also implements the management of each miniPort / IM / Protocol Driver through this way.
Windows 2000 and the NT series have introduced WDM, support PNP, Power Management, and WMI, in order to allow the operating system itself support, NTOSKRNL.EXE exports several DRVO_BUILTIN_DRIVER (Defined in NTDDK.H) flags. Driver, which is PNPManager, WMIXWDM, and ACPI_HAL, the latter is supported by ACPI (this is in my Windows XP Professional desktop, I don't know if I don't support ACPI, I don't support ACPI, my machine is also deported on Ntoskrnl.exe FileSystem / Raw driver for file system support, I think these devices may differ from machine configuration and Windows version, in fact I am in my Windows 2000 Server SP0 notebook Ntoskrnl.exe generates the following four devices: PNPManager, PCI_HAL, WDM and RAW, the narrative under our basics is on the desktop, as for some different different I may point out, or there may be no), the first two Driver are introduced to support WDM. WMIXWDM exports WMIDATEVICE for WMI support, which is not related to the discussion of layered drivers in this article. Here, I will focus on PNPManager.
Before introducing, let's take a look at the DEVMGMT.MSC "Sort by Connection Device" view:
TSU00 (machine name, virtual root bus enumeration implemented by PNPManager)
|
| Advanced Configuration And Power Interface (ACPI) PC (ACPI_HAL driver implementation in NtoskRNL)
|
| MicrSoft ACPI-Compliant System (Enumerated by ACPI.SYS)
|
| PCI BUS (implemented by pci.sys)
|
| (Connected device)
This is the situation on my machine, PNPManager is a bus driver (implemented in Ntoskrnl.exe, if you have Checked Build's ntoskrnl.exe, you can easily discover it from Base / NTOS / IO / PNPMGR / PNPDD. c Implementation, have you seen the Windows XP Source Tree of SysInternals?), she implements a virtual bus called root. All Legacy devices are connected to this virtual bus. If you don't believe it, you continue to select "Show hidden devices to see" on the sketch listed in DEVMGMT.MSC. From this sense, she wants to build a PDO for each device connected to her. For these PDOs, it is usually namdured at 00000001. For example, in my machine, I have an experiment, and the device name has been 00000050, a total of 80 PDOs (not so naming on my Windows 2000 Server machine, Although it is also based on hexadecimal, it starts from a quite a value). I really like the OSR's DeviceTree with Windows XP DDK, but in order to better understand, still work with Windbg: Find the PDO implemented by PNPManager attached by the sketch ACPI_HAL, usually this is the PNPManager implementation A PDO, named 00000001 (if your PNPManager generated device is not so naming, please use! Drvobj PnpManager to find the generated corresponding PDO, my Windows 2000 Server SP0 notebook, PNPManager's first PDO Used to serve the ESS sound card, not my original PCI_HAL, you may need to use! DevStack or the following! Devnoe command, method is not detailed):
KD>! Object / device / 00000001
Object: 812b4410 TYPE: (812B4048) Device
ObjectHeader: 812B43F8
Handlecount: 0 Pointercount: 5
Directory Object: E10011B0 Name: 00000001
KD>! DevoBJ 812B4410
Device Object (812B4410) is for:
00000001 / Driver / PNPManager DriverObject 812B4980
Current IRP 00000000 REFCOUNT 0 TYPE 00000004 Flags 00001040
DACL E1518A6C DEVEXT 812B44C8 DevObjext 812B44D0 DevNode 812B42B8
ExtensionFlags (0000000000)
AttachedDevice (Upper) 812F6BB0 / Driver / ACPI_HAL
Device queue is not busy.
We can easily discovery through the output of AttachedDevice above to the device 00000001 is ACPI_HAL, which is consistent with our devmgmt.msc. In fact, Attached to this PDO is a device called FDO by ACPI_HAL. PDO and FDO itself are still represented by Device_Object, as previously referred to, for bus drive developers typically use a flag of DeviceExtens to distinguish between the same Driver service is PDO or FDO. FDO is usually established by Driver's AddDevice portal, and after the establishment, use oattachdeventodeventack to attach to the lower-level bus driver, which is as seen in Windbg above. This Attached operation is the same as the Legacy device we discussed out, and it is also an ATTACHEDDEVICE member using Device_Object. What you might be inappropriate PNPManager's AddDevice portal should be implemented. We know that PNPManager is implemented as root bus driver. Since it is root, there is no PDO provided on Attached. In fact, you can use Windbg to see its implementation: In Free Build XP, it only implements Return Status_Success (xor Eax, Eax / Ret). When I was using Checked Build, I just checked IRQL: RTLASSERT (KegetCurrentiRQL () <= APC_LEVEL).
Of course, for the ACPI_HAL or PCI bus, its addDevice is definitely different from PNPManager, and they must ocreateDevice to access the PDO provided by FDO, Attached to PNPManager or the PDO provided by the upper bus, implement hierarchical relationships. We continue to use Windbg to verify my ideas:
KD>! Drvobj / Driver / ACPI_HAL
Driver Object (812f6ce8) is for:
/ Driver / ACPI_HAL
Driver Extension List: (ID, AddR)
Device Object List:
812F6A90 812F6BB0
Which device exported by ACPI_HAL is PDO, which is FDO (you should understand at least one FDO). We know that the PNP Manager will first call the bus driver's AddDevice entry, and then send a variety of MinorFunction director of various IRP_MJ_PNP to the bus driver enumeration bus, which is established for each device connected to the above. PDO, etc. I only describe usually, for the virtual bus such as TOASTER that came in DDK, the device on which the device on the enumeration bus is to indicate the PDO's establishment (by IOINVALIDATEVICERELATIONS to make PNP Manager IRP_MJ_PNP). Of course, the virtual bus in TOASTER is implemented, and the AddDevice entrance, that is, FDO is always the establishment of PDO. Because the device for the same Driver_Object service, it is a one-way lin list through the DeviceObject of DRIVER_OBJECT. This DeviceObject indicates the chain header, and is connected by the device_Object's NextDevice. For IOCREATEDEVICE, it is always inserted into the header, while FDO is always the first to be established, so it is always tailing. With these analysis, the output 812f6bb0 above the ACPI_HAL is FDO, and 812F6A90 is a PDO. OK, so this PDO is another sub-PDO for the bus driver implemented by the upper ACPI.sys. KD>! DevoBJ 812F6A90
Device Object (812f6a90) is for:
00000052 / Driver / ACPI_HAL DriverObject 812f6CE8
Current IRP 00000000 REFCOUNT 0 TYPE 0000002A Flags 00001040
DACL E1518A6C DEVEXT 812F6B48 DEVOBJEXT 812F6B60 DevNode 812F63A8
ExtensionFlags (0000000000)
AttachedDevice (Upper) 812AD960 / Driver / ACPI
Device queue is not busy.
You look at the upper layer is not / Driver / ACPI (AttachedDevice). The PCI bus is also attached to the MicrSoft ACPI-Compliant System implemented by Attached to Acpi.sys. Note that ACPI is not like ACPI_HAL, only one PDO, and the PCI bus is not the first PDO. With these knowledge, I think you should be more likely to find which PDO attached to the PCI bus. A simpler way is to use the fdo of the DUMP PCI bus of the DEVSTACK.
KD>! Drvobj PCI
Driver Object (812ef850) is for:
/ Driver / PCI
Driver Extension List: (ID, AddR)
Device Object List:
812F39E8 812F3D58 812F4E40 812F4038
812F0710 812F0908 812F0C58 812F14E8
812f0e38
KD>! Devstack 812f0e38
DEVOBJ! Drvobj! Devext Objectname
> 812f0e38 / driver / pci 812f0ef0
812DC8C0 / Driver / ACPI 812F5660 00000058
DEVNODE 812F1008:
DeviceInst Is "ACPI / PNP0A03 / 2 & Daba3FF & 0" ServiceName IS "PCI"
The devstack command actually uses the AttachedTo of Device_Object AttachedDevice with the DeviceObjectExtension (Note here is the DeviceObjectExtension instead of the DeviceExtension). Of course, the devstack command also displays Device_Node corresponding to the device. Device_node is a system data structure introduced to support PNP. The complete device_node definition is very complicated and very large, I will not listed, several important members such as Sibling (Brothers Device_Node), Child (child device_node), PARENT (Parent Device_Node), device status PNP_DEVNODE_STATE, resource usage cm_resource_list, interface type interface_type, device identification, service name serviceName, etc.
From my prompts, DeviceNode contains Sibling, Child, Parent, etc., we can easily think that the system may make all DeviceNode into a tree (similar to the directory tree of the file system), actually is this, the kernel variable IOPROOTDEVICENODE indicates this The root of the tree. The devnode command can see the situation of this root node, if you use it! DevNode 0 1 command, you will live a WINDBG DEVMGMT.MSC version. In fact, the system's setupdi (setupapi.dll exported for device installation API) is the device that is from DUMP. DEVMGMT.MSC indirectly uses these APIs (you can be as surprised as I. MSC file is just an XML file parsed by mmc.exe). These APIs have also been used by DeventRee in the same OSR.
So far you may be more troublesome, why is the PDO, how do you know which bus attached to, to form an apparatus level. The secret is that the registry, the device is installed, and the sequence of content indicating the content indication system is added to the registry. The earlier. INF file is really complicated, in my opinion, is never as perl script. Windows 2000 has automatically made too much for you (I really want to know what to do, 嘻嘻).
In the registry, HKLM / System / CurrentControlSet / Enum collaborates with HKLM / System / CurrentControlSet / Control / Class to complete such tasks, of course, is inseparable from HKLM / System / CurrentControlSet / Services as the Legacy driver. For the complete way of introducing the Windows 2000 / XP hierarchical drive model, it is necessary to finally refer to the Filter driver, which is a type of driver attached to the bus driver or other driver, for enhancement, change the original Some of the features of the device. Enums in the just mentioned registry and the Upperfilters of the Class item are provided with the value of LowerFilters.
Finally, a few concepts are distinguished by this hierarchical drive from Windows 2000 / XP, such as intermediate layer drivers, so, such as WINDOWS 2000 / XP, which can be seen everywhere. The class driver implements a common function of a class of devices, which does not involve actual hardware access. Such as disk-driven drivers, there are disk.sys, tape.sys, cdrom.sys, and use of classpnp.sys, as examples, with disk.sys as an example, and she is an IDE interface with disk.sys. Or the SCSI interface, the miniport / port drive implementation interact with the specific hardware by the underlying Atapi.sys or SCSIPORT.SYS. In addition, it will be mentioned, it can be said that FileSystem Filter is a layered drive of Legacy (only using Device_Object AttachedDevice member. And for network drivers, such as NDIS Intermediate Drivers and NDIS MUX Intermediate Drivers and NDIS MUX Intermediate Drivers) It is a hierarchically driven application, but there are too many information hidden by Ndis Wrapper Library (Ndis.sys) in Windows 2000 / XP (hidden the true face of IRP), or you can use ndis.sys using it. The internal self-structure definition, such as NDIS_M_DRIVER_BLOCK, NDIS_MINIPORT_BLOCK, NDIS_PROTOCOL_BLOCK, NDIS_PITOCOL_BLOCK, NDIS_PIS_PIS_BLOCK these definitions between these definitions, and it has implemented a hierarchical structure.
Basically, I've been probably, I don't know if it is clear. Looking forward to your feedback guidance exchange (TSU00@263.net).
