Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Overview of Windows Server 2003 Plug and Play

Windows Server 2003 uses the same plug-and-play support introduced in Windows 2000. The Windows Executive has two components that handle PnP services: Plug and Play Manager and Power Manager:

• Plug and Play Manager.
  Discovers PnP devices using a process called

  enumeration . It then loads an appropriate driver and makes Registry entries based on INF scripts written either by Microsoft or the hardware vendor. Plug and Play Manager also allocates resources such as IRQs, I/O ports, and DMA channels based on information gleaned from ACPI.




• Power Manager.
  Handles dynamic interaction with devices to conserve battery life or limit wear and tear on components. Power Manager can be set to spin down a hard drive, for example, after a certain interval of inactivity.

The trick to getting a successful PnP enumeration is having an INF script that calls out the same name as that reported by the device. If PnP Manager cannot match an INF script to the device, it cannot complete the transaction even if the correct driver is available on the machine. Drivers are stored in \Windows\System32\Drivers. INF scripts are stored in \Windows\Inf.

32-bit drivers cannot be loaded on an IA64 machine. The WOW64 emulator only works in user space, not kernel space. However, the same INF script can be used to load both 32-bit and 64-bit drivers. This enables a vendor to deploy a single script and two sets of drivers. If the vendor wants to load only a 64-bit driver, the .inf extension can be changed to .ia64. This signals the operating system to look only for 64-bit drivers.

Using Device Manager

Before proceeding much further, let's take a look at the MMC console provided by Microsoft for viewing details about the devices loaded on a machine. This is the Device Manager, Devmgmt.msc. In general, if you have hardware problems or want to configure a device, the first place to go is the Device Manager console. There are several ways to open the console:

• Right-click the My Computer icon on the desktop and select M

  ANAGE from the flyout menu. Expand the tree under System Tools | Device Manager.




• Right-click the My Computer icon, select P

  ROPERTIES from the flyout menu, select the Hardware tab, then click Device Manager.




• My personal favorite is the Run window. I just enter devmgmt.msc and press Enter.

Figure 3.12 shows an example of the device tree displayed by the Device Manager console.

To see the configuration information for a particular device, right-click the Device icon and select P

ROPERTIES from the flyout menu. If Device Manager does not list a device that you know is installed in the system, the device might be misconfigured or a legacy device might not be recognized by the PnP Manager. Legacy devices can be installed manually using the Install New Hardware applet in Control Panel.

An exclamation point or question mark next to a device indicates a problem of some sort, usually a resource conflict. A big red X indicates that the problem was severe enough to force disabling of the device.

To assess the problem, open the Properties window for the device then select the Device Status tab to find the nature of the problem. If the properties indicate a resource conflict, use the Resource view to see what other devices are contending for the same resource.

To clear a conflict, try deleting the device then restarting. This may force PnP Manager to reconsider the resource allocation decision it made the first time. You can also try moving the card to another PCI slot, which forces ACPI to assign different resources.

If a resource conflict persists for a legacy device, try taking manual control of the resource allocation for the device by selecting the Resources tab and unchecking the Use Automatic Settings option. This option will be dimmed for PCI devices. After you manually allocate resources to a legacy device, restart the machine to see if the error persists or if you caused a problem for another device.

Advanced Configuration and Power Interface (ACPI)

Although Microsoft calls Windows Server 2003, XP, and Windows 2000 "Plug-and-Play" operating systems, they are actually ACPI operating systems. The Advanced Configuration and Power Interface standard defines mechanisms by which devices report their capabilities and resource needs to ACPI, where they are dutifully listed in a set of tables in the volatile memory section of the chip. The operating system reads these tables and makes resource allocation and power management decisions based on the information it finds there.

According to the ACPI 2.0 specification, available at www.acpi.info, the following services are provided by the ACPI infrastructure:

• System power management




• Device power management




• Processor power management




• Device and processor performance management




• Plug and Play




• System Events




• Battery management




• Thermal management




• Embedded Controller management




• SMBus Controller management (SMBus is the System Management bus specification promulgated by Intel.)

The ACPI infrastructure on a machine is an intimate part of the machine's operation, so Microsoft chose to incorporate ACPI support directly into the operating system kernel via the Hardware Abstraction Layer (HAL).

As you can see from the list, Windows Server 2003 and XP use ACPI to handle power management as well as plug and play. Don't confuse these power management features with the legacy Advanced Power Management (APM) services that were part of the PC specifications for many years. APM uses function calls in the system BIOS to control the machine's wake-state. Legacy APM function calls are supported only in XP, not in Windows Server 2003 servers.

You can check to see if APM is enabled by clicking the Power Options hyperlink in the new Printers and Other Hardware section of the new Control Panel interface. If the Power Options window has an APM tab, the machine has an APM BIOS. You should only enable APM support if the machine has no other power management options available, indicating that no ACPI functionality has been enabled in the HAL.

[View full width]
C:\Program Files\Resource Kit>apmstat -v
This computer appears to have an APM legal HAL
This machine has an APM bios present that looks OK, and it is
not on the list of machines known to have APM problems.
Check the power applet in the control panel to see if APM is 
enabled
APM Registry Data Dump
Major = 0001  Minor = 0002
InstallFlags = 0003
Code16Segment = f000  Code16Offset = 56c4  DataSeg = 0040
Signature = APM
Valid = 0001
Detection Log Data:
44 45 54 4c 4f 47 31 00 00 00 00 00 00 00 00 00
D  E  T   L  O  G  1

This is an ACPI machine. APM is NOT relevant on this machine.

ACPI Compatibility

You should have relatively few problems installing Windows Server 2003 on a new machine that meets the ACPI v2 specification. Older machines built during the time that the ACPI spec was evolving sometimes have problems, ranging from the failure of certain power management features to erratic behavior to periodic freezes and bugchecks.

Microsoft drew a line at 1/1/99 and assumes that any machine built after that date is ACPI 2.0-compliant. Machines that are known exceptions to this rule are listed in the Txtsetup.sif file on the Windows Server 2003 CD under the heading [NWACL], which stands for

Non-Windows ACPI Compliance List .

Setup determines the ACPI identification of a machine by querying two ACPI tables: the

Fixed ACPI Description Table (FACP), which contains a string representing the vendor, and the

Root System Description Table (RSDT), which contains an alphanumeric value assigned by the vendor to represent the machine's make and model. The [NWACL] entry identifies the source of the identification. For example, the Toshiba Portege 3300 and the Fujitsu Sprint are on the NWACL list. Here are the particulars from the [NWACL] section of the Txtsetup.sif file:

[ToshibaPortege3300]
AcpiOemId="FACP","TOSHIB"
AcpiOemTableId="FACP","750     "
AcpiOemRevision="<=","FACP",1
[FujitsuSPRINT]
AcpiOemId="RSDT","FUJ   "
AcpiOemTableId="RSDT","SPRINT  "

The Txtsetup.sif file also lists machines built prior to 1/1/99 that are known to be ACPI-compliant. These machines are listed under the [GoodACPIBios] heading.

There is also a "good but only with some fixes" list included in a file called Biosinfo.inf, also in the \I386 directory on the Windows Server 2003 CD. This list identifies machines that work only if certain ACPI features are disabled. Here is an example listing:

; Workaround for BIOS bug in Dell Dimension 8100, Precision 220,
;and Precision 420 using National PC87364 SuperIO chipsets.
;Parallel port is configured in a way that does not
; work on Win2k or WinXP
[DellNationalPC87364WorkAround]
AddReg=DellNationalPC87364WorkAroundAddReg
[DellNationalPC87364WorkAroundAddReg]
HKLM,SYSTEM\CurrentControlSet\Services\Parport\Parameters,DellNationalPC87364,0x00010001,1

If you have a machine with a motherboard older than 1/1/99 that is not listed on the good-boy list but you think it would be perfectly fine running with the ACPI kernel, you can try changing the ACPIEnable option from ACPIEnable = 2 to ACPIEnable = 1 in the Txtsetup.sif file. This forces Setup to enable ACPI and load the ACPI kernel. This has the potential to cause the machine to do odd gymnastics, so it is not recommended except for personal experimentation.

Power Management Features

Dependingon the ACPI table entries found during Setup, Windows Server 2003 and XP display certain options in the Power Options window opened in Control Panel. Figure 3.15 shows the options for XP running on a laptop. Figure 3.16 shows the options on Windows Server 2003.

After Setup decides on the ACPI configuration for a machine, the entries are hardwired into the HAL. If you change your mind later on and decide to enable an option in CMOS, you'll need to reinstall the operating system. Keep this in mind when you deploy images.

Windows Driver Model (WDM)

A key benefit to the merging of the corporate and consumer Windows products is the ability to use a single driver throughout the product line. The blueprint for creating those drivers is the

Windows Driver Model , or WDM. If you are interested in the architecture of WDM drivers or how they are developed, here are a few good references:

• Programming the Microsoft Windows Driver Model , by Walter Oney. This is an excellent book for system administrators because it has lucid descriptions of the way the drivers work and the architectural models of the driver internals.




• Developing Windows NT Device Drivers: A Programmer's Handbook , by Edward Dekker and Joseph Newcomer. This is another excellent resource. You'll get a lot of information if you don't mind sifting through a little complex jargon.




• Windows NT Device Driver Development , by Peter Viscarola and Anthony Mason. This is considered the definitive book on NT device drivers. It is geared more for the older NT Driver Model, but has solid coverage of WDM.




• Windows Server 2003 Driver Development Kit (DDK) . The documentation in the DDK is terse, but you can't get much more authoritative. The DDK used to be a free download from Microsoft, but now you have to purchase it.

WDM and PnP are inextricably linked in Windows Server 2003, so here is a brief overview just to get the vernacular.

Bus

The WDM view of I/O starts with a bus. A bus is an interface that controls one or more devices. An IDE controller is a bus, for example, because it provides the interface to one or more hard drives. Other buses include the following:

• Personal Computer Interface (PCI) bus




• RS-232 Serial Bus




• Parallel Port




• Advanced Configuration and Power Interface (ACPI)




• Small Computer System Interface (SCSI)




• PC Card (formerly Personal Computer Memory Card International Association, or PCMCIA)




• Universal Serial Bus (USB)




• IEEE 1394 FireWire

Bus Drivers

A bus is controlled by a bus driver. Bus drivers are controlled by the Plug and Play Manager, which communicates with the devices via function calls in the HAL.

A bus driver enumerates devices on its bus and builds a

Physical Device Object (PDO) for each device it finds. The PDO virtualizes the device, rendering it into a digital form that can respond to commands from the Executive. Other duties of the bus driver include hall monitor, errand boy, receptionist, and gofer. In other words, it does the following:

• Keeps track of events on its bus and reports them to the Plug and Play Manager.




• Responds to I/O request packets (IRPs) from Plug and Play Manager and Power Manager.




• Improves I/O performance by multiplexing bus access requests.




• Performs administrative chores required to keep the devices on the bus running smoothly.

Functional Device Objects

A bus driver generally does not communicate directly to devices on its bus unless the devices use

raw I/O . Instead, the bus driver virtualizes the physical device objects still further into data constructs called

Functional Device Objects (FDO). These FDOs are controlled by

function drivers . The Plug and Play Manager loads one function driver for each device.

Function Drivers

A function driver is implemented as a set of drivers: a

class driver , a

minidriver , and one or more

filter drivers.

• Class drivers.
  Provide basic functionality for a device type, such as a mouse or a scanner or a hard drive. Microsoft usually writes class drivers.




• Minidrivers.
  Determine specific operational functions. Vendors write mini drivers for their hardware.




• Filter drivers.
  Layer above or below the function driver and provide additional services. Microsoft encourages vendors to write filters rather than build entirely new custom minidrivers.

WDM Functional Example

Here is an example of how a device with a WDM driver is enumerated and loaded:

1. Insert a new PC Card SCSI controller with an attached Jaz drive into the PCMCIA slot of a laptop.




2. The PCMCIA driver discovers the new card and creates a Physical Device Object (PDO) for it. It informs Plug and Play Manager about the new PDO.




3. The Plug and Play Manager looks up the correct driver for the new PDO, loads the driver, and passes the PDO over to the SCSI driver.




4. The SCSI driver builds a Functional Device Object (FDO) and attaches it to the driver stack for the PC Card bus.




5. Plug and Play Manager instructs the SCSI driver to enumerate the bus.




6. The SCSI driver enumerates the bus, finds the SCSI drive, and creates a PDO for the drive.




7. Plug and Play Manager looks up the driver for the new PDO, loads the driver, and passes control of the PDO over to the new driver.




8. The disk driver builds an FDO for the drive and attaches the FDO to the device stack for the SCSI bus.




9. The file system drivers in I/O Manager can now communicate with the drive via the SCSI bus interface.

One of the end results of all this PnP discovery, enumeration, and object building is a