Wednesday, March 24, 2010

Windows 2003 Server EMS core

test2

Windows 2003 Server EMS core Hardware

Introduction

The Microsoft Windows operating system provides many mechanisms for managing a system when Windows is loaded, fully initialized and the system is functioning. This type of system management is called “in-band” and typically occurs over the network. However, a different solution is required for managing a system when the system has failed or when Windows is not loaded, is in the process of loading, or is in distress, because Windows network software is not available. This type of system management is called “out-of-band” management.

The goal for out-of-band management is always to return the system to a fully functioning state where in-band management is available. Making both in-band and out-of-band management available remotely are key components of headless functionality. With the exception of hardware replacement, all administrative functions that can be accomplished locally should be available remotely. For example, it should be able to accomplish the following remotely:

•Power on a system that is currently off

•Change BIOS settings or view POST results

•Choose the operating system, set operating system options

•Interact with specific diagnostic and recovery tools

•View system blue-screens

•Reset a system

To accommodate the many possible system operation states, careful thought must be given to hardware, firmware, and operating system functionality to ensure a comprehensive and complementary implementation of out-of-band management capabilities. Each system component must contribute to the coherent, complementary solution in order to avoid expensive, confusing administration.

This paper summarizes the design issues and requirements for hardware and firmware that will ensure coherent, complementary functionality for out-of-band management of a headless system running Microsoft Windows.

Headless Implementation in the Windows Server 2003 Family

A headless solution requires removal of local console I/O dependencies in the operating system. Windows Server 2003 supports operating without a keyboard, mouse, or monitor attached to the system. On an ACPI-enabled system, Windows Server 2003 supports operating without a legacy 8042 keyboard controller. Windows Server 2003 also includes support for systems without VGA/video hardware.

Based on built-in Windows support, a USB-capable system running Windows Server 2003 can support hot plugging the mouse and keyboard while Windows is running, and a system with a VGA card can support hot plugging a monitor.

In Windows Server 2003, out-of-band console I/O support is provided for all Windows kernel components, the loader, setup, recovery console, Windows kernel, blue-screens and a text mode management console available after Windows Server 2003 has initialized called the Special Administration Console. This functionality is called the Emergency Management Services (EMS). This I/O conforms to the following by default:

•9600 baud

•1 stop bit

•No parity

•8 data bits

•No flow control

•Output conventions are defined in “Standardizing Management Console Output on the Serial Port Interface (VT100+)” later in this paper.

Note that these settings were chosen because they are the current “standard” configuration in UNIX administration world and allow interoperability. However, additional settings are supported if they are passed via the Serial Port Console Redirection Table. It is suggested that higher baud rates be used whenever possible and legacy VT100 support is not a concern. The specification for the Serial Port Console Redirection Table can be found at http://www.microsoft.com/hwdev/platform/server/headless/default.asp

Designing Hardware and Firmware for Windows Server 2003 Headless Systems

There are three key areas that must be addressed to provide a high quality headless platform that is cleanly integrated with Windows Server 2003 EMS. The section of this paper covers these three areas.

The first area is management port hardware: The Windows Server 2003 family will support a standard legacy serial port. Provided hardware support is available for testing, the Windows Server 2003 family will also support systems with more advanced management hardware, that provides a UART interface in system I/O space or Memory Mapped I/O.

The second area is a standardized firmware and management console user interface. It is important the system firmware and out-of-band management service processor user interface be available via the same out-of-band communication channel as the EMS. The firmware must cleanly hand the communication channel off to the EMS during the boot process. The firmware must use the same terminal definition as Windows Server 2003 EMS and use the same keystrokes to represent not standardized keystrokes such as F12 as specified later in this paper.

The third area is the passing of the out-of-band communication channel configuration information from the firmware to Windows Server 2003. This is achieved via the Serial Port Console Redirection Table.

Providing Legacy Out-of-Band Management Port Hardware for Use with EMS

The headless functionality in the Windows Server 2003 family supports a standard (16550) serial port at the legacy address of COM1, COM2, COM3 or COM4 (3F8, 2F8, 3E8 and 2E8 respectively) or a UART at well known non-legacy address as described in “Providing Non-Legacy Out-of-Band Management Port Hardware for Use with EMS” A server must provide at least one UART interface capable of use by Windows Server 2003 EMS. Windows EMS does not make use of legacy PC interrupts even when using a legacy com port.

When using a serial port connection to access Windows EMS support, all serial cables must be null modem cables that support the Carrier Detect (CD) signal. Windows will not provide console I/O if Carrier Detect is not active. Note: Cables with Carrier Detect shorted to RTS (Ready to Send) will work.

Providing Non-Legacy Out-of-Band Management Port Hardware for Use with EMS

This describes requirements for either a serial port or service processor.

The guidelines in this section apply for service processors configured to use an I/O location other than the legacy COM port address.

The legacy COM port on a Super I/O chip is an ideal out-of-band management port. It provides a serial port at a well-known address, and the hardware is reliable and fully defined. Therefore, Windows Server 2003 support for the out-of-band management port communicates with a UART device that uses a serial protocol, typically at a standard COM port address.

Notice, though, that it is a goal for the industry to move to “legacy free” systems that are designed without Super I/O chips or legacy COM ports. To expose the same serial-port functionality in legacy-free system, the mechanism of choice is a UART in PCI I/O space, which can be as simple as a serial port on a PCI card.

However, several OEMs produce add-on management devices for controlling the computer in its pre-boot state. A natural extension of these devices is to use them as the EMS I/O device.

Using Windows software in conjunction with OEM-supplied device provides several benefits. Software-only solutions typically cannot provide all the functionality found on these OEM management boards (hardware reset, power on, and so on). However, combining both hardware and Windows software solutions can achieve an extremely compelling solution for corporate customers.

The non-legacy UART interface in PCI I/O space can be exposed regardless of the underlying device or its external connection. This allows the Windows Server 2003 EMS to use the same simple programming model, regardless of the device or bus that this device uses. The OEM can also abstract the output of the interface such that it is no longer restricted to a serial cable. For example, some of these devices have an RJ45 connector, allowing customers to extend their investment in Ethernet network cabling by implementing a private management network while avoiding the problems and cost of serial cable deployment.

NOTE: Support for non-legacy UARTs in system I/O on 32 and 64 bits and MMIO in the 64-bit versions of the Windows Server 2003 family is dependent on hardware being available for testing. If hardware is not available, only UARTs at the legacy addresses of COM1 and COM2 will be supported.

Out-of-Band Management Port Device Requirements

This section lists the requirements for the out-of-band management port device for the Windows Server 2003 family.

1.UART control register must function as a standard UART Device

The device must act as a 16550 or 16450 UART. Windows Server 2003 will test this device using the following process.

1. Save off the current modem status register.

2. Place the UART into diagnostic mode (The UART is placed into loopback mode by writing

SERIAL_MCR_LOOP to the modem control register).

3.The modem status register is read and the high bits are checked. This means SERIAL_MSR_CTS, SERIAL_MSR_DSR, SERIAL_MSR_RI and SERIAL_MSR_DCD should all be clear.

4.Place the UART in diagnostic mode and turn on OUTPUT (Loopback Mode and OUTPUT are both turned on by writing (SERIAL_MCR_LOOP | SERIAL_MCR_OUT1) to the modem control register).

5.The modem status register is read and the ring indicator is checked. This means SERIAL_MSR_RI should be set.

6.Restore original modem status register.

2.UART control register must be at a well-known address

The current plan is: On x86 systems, this address must exist exclusively in system I/O space (which includes legacy COM port address). On IA-64 systems, this address must exist at a legacy COM port address or in Memory Mapped I/O. Support for addresses other than legacy COM ports will be determined largely based on support by Hardware that OEM’s are able to supply.

3.Device that the UART is on must be available before Windows is loaded

In particular, the device must be available to the Windows loaders. This implies that the device must be configured by the BIOS during POST.

Recommended: The BIOS should expose the out-of-band management port in such a way that the port is available for redirecting BIOS initialization screens or that the surrounding hardware redirects the BIOS screens through some other method (“screen scraping”).

4.UART device must always be available to the system

For the Windows loader to communicate with this device, the address must be “pre-translated” to the processor-relative address, because the loader cannot call into the hardware abstraction layer (HAL) in order to translate a bus-relative address to a processor-relative address.

5.Address of the UART device may not change

The Windows headless software is not Plug and Play-aware, and it only stores the translated address for a device. If the device address were to be relocated, the headless software that wrote to the translated address would write to an invalid system address.

6.System has exclusive access to the out-of-band management port

The system will write directly to the out-of-band management port instead of going through the Windows I/O Manager. No device driver, for example, should also try to write to this device. In particular, there is no Windows support for a “crashport” that is only invoked upon a blue-screen, similar in concept to crashdebug.

7.System can include only one out-of-band management port

The Windows Server 2003 family does not support any scenario where one device is the output out-of-band management port and another device is the input out-of-band management port.

8.Out-of-band management port must remain highly available

For example, the device should not be powered off while the system is running.

Out-of-Band Management Port Implementation

The following describes how Windows Server 2003 and hardware must function together for proper EMS out-of-band management port detection and interaction.

Mechanism must be provided for determining the base address of the out-of-band management port

Windows Server 2003 performs a series of checks to detect the base address of the out-of-band management port. The following is the order of precedence of the settings that are checked (that is, 1 supercedes 2). For a system that will support Windows Server 2003 EMS, one of these mechanisms must be provided.

1.User specifies address in Boot.ini (IA 32 only). The user can indicate that one of the legacy COM ports is to be used for headless operation. By detecting the keywords COM1 or COM2 in Boot.ini for redirection, the system can deduce the I/O address of the device, because these devices are always at a well-known address. This is the least preferred method, because it allows conflicts between Windows and BIOS settings.

2.System detects address in Serial Port Console Redirection (SPCR) ACPI table (ACPI-enabled platforms). An ACPI BIOS can implement the SPCR ACPI table, which indicates the address of the out-of-band management port. This address must be pre-translated to a processor-relative address.

3.System detects address from EFI-based console output handle (IA 64 only). Windows can examine the console device handle (which may include “sub-device paths” to determine whether they are “headless” devices. If the device path for the console device is a UART device, the device path will have a UART device sub-path. Windows can then look at the other parts of the device path to determine the base address of the port. This might include examining the ACPI portion of the device path for the _CRS, and so on. Base addresses of PCI devices are not determined using this method.

Device initialization must be handled by BIOS

The headless-aware BIOS or system firmware must configure the out-of-band management port during POST so that BIOS startup screens and the Windows loader screens can be redirected during system startup.

Out-of-band management port base address must not change

This may be achieved in one of these ways:

•Out-of-Band management port resides on a bus that doesn’t relocate. If the out-of-band management port is a COM port on the ISA bus, then the port address will not move. If the device is on the PCI Root Bus, the device address will not move, because the root PCI bus also receives special treatment in Windows Server 2003; however, in future versions of Windows this may not be the case.

•Non-standard devices can be claimed by BIOS. Here, “non-standard” refers to any device not defined in ISA or PCI space. An ACPI BIOS can implement a Motherboard Resources Device for a non-standard out-of-band management port. This prevents the device resources from being claimed by another resource.

•Windows Server 2003 PCI Bus driver prevents device from being moved. During system initialization, the system bus drivers will initialize the devices on their respective bus. The bus initialization must be able to detect an out-of-band management port on the bus and ensure that the device is not moved. For Windows Server 2003, PCI is the only bus besides ISA that will be supported by Windows EMS. If the BIOS provides the PCI information in the Serial Port Console Redirection ACPI fixed table or the EFI console device path points to an appropriate headless port, then Windows will ensure that the device will not be powered off or moved.

This device will not be enumerated by PNP. This protects the port from having a PNP driver being loaded for it or being moved by PNP. Because the device will not be enumerated by PNP, none of the other functions of the device falling under the same header as the Out-of-Band management port will be enumerated, making it impossible to associate a device driver with the other functions on this device. These other devises must have their own PCI headers and decode logic.

A PCI Out-of-Band management port device can be located using the SPCR ACPI table, which provides sufficient information to describe the out-of-band management port. This data includes PCI bus, slot, and function number for the device. In addition, the device ID and vendor ID for the device will be included in the table. (0xFFFF vendor ID and device ID will indicate an ISA device in the SPCR table.)

Exclusive access to device must be enforced

•The system firmware can use the out-of-band management port for redirecting it’s UI.

It is recommended that the BIOS or service processor redirect all output until serial traffic is detected. The first character of the detected serial traffic must be transmitted. In this scenario, Carrier Detect on UART must be held high even when console redirection in occurring. Once serial traffic is detected, Windows EMS must have full and exclusive access to the out-of-band management port.

If no serial traffic detection code is implemented, once Int 19 on BIOS systems or ExitBootServices on EFI systems has been called, the Windows EMS must have full and exclusive access to the out-of-band management port.

•The out-of-band management port must always be present and available. It may not disappear or become inaccessible for writes or reads.

•Windows Server 2003 detects the out-of-band management port and does not expose this device to any higher-level interfaces.

Implementing Firmware for Headless Systems

The firmware must provide the Serial Port Console Redirection (SPCR) table, which allows Windows to determine the location and setting used by the firmware for console I/O on the serial port. This could be used to automatically match the Windows configuration with the firmware configuration.

The BIOS must support PXE-compatible network adapters, as defined in Preboot Execution Environment (PXE) Specification, Version 2.1, available at http://developer.intel.com/ial/wfm/wfmspecs.htm. For EFI-based systems, the remote boot protocols are defined in the EFI specification. See also “RIS and PXE Requirements” later in this paper.

It is important the firmware configuration, e.g. BIOS Setup, be available via the same out-of-band management port as Windows Server 2003 Emergency Management Services. If the out-of-band management port that the EMS uses is a legacy serial port, the BIOS or system firmware must redirect its console I/O to the same serial port and settings that Windows supports. Furthermore, if the redirection settings can be configured, they should default to the Windows-compatible settings cited earlier: COM1 9600 baud, 8N1 without flow control.

Serial console I/O must be in the format of VT100 plus the conventions defined in “Standardizing Management Console Output on the Serial Port Interface (VT100+)” later in this paper.

Firmware Localization Requirements

If the firmware uses a language other than English, the serial port output must be in UTF8 format as defined by the UNICODE Group (see http://www.unicode.org/).

•On a BIOS-boot system, the language used by the BIOS must be defined in the Serial Port Console Redirection Table (see http://www.microsoft.com/hwdev/platform/server/headless/default.asp).

•On an EFI-based system, this information is stored in the global environment variables as defined in the EFI specification, version 1.0 or later.

RIS and PXE Requirements

The Windows Server 2003 family provides Remote Install Services (RIS) on servers. This allows remote, network-based installation of the Windows EMS on a clean system. To take advantage of this capability, a network adapter that is PXE capable is required, as defined in Preboot Execution Environment (PXE) Specification, Version 2.1.

A PXE capable network adapter is not required. However, if a network adaptor that is PXE capable can be inserted into the system, the system firmware or BIOS implementation must allow the PXE boot to be a selection for the boot order. For example, an administrator might configure the BIOS to attempt to boot in this order: hard drive, CD-ROM, floppy drive, network.

Furthermore, the system firmware or BIOS must provide an option that the administrator can use to initiate a remote boot by way of a keystroke, in effect circumventing the boot order list. This key should be F12.

Being able to specify and circumvent boot order allows implementation of useful emergency recovery scenarios (see “Scenarios” later in this paper).

Designing Service Processor/ASIC or UPS

A service processor/ASIC UPS can provide headless management in conjunction with the support in the Windows Server 2003 family. The Service Processor/ASIC can provide support for dealing with management tasks that Windows Server 2003 can not provide, such as powering on the system, resetting the system when it is hard hung, retrieving Field Replaceable Units information or performing hardware diagnostics. They can also provide secured output on mediums more complicated than serial ports, such as HTTP on TCP-IP on Ethernet.

Service Processor/ASIC General Functionality Requirements

The ASIC or service processor must provide a mechanism to reset the system. The There are many opportunities for value-added capabilities while still adhering to these guidelines. For instance, Field replaceable units (FRUs) and sensor data etc. may be provided.

Service Processor/ASIC Internal Hardware Interface Requirements

To provide complementary functionality Windows Server 2003 EMS and the Service Processors must both be available to the remote Administrator. To this end, the Service Processor/ASIC must provide a pass-through connection between Windows and the management system. This allows the user to interface to both the service processor and Windows Server 2003 EMS via a single connectivity medium and a single cable.

The service processor/ASIC must provide a 16550 (preferred) or 16450 UART in system I/O (which includes legacy COM port addresses) on IA32, and MMIO or at a legacy COM port address on IA64, as an internal hardware interface. This UART hardware Interface must always be available to Windows Server 2003 EMS. I.E. The UART interface must be provided by hardware or firmware not a Windows Device driver so that it is available when the Windows Server 2003 Loader is running, when Windows Server 2003 is fully loaded and when there has been a blue-screen etc. This UART may not disappear or become unavailable to write to at time. For more information on the implementation of Out-of-Band management port hardware, see the above sections entitled “Providing Legacy Out-of-Band Management Port Hardware for Use with EMS” and “Providing Non-Legacy Out-of-Band Management Port Hardware for Use with EMS.”

Non-legacy UART interfaces must be described fully in SPCR table. On IA32 systems, legacy COM ports should be described fully by the SPCR table. On IA64 systems, legacy COM ports must be described fully by the SPCR table (preferred) or via EFI console device path.

Service Processor/ASIC External and User Interface Requirements

These guidelines allow freedom of design in the in external and user interface while maintaining usability and integration of Windows Server 2003 EMS and Service Processor/ASIC. The Service Processor/ASIC may expose varying external hardware interfaces, such as serial port, RJ45 (Ethernet) or a proprietary connector. Furthermore, some external interfaces may support more than one communication protocol, e.g. Ethernet supports telnet, sockets and HTTP traffic among others. However, from the standpoint of these guidelines, these can be divided into two categories, those that can output only a single channel of communication e.g. serial ports with VT100, and those that can output multiple channels simultaneously e.g. Ethernet with HTTP.

Single Channel External Interfaces

When the external interface to the Service Processor/ASIC is a single channel external interface such as the serial port, it is only possible the user to interact with one Out-of-Band management entity at a time. The EMS and the service processor must be able to share this external interface in a reliable and useable way. To this end integration between the Windows Server 2003 EMS and the Service Processor/ASIC is particularly important since during the boot process the user will be using the same user interface, typically some form terminal to interact with both, and expect the same I/O conventions to be followed by both.

During the boot process the typical user experience must be

1)Power on the system (if supported) – Service Processor/ASIC Functionality

2)View and optionally interact with FW POST – Service Processor/ASIC and Firmware Functionality

3)View and optionally interact with the Windows Server 2003 Loader – EMS Functionality

4)View and optionally interact with the Special Admin Console (SAC) – EMS Functionality

The Firmware and Service Process must allow Windows Server 2003 Full control of the service processor after step 2 so that step three and on may occur. These means that complete control of the internal UART interface must be available and the Service Processor/ASIC must provide pass-through port functionally that allows Windows Server 2003 EMS to communication directly with in a manner exactly equivalent to a standard terminal attached via a null modem to a serial port.

During normal operation, service processor/ASIC must allow unconstrained communication between Windows and the management system. In this case Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp, provides a mechanism to invoke and exit the Service Processor or ASIC. When the pass through-port is in use by windows, the service Processor must “snoop” the traffic on the pass through port for the proper escape sequence. The ASIC or service processor may interrupt the Windows use of the pass-through port when the appropriate escape sequence is sent from the management system and the Service Processor/ASIC “snoops” it. Then the Service Processor/ASIC sends an escape sequence as an acknowledgment to the management system that it has been invoked and then present its user interface on the serial connection.. The Service Processor should intercept the escape sequence used to invoke it and any serial traffic that follows the escape sequence until it returns to pass through mode. When the service processor is not in pass through mode, it should lower Carrier Detect (see the section “Exclusive access to device must be enforced” in this paper for the special case of initial BIOS/Service Processor console redirection) unless it buffers all data from EMS. Such a buffer should be configurable to on or off. The Service Processor must return to pass-through mode when the appropriate escape sequence is sent be from the management system. These escape sequences requirements are documented in Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp.

Service Processor/ASIC Serial Port Pass-through Topology

When the service Processor is invoked and the user is interacting with it certain escape sequences must initiate specific behavior. These escape sequences and behaviors are documented in Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp.

If the Service Processor/ASIC did not use the same conventions as the EMS, the user would have an extremely difficult time sending the proper commands escape sequences. A standard terminal must be used to maintain interoperability between Windows NET Server EMS and service processor from multiple systems from multiple vendors. However, no standard terminal covers the additional extended keys on the PC 101 keyboard e.g. neither VT100 nor any other standard terminal has an F12 key or a standard way of encoding it on the wire. To this end, Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp, is provided. The service processor/ASIC and firmware must adhere to the same terminal conventions as described in the Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/headless. The user interface must be accessible via a terminal or terminal emulator supporting either VT100+ or a terminal VT100.

Multiple Channel External Interfaces

When the external interface to the Service Processor is a multiple channel external interface, as LAN connection may be, the requirements for providing access to the EMS change slightly. The channel for EMS communication must always be available regardless of whatever other management tools and communication is ongoing.

The client software provided to manage the out-of-band functionality provided by the Service Processor/ASIC must provide a terminal interface that the administrator may use to directly access the EMS. The terminal portion of the client must behave as a standard 80X25 terminal supporting VT100 or VT100+, i.e. the experience of the user should be that of attaching a terminal via a null modem cable to a serial port.

In the multi channel scenario the service processor is not required to provide any interaction with it’s user interface via this terminal screen. However In this case, the required service processor/ASIC and firmware functionality must be available elsewhere in the client user interface. If the firmware is available through this console, the firmware must adhere to the guidelines in “Implementing Firmware for Headless Systems.” If the Service Processor/ASIC is available through this console, the Service Processor/ASIC must adhere to the guidelines in “Single Channel External Interfaces”.

UPS Requirements

An Uninterruptible Power Supply (UPS) can provide control of the power supplied to the server, which can in turn provide rudimentary management capabilities such as remote control of power off and power cycling. For the purpose of this document the term UPS also represents smart power switches which can offer the same management capabilities of a smart UPS but without the functionality of maintain power to the server when external power is lost.

A UPS can also allow serial communication to pass through it between a management system and the Windows headless server. That is, the management port could have a serial connection to an external serial port on the UPS, which could have a serial connection to the Windows headless server. If a UPS uses a pass-through serial port interface externally, this port must allow unconstrained communication between the system for which the UPS provides backup power, the management system, and Windows. The UPS can interrupt the use by Windows of the pass-through connection by way of an escape sequence sent from the management system. Using this mechanism a smart UPS can provide some of key basic functions of an onboard service processor for systems only have a serial port.

Note: To take advantage these capabilities, a server must be configured to automatically boot when power is applied.

Note: Some UPS provide applications that access the UPS, from the server being powered, via a serial port. The serial connection being used for EMS, between the UPS and the Server, cannot be accessed by an application on the server to access and configure the UPS. This requires 2 serial connections.

The following requirements apply for any UPS to be used to in conjunction with Windows NET Server EMS:

•The UPS must provide a mechanism to reset the system.

•The entire end-to-end pass-through serial path must present the serial signals from the system to be managed to the management console as though from a serial port through a null modem cable as described in “Selecting Hardware for Headless Systems” earlier in this paper.

UPS Pass-through Topology

•The UPS may interrupt the Windows use of the pass-through serial path when the appropriate escape sequence is sent from the management system. The UPS sends an escape sequence as an acknowledgment to the management system that it has been invoked and presents, if one exists, its user interface on the serial connection. The UPS should intercept the escape sequence used to invoke it and any serial traffic that follows the escape sequence until it returns to pass through mode. When the UPS is not in pass through mode, it should lower Carrier Detect unless it buffers all data from EMS. Such a buffer should be configurable to on or off. The UPS must return to pass-through mode when the appropriate escape sequence is sent be from the management system. These escape sequence requirements are documented in Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available at http://www.microsoft.com/hwdev/platform/server/headless/default.asp.

•The UPS user interface must adhere to the same terminal conventions as described in the Standardizing Out-of-Band Management Console Output and Terminal Emulation (VT-UTF8 and VT100+), available athttp://www.microsoft.com/hwdev/platform/server/headless/default.asp, The user interface must be accessible via a terminal or terminal emulator supporting either VT100+ or a terminal VT100. If the UPS did not use the same conventions as the EMS, the user would have an extremely difficult time sending the proper commands escape sequences.

Management Port Solutions for Partitioned Systems

A partitioned system must provide a management port per partition. The management port may not be added or removed from the partition dynamically.

Security

Security on access to power management tool like a Service Processor and Windows Server 2003 is an important consideration. Because of the nature of the changing states Windows software providing the EMS during the course of boot, Windows operation and possible failure, it would be impossible to provide a seamless and cohesive security story using only the Windows software. Therefore, Windows EMS relies on physical security in the case of simple hardware such as a serial port, and the security provided by any Service Processor, ASIC, UPS, terminal concentrator or other device providing access to the EMS if a less physically secure medium such as the network is provided by said devices.

Note: Any device providing access to the EMS may provide security even if its external interface is a serial port or other physically secure interface. Once the security requirements have been satisfied by the port must behave as specified above.

Server 2008 Roles for Core

New

Steps for installing server roles on a 2008 Server Core installation

To see the roles installed on the server, we should use oclist command.

DNS Server role

To install the DNS Server role

1.At a command prompt, type:

start /w ocsetup DNS-Server-Core-Role

After this by using dnscmd from the command prompt we can configure the configuration part like adding DNS zones & records, One more easy way is there by using remote management we can configure all these configurations from the remote server by using DNS management GUI console.

To uninstall the DNS server role

start /w ocsetup DNS-Server-Core-Role /uninstall

IMPORTANT: Server role should be mentioned with case sensitive.

DHCP Server role

To install the DHCP Server role

1.At a command prompt, type:

start /w ocsetup DHCPServerCore

2.Configure a DHCP scope at the command prompt by using netsh, or by remotely using the DHCP snap-in from Windows Server 2008.

3.If the DHCP server is installed in an Active Directory domain, you must authorize it in Active Directory.

The DHCP Server service does not start automatically by default. Use the following procedure to configure it to start automatically and to start the service for the first time.

To configure and start the DHCP Server service

1.At a command prompt, type:

sc config dhcpserver start= auto

2.Start the service by typing:

net start dhcpserver

start /w ocsetup DHCPServerCore /uninstall at the command prompt will uninstall the DHCP Server role

To install File Services role features

•For File Replication Service, type the following at a command prompt:

start /w ocsetup FRS-Infrastructure

•For Distributed File System service, type:

start /w ocsetup DFSN-Server

•For Distributed File System Replication, type:

start /w ocsetup DFSR-Infrastructure-ServerEdition

•For Services for Network File System (NFS), type:

start /w ocsetup ServerForNFS-Base

start /w ocsetup ClientForNFS-Base

Hyper-V role

To install the Hyper-V role, at a command prompt, type:

start /w ocsetup Microsoft-Hyper-V

To manage Hyper-V on a Server Core installation, use the Hyper-V management tools to manage the server remotely. These tools are available for Windows Server 2008 and Windows Vista Service Pack 1.

Print Services role

To install Print Services role features

•For the Print Server feature, type the following at a command prompt:

start /w ocsetup Printing-ServerCore-Role

•For the Line Printer Daemon (LPD) service, type:

start /w ocsetup Printing-LPDPrintService

To add a printer to the print server

1.Determine the IP address or host name of the printer. This may be on the printer's test or printer configuration page or you might need to refer to the manufacturer's documentation for instructions.

2.Verify that the print server can communicate with the printer through the network by pinging the printer from the print server.

3.On another computer running Windows Vista or Windows Server 2008, open the Print Management console and add the server running the Server Core installation.

4.Expand the entry for the print server running a Server Core installation, right-click Drivers, and then click Add Driver. The Add Printer Driver Wizard starts.

5.Complete the wizard to install the printer driver for your printer.

6.In the Print Management console, right-click Printers and then click Add Printer. The Network Printer Installation Wizard starts.

7.Click Add a TCP/IP or Web Services printer by IP address or hostname and then click Next.

8.Enter the printer's host name or IP address (the port name will be the same by default), and then click Next.

9.Make any necessary changes to the printer name, contact information, or sharing status, and then click Next.

Web Server (IIS) role

To install the Web Server role

1.For the default installation, type the following at a command prompt and press ENTER:

start /w pkgmgr /iu:IIS-WebServerRole;WAS-WindowsActivationService;WAS-ProcessModel

2.For an installation that includes all of the options, type the following at a command prompt and press ENTER:

start /w pkgmgr /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;

IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;

IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;

IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;

IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;

IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;

IIS-WebServerManagementTools;IIS-ManagementScriptingTools;IIS-IIS6ManagementCompatibility;IIS-Metabase;

IIS-WMICompatibility;IIS-LegacyScripts;IIS-FTPPublishingService;IIS-FTPServer;WAS-WindowsActivationService;

WAS-ProcessModel

Known issues for installing a server role on a Server Core installation of Windows Server 2008 R2

•You cannot use the Active Directory Domain Controller Installation Wizard (Dcpromo.exe) on a server running Server Core installation. You must use an unattend file with Dcpromo.exe to install or remove the domain controller role.

Alternately, you can run Dcpromo.exe on another computer running Windows Server 2008 R2 and use the wizard to save an unattend file that you can then use on the server running Server Core installation.

•Dcpromo.exe will restart the computer immediately when the installation is complete or when Active Directory is removed unless RebootOnCompletion=No is included in the answer file.

•The Web Server (IIS) role supports a subset of ASP.NET in Server Core installations of Windows Server 2008 R2. The following IIS features are available in Server Core installations of Windows Server 2008 R2, see the section “Web Server (IIS) role.”

Task: View system information

•Msinfo32

•Set

•Systeminfo

Task: View user information

•Whoami

Task: Manage users and groups

•Net accounts

•Net group

•Net localgroup

•Net user

Task: View or change computer name

•Hostname

•Netdom renamecomputer

Task: Join or leave a domain

•Netdom join

Task: Log off or shut down

•Logoff

•Shutdown

Task: Configure networking

•Ipconfig

•Netsh interface

•Netsh routing

•Route

Task: Configure Windows Firewall

•Netsh advfirewall

Task: Configure Internet Protocol security (IPsec)

•Netsh ipsec

•Scregedit.wsf

Task: Activate Windows

•Slmgr.vbs

Task: Manage services

•Net continue

•Net pause

•Net start

•Net stop

•Sc

•Tasklist

Task: Manage processes

•Taskkill

•Tasklist

•Taskmgr

Task: Manage tasks

•At

•Schtasks

Task: Collect and analyze performance data

•Logman

•Relog

•Typeperf

Task: View events and manage event logs

•Wevtutil

Task: Manage disks and storage

•Compact

•Defrag

•Diskpart

•Diskraid

•Mountvol

Task: Manage Volume Shadow Copy Service (VSS)

•Vssadmin

•Cacl

Task: Manage file systems and file permissions

•Convert

•Fsutil

•Icacls

•Takeown

Task: Manage files

•Openfiles

•Sigverif

Task: Manage shares and share permissions

•Net share

Task: Manage the registry

•Reg

•Regedit

Task: Install and manage drivers

•Driverquery

•Pnputil

•Sc

Task: Install and manage updates

•Pkgmgr

•Scregedit.wsf

•Systeminfo

•Wuauclt

•Wusa

Task: Install roles and features

•Oclist

•Ocsetup

Task: Install applications

•Msiexec

Task: Manage Group Policy

•Gpresult

•Gpupdate

•Secedit

Task: Manage certificates

•Certreq

•Certutil

Task: Manage Terminal Services (Remote Desktop for Administration)

•Change

•Logoff

•Msg

•Mstsc

•Qappsrv

•Qprocess

•Query

•Qwinsta

•Reset session

•Rwinsta

•Shadow

•Tscon

•Tsdiscon

•Tskill

Sunday, January 31, 2010

Analyze windows server Crash

Analyze windows server Crash
A system crash: If you're lucky, it only ruins your day. More than likely, you're in for several bad days followed by a few stressful weeks or months. After all, systems rarely fail only once. Rather, they keep crashing until you find the cause and fix the problem.
This primer will show you how to solve problems quickly. Using a tool that costs nothing, you can solve approximately 50% of Windows server and workstation crashes in a few minutes. The tool is WinDbg , the free Windows debugger.
You've probably never used the debugger, don't have it and don't want it. After all, it's a developer's tool, not an administrator's, right? Yes, but what you need to know is remarkably easy to learn, and even a rudimentary familiarity with the debugger could enhance your skills and your resume.
Think about this: After rebooting a crashed machine, we've brought up the debugger, opened a memory dump file, given the debugger a single command, and learned not only that the cause was a driver, but also the driver's name — all in less than a minute. Granted, the debugger was installed and configured, we knew what commands to use and what to look for.
Why does Windows crash?
To date, Windows has been used most commonly on the x86 processor. The x86 implements a protection mechanism that lets multiple programs run simultaneously without stepping on each other's toes. This protection comes in four levels of privilege or access to system memory and hardware. Two of these levels are commonly referred to as kernel mode and user mode.
Kernel mode is the most privileged state of the x86. Both the Windows OS and drivers are considered trusted, and, therefore, run in kernel mode. This ensures unfettered access to system resources and the ability to maximize performance. Other software is assigned to user mode, the least-privileged state of the x86, restricting direct access to much of the system. Applications, such as Microsoft Word, run in user mode to guard against applications corrupting system-level software and each other.
Although kernel-mode software is protected from applications running in user mode, it is not protected from other kernel-mode software. For example, if a driver erroneously accesses a portion of memory that is being used by other software (or not specifically marked as accessible to drivers), Windows stops the entire system. This is called a bug check or a crash, and Windows displays the popularly known Blue Screen of Death (BSOD). About 95% of Windows system crashes are caused by buggy software (or buggy device drivers), almost all of which come from third-party vendors. The remaining 5% is due to malfunctioning hardware devices, which often prompt crashes by corrupting memory contents.
Another little-known fact is that most crashes are repeat crashes. Few administrators can resolve system crashes immediately. As a result, they typically happen again and again. It's common to see weeks and months pass before the answer is found. By solving a crash immediately after the first occurrence, you can prevent time-consuming and costly repeat crashes.
We'll focus on solving crashes under Windows 2000, XP and Server 2003. The process is identical for Windows servers and desktops. With respect to the debugging and interpretation process, this information applies with remarkably little differences to other operating systems, such as Linux, Unix and NetWare.
Getting started
To resolve system crashes using WinDbg, you need the following:
A PC with 25M bytes of hard-disk space, a live Internet connection and Microsoft Internet Explorer 5.0 or later.
A PC running Windows Server 2003, Windows 2000 or Windows XP.
The latest version of WinDbg .
A memory dump (the page file must be on C: for Windows to save the memory dump file).
The memory dump is a snapshot of what the system had in memory when it crashed. Few things are more cryptic than a dump file at first glance. Yet it is the best place to go for information on a crash. You can try to get this data in other ways - a user or administrator may remember what the system was doing when it crashed, or that they installed a new hardware device recently, in which case you can check related drivers or hardware - but they could also forget, providing incomplete or inaccurate information.
Windows Server 2003, 2000 and XP create three types of memory dump files:
Small or mini dump : A mini dump is a tiny 64K-byte file. One reason it's so small is that it doesn't contain any of the binary or executable files that are in memory at the time of a system crash. The .exes are needed for full and proper crash analysis, therefore, mini dumps are of limited value without them. However, if you are debugging on the machine that created the dump file, the debugger can find them in the System Root folders, unless they were changed by a system update (we'll provide a workaround for this later). XP and Server 2003 produce mini dumps by default, one for each crash event, as well as a full dump file. While it saves all mini dumps, the system only saves the most recent full dump. Windows 2000 can save mini dumps, but by default it is set to save only a full dump.
Kernel dump : This is equal to the amount of RAM occupied by the operating system's kernel. For an XP PC with 512M bytes of RAM, this is usually around 60M bytes, but it can vary. For most purposes, this crash dump is the most useful. It is significantly smaller than the full memory dump, but it only omits those portions of memory that are unlikely to have been involved in the crash.
Complete or full dump : This is equal to the amount of RAM in the box. Therefore, a machine with 512M bytes of RAM creates a 512M-byte dump file (plus a little). While a full dump contains all possible data and executables the memory has to offer, its sheer size can make it awkward to save or transfer to another machine for debugging. Windows 2000 produces a full dump by default.
Because XP and 2003 are set up to save a mini dump for every crash event, there should be a mini dump file for every crash the machine has had since it was turned on. This data can be extremely valuable, giving you a rich history to inspect.
Saving a memory dump
To resolve system crashes through the inspection of memory dumps, set your servers and PCs to automatically save them with these steps:
Right-click on My Computer
Select Properties
Select Advanced
In the Start up and Recovery section, select Settings; this displays the Startup and Recovery dialog box
In the Write debugging information section, select kernel memory dump
While still in the Start up and Recovery dialog box, ensure that the following options are checked in the System failure section:
Write an event to the system log
Send an administrative alert
Automatically restart
In the Write debugging information, you have the option to save only the most recent dump file or to have the system rename the existing dump file before it creates a new one. We prefer saving the dump files because previous dump files may provide additional or different information - however, space can be an issue, so set this option according to your needs.
The Write debugging information section also tells you where the dump file will be created. On XP and 2003 systems, mini dumps are located at %SystemRoot%\Minidump, or c:\Windows\Minidump; kernel and full dumps are located at %SystemRoot%\MEMORY.DMP or c:\Windows\MEMORY.DMP. For Windows 2000, memory dump files are located at c:\winnt\memory.dmp.
If you don't have a dump file on your machine, you can get one from another system or download one here. This kernel dump is about 20M bytes zipped and 60M bytes extracted. It was created using a testing tool that generates a system crash.
Getting the debugger
The debugger is free and available from Microsoft's Web site. At the site, scroll down until you see the heading, "Installing Debugging Tools for Windows." Select the link, "Install 32-bit version…” and then select the most recent non-beta version and install it. The most recent versions are about 12M-byte downloads. You can do the installation on a PC without restarting it (Don’t be surprised if the site has changed somewhat. Microsoft keeps improving the debugger with releases at least once per year.).
This distribution includes KD.EXE, the command-line kernel debugger; NTSD.EXE, the command-line user-mode debugger; CDB.EXE, the command-line user-mode debugger (a variant of ntsd.exe); and WinDbg, the GUI version of the debugger. WinDbg supports kernel-mode and user-mode debugging, so WinDbg is the one we'll use here.
Setting up the debugger
There are two ways to look at crash data: View what's in memory while the system is stopped (by linking it to a running PC with a null-modem cable, or invoking a product that you pre-installed on the system, such as SoftICE, which lets you step through the code in memory line by line)
Null-modem cables are serial cables that have been configured to send data between two serial ports. They are available at most computer stores. Do not confuse null-modem cables with standard serial cables, which do not connect serial ports.
Given that minimizing interruptions is the goal of most administrators, we opt for the second way: Restart the server or PC, launch the debugger, and open the dump file.
From the program group Debugging Tools for Windows, select WinDbg. After the debugger comes up, you'll immediately notice a lot of … nothing. A blank screen. That's because you have to specify a dump file to analyze and download symbol tables to use in the analysis. Let's take care of the symbol files first.
Symbol tables are a byproduct of compilation. When a program is compiled, the source code is translated from a high-level language into machine code. At the same time, the compiler creates a symbol file with a list of identifiers, their locations in the program, and their attributes. Some identifiers are global and local variables, and function calls. A program doesn't require this information to execute. Therefore, it can be taken out and stored in another file, reducing the size of the final executable.
Smaller executables take up less disk space and load into memory faster than large ones. But there's a flip side: When a program causes a problem, the OS knows only the hex address at which a problem occurred. You need something more than that to determine which program was using that memory space and what it was trying to do. Windows symbol tables hold the answer. Accessing these tables is like laying a map over your system's memory.
Windows symbol files are free from Microsoft's Web site, and the debugger can retrieve them automatically. To set up the debugger to do this, verify that you have a live Internet connection and set the symbol file path in WinDbg by selecting File Symbol File Path. Then enter the following string:
SRV*c:\local cache*http://msdl.microsoft.com/download/symbols
Substituting your own directory path for c:\local cache. For example, if you want the symbols to be placed in c:\symbols, then set your symbol path to
SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
The location of the symbol table is up to you.
When opening a memory dump, WinDbg will look at the EXE/DLLs and extract version information. It then creates a request to the symbol server at Microsoft, which includes this version information, and locates the precise symbol tables to draw information from. If you have difficulty retrieving symbol files, check that your firewall permits access to http://msdl.microsoft.com.
If you restrict your debugging to memory dumps from the machine you are on, you will need relatively little hard-disk space for the symbol tables. In most cases 5M-bytes will be more than sufficient. But if you plan to look at dumps from other machines that have different Windows versions and patch levels, you'll need more space for the additional symbol files that support those versions.
System update workaround
If you are trying to analyze mini dumps on a machine that had updates installed after the dumps were created (or if you're analyzing a mini dump file from another machine), the drivers found in your system root will be different (newer) than the ones present when the mini dump were created. To solve this, set the executable image file path by selecting File Image File Path. Then enter the following string: c:\windows\System32; c:\windows\system\System32; http://www.alexander.com/SymServe.
Loading the dump file
To open the dump file that you want to analyze, select File Open Crash Dump. You'll be asked if you want to save workspace information. Click Yes if you want it to remember where the dump file is. WinDbg looks for the Windows symbol files. WinDbg references the symbol file path, accesses microsoft.com, and displays the results. Close the Disassembly window so you are working in the Command window.
NOTE: Don’t be surprised if the debugger seems rather busy following opening of the dump file, especially the first time you try it. It needs to retrieve symbols and, in the case of mini dumps, it needs to retrieve the binaries. This may take a few minutes. Also, the newer release of WinDbg seems to take longer retrieving driver data as well. Be patient. It is worth the wait!
At this point, WinDbg may return an error message, such as the following one, indicating it could not find the correct symbol file.
*** ERROR: Symbol file could not be found. Defaulted to export symbols for ntoskrnl.exe -
If it does, one of the following three things is usually wrong:
Your path is incorrect; check to make sure there are no typos or other errors in the symbol file path you entered earlier.
Your connection failed; check your Internet connection to make sure it is working properly.
Your firewall blocked access to the symbol files or damaged the symbol file during retrieval.
If your path and connection are solid, then it's likely that the problem is your firewall. If a firewall initially blocks WinDbg from downloading a symbol table, it can result in a corrupted symbol file. Unblocking the firewall and attempting to download the symbol file again does not work; the symbol file remains damaged. The quickest fix is to close WinDbg, delete the symbols folder (which you most likely set at c:\symbols), and unblock the firewall. Now, reopen WinDbg and a dump file. The debugger will recreate the folder and re-download the symbols.
If you see this message, "***** Kernel symbols are WRONG. Please fix symbols to do analysis.", WinDbg was unable to retrieve the proper symbols and it will resort to using the default symbol table. But as the warning suggests, it cannot produce accurate results. Remember that symbol tables are generated when programs are compiled, so there is a symbol table file for every Windows version, patch, hot fix, and so on. Using the wrong symbols to track down the cause of a crash is like trying to steer a ship into Boston Harbor with a chart for San Diego. You must use the right ones, so go back up to the section above and ensure you have the right path set, the connection is good, and it is not blocked.
Look through WinDbg's output. You may see an error message similar to the following that indicates it could not locate the symbols for a third-party driver.
*** ERROR: Module load completed but symbols could not be loaded for driver.dll Unable to translate address bf9a2700 with prototype PTE Probably caused by: driver.dll (driver+44bd)
This means that the debugger has found a driver is at fault but, being a third-party driver, there are no symbols for it (Microsoft does not store all of the third-party drivers). You can ignore this. Vendors do not typically ship drivers with symbol files, and they aren't necessary to your work; you can pinpoint the problem driver without them.
Debugger commands
With the dump file loaded into WinDbg, it's time to ask for some diagnostic information. While there are loads of commands to use, two are all you need: !analyze –v and , and lmv.

!analyze –v displays information describing the state of a system when it crashed, the fault encountered, and who is the primary suspect.
lmv displays a list of drivers and their path, version and vendor information. It often includes a product description.
If you want to sound like a software engineer, or if at least you don't want to sound clueless, here's how you pronounce the first command: "bang analyze dash vee."
Analysis with !analyze –v
Type !analyze –v on the command line at the bottom of the Command window. The explanation it gives is a combination of English and programmer-speak, but it is nonetheless a great start. In fact, in many cases you may not need to go any further. If you recognize the cause of the crash, you're probably done.
Here's an example. After typing! analyze –v, we receive the following output:
kd> !analyze -v
KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
(This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address.)
Arguments:Arg1: c0000005, The exception code that was not handledArg2: bf9bc4bd, The address that the exception occurred atArg3: f69f02bc, Trap FrameArg4: 00000000
Debugging Details:------------------EXCEPTION_CODE: c0000005
FAULTING_IP:vdriver+44bdbf9bc4bd 8b4014 mov eax,[eax+0x14]
TRAP_FRAME: f69f02bc -- (.trap fffffffff69f02bc)ErrCode = 00000000eax=00000000 ebx=01740000 ecx=010886a0 edx=f69f069c esi=fa07d400 edi=e161f7f8eip=bf9bc4bd esp=f69f0330 ebp=f69f0344 iopl=0 nv up ei pl nz na pe nccs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202vdriver+44bd:bf9bc4bd 8b4014 mov eax,[eax+0x14] ds:0023:00000014=????????
DEFAULT_BUCKET_ID: DRIVER_FAULTBUGCHECK_STR: 0x8ELAST_CONTROL_TRANSFER: from bf9ba5cf to bf9bc4bd
STACK_TEXT:f69f0344 bf9ba5cf e161f7f8 e17f8e30 e21e4530 vdriver+0x44bdf69f06b0 f69f06e0 e2638678 f69f06e4 f69f0890 vdriver+0x25cfe1bd6b90 1f0507b6 00000000 e1622008 00000010 0xf69f06e000000000 00000000 00000000 00000000 00000000 0x1f0507b6f69f0bf0 805766ef f69f0c78 f69f0c7c f69f0c8c nt!KiCallUserMode+0x4f69f0c4c bf8733cd 00000002 f69f0c9c 00000018 nt!KeUserModeCallback+0x87f69f0ccc bf8722a5 bc667998 0000000f 00000000 win32k!SfnDWORD+0xa0f69f0d0c bf873b38 7196bc2d f69f0d64 00affed0 win32k!xxxDispatchMessage+0x1c0f69f0d58 805283c1 00afff2c 804d2d30 ffffffff win32k!NtUserDispatchMessage+0x39f69f0d58 7ffe0304 00afff2c 804d2d30 ffffffff nt!KiSystemService+0xc400afff08 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4
FOLLOWUP_IP:vdriver+44bdbf9bc4bd 8b4014 mov eax,[eax+0x14]
FOLLOWUP_NAME: MachineOwnerSYMBOL_NAME: vdriver+44bdMODULE_NAME: vdriverIMAGE_NAME: vdriver.dllBUCKET_ID: 0x8E_vdriver+44bd
Look for a section labeled "Debugging Details." Then, scan down until you find DEFAULT_BUCKET_ID:. This provides the general category of the failure. It shows DRIVER_FAULT, indicating that a driver is the likely culprit. Scanning further down to IMAGE_NAME, we see vdriver.dll. We have a suspect!
Analysis with lmv

The next step is to confirm the suspect's existence and find any details about him. Typing lm in the command line displays the loaded modules; v instructs the debugger to output in verbose (detail) mode, showing all known details for the modules. This is a lot of information. Locating the driver of interest can take a while, so simplify the process by selecting edit Find.
Here's an example of output generated by the lmv command:
kd> lmv bf9b8000 bfa0dc00 VDriver (no symbolic information) Loaded symbol image file: VDriver.dll Image path: \SystemRoot\System32\VDriver.dll Checksum: 00058BD5 Timestamp: Fri Sep 28 10:12:47 2001 (3BB4855F) File version: 5.20.10.1066 Product version: 5.20.10.1066 File flags: 8 (Mask 3F) Private File OS: 40004 NT Win32 File type: 3.4 Driver File date: 00000000.00000000 CompanyName: Video Technologies Inc. ProductName: VDisplay Driver for Windows XP InternalName: VDriver.dll OriginalFilename: VDriver.dll ProductVersion: 5.20.10.1066 FileVersion: 5.20.10.1066 FileDescription: Video Display Driver LegalCopyright: Copyright© Video Technologies Inc. 2000-2004 Support: (800) 555-1212
Use File Find to locate the suspect driver. If the vendor was thorough, complete driver/vendor detail is revealed
The amount of information you see depends upon the driver vendor. Some vendors put little information in their files; others, such as Veritas, put in everything from the company name to a support telephone number! If a vendor is thorough, the results from the command will be similar to those shown here.
After you find the vendor's name, go to its Web site and check for updates, knowledge base articles, and other supporting information. If such items don't exist or resolve the problem, contact them. They may ask you to send along the debugging information (it is easy to copy the output from the debugger into an e-mail message or Word document), or they may ask you to send them the memory dump (zip it up first, both to compress it and protect data integrity).
Not aways easy
Finding out what went wrong is often a simple process, but it isn't always so. At least 50% of the time (often 70%), the debugger makes the reason for a crash obvious. But sometimes the information it provides is misleading or insufficient. What do you do then?
Inconsistent answers
If you have recurring crashes but no clear or consistent reason, it may be a memory problem. Download the free test tool, Memtest86. This simple diagnostic tool is quick and works great.
Many people discount the possibility of a memory problem, because they account for such a small percentage of system crashes. However, they are often the cause that keeps you guessing the longest.
The operating system is the culprit
Not likely! As surprising as it may seem, the operating system is rarely at fault. If ntoskrnl.exe (Windows core) or win32.sys (the driver that is most responsible for the "GUI" layer on Windows) is named as the culprit, and they often are, don't be too quick to accept it. It is far more likely that some errant third-party device driver called upon a Windows component to perform an operation and passed a bad instruction, such as telling it to write to non-existent memory. So, while the operating system certainly can err, exhaust all other possibilities before you call Microsoft! The same goes for debugging Unix, Linux, and NetWare.
Wrong driver named
Often you will see an antivirus driver named as the cause. For instance, after using !analyze –v, the debugger reports a driver for your antivirus program at the line "IMAGE_NAME". This may well be the case, but bear in mind that such a driver can be named more often than it is guilty. Here's why: For antivirus code to work it must watch all file openings and closings. To accomplish this, the code sits at a low layer in the operating system and is constantly working. In fact, it is so busy it will often be on the stack of function calls that was active when the crash occurred, even if it did not cause it. Because any third-party driver on that stack immediately becomes suspect, it will often get named. From a mathematical standpoint it is easy to see how it will so often be on the stack whether it actually caused a problem or not.
Little or no vendor information
Not all vendors include needed information (not even their name!). If you use the lmv command and turn up nothing, look at the subdirectories on the image path (if there is one). Often one of them will be the vendor name or a contraction of it. Another option is to search Google. Type in the driver name and/or folder name. You'll probably find the vendor as well as others who have posted information regarding the driver.
Summary
When systems crash your first objective is to get them up and running. Your second is to fix the problem to prevent future crashes. Be willing to use any tool that can help you — even the Windows debugger. It won't give you the cause of every crash event, but it can help you solve 50% or more with two simple commands.

Analyze windows server Crash

News

Nintendo's Iwata dismisses iPad, 3D gaming
In AP report, Nintendo's Satoru Iwata says he doesn't believe Apple's iPad provides the kind of value some hoped it would. He also doesn't see much value in 3D gaming. 1/29/2010 10:18 AM
Read more Open in browser
Boeing puts 787 Dreamliner through stall tests
Company says that it has put its much-anticipated new plane through more than 50 stall tests and expects to do dozens more. So far, so good. 1/29/2010 8:52 AM
Read more Open in browser
Apple icon drops pants, suggests you e-mail your senator
In a PSA in support of the Clean Energy Jobs and American Power Bill, "Get a Mac" icon Justin Long encourages you to e-mail your senator. He also reminds you he's the Mac guy. 1/28/2010 4:46 PM
Read more Open in browser
McGraw-Hill on iPad launch: We didn't get booted; we weren't part of it
Remarks by CEO led some to believe the publisher was privy to iPad details before the launch, but that wasn't the case. It was never part of the event to begin with, says a spokesman. 1/28/2010 2:26 PM
Read more Open in browser
Who will buy the iPad?
The tech-savvy set has expressed mostly disappointment with Apple's latest device. But that doesn't appear to be Apple's intended audience. 1/28/2010 12:05 PM
Read more Open in browser
Expert sees security issues with the iPad
Security expert says things like strong encryption and an access control feature are missing from Apple's new iPad tablet device. 1/28/2010 10:55 AM
Read more Open in browser
Debating the merits of Apple's iPad
CNET writers Ina Fried and Josh Lowensohn hash out some of the pressing issues about the iPad: its merits, its faults, and what to look forward to in future iterations. 1/28/2010 9:12 AM
Read more Open in browser
$1 million for first perfecto in MLB 2K10
Almost any major league pitcher who threw a perfect game would be a millionaire. Now 2K Sports is offering a million dollars to the first gamer to toss one in its hit baseball video game. 1/28/2010 7:43 AM
Read more Open in browser
How 'Avatar' may predict the future of virtual worlds
When James Cameron invented a camera that integrated footage of actors directly into his digital universe, it may have presaged the worlds millions will spend time in one day. 1/28/2010 1:30 AM
Read more Open in browser
iPad unites Apple's media and mobile ambitions
The new tablet epitomizes Apple's direction as a mobile device maker and gatekeeper of media. 1/28/2010 1:30 AM
Read more Open in browser

WINTELTIPS

Search This Blog

Wednesday, March 24, 2010