Windows® Internals, Sixth Edition, Part 1

You can determine which version of the HAL you’re running by using WinDbg and opening a local kernel debugging session. Be sure you have the symbols loaded by entering .reload, and then typing lm vm hal. For example, the following output is from a system running the ACPI HAL:lkd> lm vm hal start end module name fffff800'0181b000 fffff800'01864000 hal (deferred) Loaded symbol image file: halmacpi.dll Image path: halmacpi.dll Image name: halmacpi.dll Timestamp: Mon Jul 13 21:27:36 2009 (4A5BDF08) CheckSum: 0004BD36 ImageSize: 00049000 File version: 6.1.7600.16385 Product version: 6.1.7600.16385 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: halmacpi.dll OriginalFilename: halmacpi.dll ProductVersion: 6.1.7600.16385 FileVersion: 6.1.7600.16385 (win7_rtm.090713-1255) FileDescription: Hardware Abstraction Layer DLL LegalCopyright: © Microsoft Corporation. All rights reserved.

EXPERIMENT: Viewing NTOSKRNL and HAL Image Dependencies

You can view the relationship of the kernel and HAL images by examining their export and import tables using the Dependency Walker tool (Depends.exe). To examine an image in the Dependency Walker, select Open from the File menu to open the desired image file.

Here is a sample of output you can see by viewing the dependencies of Ntoskrnl using this tool:

Notice that Ntoskrnl is linked against the HAL, which is in turn linked against Ntoskrnl. (They both use functions in each other.) Ntoskrnl is also linked to the following binaries:

Pshed.dll, the Platform-Specific Hardware Error Driver. PSHED provides an abstraction of the hardware error reporting facilities of the underlying platform by hiding the details of a platform’s error-handling mechanisms from the operating system and exposing a consistent interface to the Windows operating system.

On 32-bit systems only, Bootvid.dll, the Boot Video Driver. Bootvid provides support for the VGA commands required to display boot text and the boot logo during startup. On x64 systems, this library is built into the kernel to avoid conflicts with Kernel Patch Protection (KPP). (See Chapter 3 for more information on KPP and PatchGuard.)

Kdcom.dll, the Kernel Debugger Protocol (KD) Communications Library.

Ci.dll, the code integrity library. (See Chapter 3 for more information on code integrity.)

Clfs.sys, the common logging file system driver, used by, among other things, the Kernel Transaction Manager (KTM). (See Chapter 3 for more information on the KTM.)

For a detailed description of the information displayed by this tool, see the Dependency Walker help file (Depends.hlp).

Device Drivers

Although device drivers are explained in detail in Chapter 8 in Part 2, this section provides a brief overview of the types of drivers and explains how to list the drivers installed and loaded on your system.

Device drivers are loadable kernel-mode modules (typically ending in .sys) that interface between the I/O manager and the relevant hardware. They run in kernel mode in one of three contexts:

In the context of the user thread that initiated an I/O function

In the context of a kernel-mode system thread

As a result of an interrupt (and therefore not in the context of any particular process or thread—whichever process or thread was current when the interrupt occurred)

As stated in the preceding section, device drivers in Windows don’t manipulate hardware directly, but rather they call functions in the HAL to interface with the hardware. Drivers are typically written in C (sometimes C++) and therefore, with proper use of HAL routines, can be source-code portable across the CPU architectures supported by Windows and binary portable within an architecture family.

There are several types of device drivers:

Hardware device drivers manipulate hardware (using the HAL) to write output to or retrieve input from a physical device or network. There are many types of hardware device drivers, such as bus drivers, human interface drivers, mass storage drivers, and so on.

File system drivers are Windows drivers that accept file-oriented I/O requests and translate them into I/O requests bound for a particular device.

File system filter drivers, such as those that perform disk mirroring and encryption, intercept I/Os, and perform some added-value processing before passing the I/O to the next layer.

Network redirectors and servers are file system drivers that transmit file system I/O requests to a machine on the network and receive such requests, respectively.